IWETHEY v. 0.3.0 | TODO
1,095 registered users | 0 active users | 0 LpH | Statistics
Login | Create New User
IWETHEY Banner

Welcome to IWETHEY!

New More than security. Maintenance.
Using DML for all your table access eases maintenance. If you have to change something only the dml package changes, and not all the calls.

Same with views. I like to treat the tables as private data. When it changes, nothing else breaks.
Regards,

-scott anderson

"Welcome to Rivendell, Mr. Anderson..."
New In theory
In theory but my experience has been that isolating everything creates as much work as it saves. There are cases where having a view can keep you from having to change blocks of code, and in those cases go ahead and make one. But in many cases the view just adds another step to the update of the table since you end up having to care the change through the view. Thus creating views of everything as a policy doesn't really help.

The underlying problem (and this applies to all encapsulation) is that any substantial change to the data type or organization problems means there are flaws with the buisness or presentation logic that need corrected also.* If I discover that that table needs to be broken into two because part of it is actually a many to one relation to the other part, creating a view to hide the table split doesn't get me anything most of the time. That is because the fundamental change probably broke the buisness and screen logic tied to that table.

Using views for SQL tables will depend a bit on what languages you are using though. My experience is mostly with VB, along with a smattering of C and other languages. In a weakly types, objected oriented system you can probably gain more benefit from encapsulation because you are playing into the languages strengths.

Jay

* This should not be taken as saying it's a bad idea. Only that it isn't the panacea that some people make it out to be.
New I'm talking about in PL/SQL, and this isn't theory.
We have about 1M lines of PL/SQL here. I've seen this in action again and again: people don't use DML or views, individual references to tables get scattered all over the code base, and eventually we have to go in and do a clean-up that could have been avoided by concentrating table access in DML or a view. I've done three large ones this year alone. This is very practical advice borne of experience in a large code base.

Table changes don't happen that often. Those that do can easily be taken care of in views with SELECT foo.* and the like. The problem is the business logic changes. Unless you hide your table access behind dml procedures, you end up with SELECT and UPDATE statements all over the place. Change one little thing and all of a sudden you have to go touch 30 modules to change one thing.
Regards,

-scott anderson

"Welcome to Rivendell, Mr. Anderson..."
     Am I overly paranoid? - (mmoffitt) - (10)
         Not overkill. - (admin)
         Slight overkill - (JayMehaffey) - (4)
             More than security. Maintenance. - (admin) - (2)
                 In theory - (JayMehaffey) - (1)
                     I'm talking about in PL/SQL, and this isn't theory. - (admin)
             Sometimes you need a view - (orion)
         What's the application? - (ChrisR) - (1)
             While I'm on the subject - (ChrisR)
         Small intRAnet, overkill. Big public site, no. -NT - (tablizer)
         not at all - (cforde)

* "The futexes are also cursed."
* "But they come in a choice of three flavours!"
45 ms