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

Welcome to IWETHEY!

New Slight overkill
I would consider making views for all selects a bit of an overkill. There are good reasons to make views for some tables, but trying to do every select that way isn't worth the effort.

Updates and inserts are a different story. Doing all updates and inserts through stored procedures can make sense if you have strong security requirements.

Of course it also depends on what the system is for. If your building an public web application then overkill is called for. If it is an internal application then you may not need to go the overkill route on stopping intentional hacking. And if your working on an application where the users are not required to change their passwords from the default 'password' then you might as well screw the security.

Jay
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..."
New Sometimes you need a view
at the law firm I worked at, we had an extensive database. I created some Views for various information that was stored in many different tables and required a lot of joined tables and tricky indexes. It was easier to create a view on say like Employee Info or Docket Info which referenced 12+ different tables but returned one huge recordset. Then the view can be accessed by stored procedures and filters put on them. It made maintaining the various stored procedures much easier.

But I agree, views on everything may be overkill.



"Lady I only speak two languages, English and Bad English!" - Corbin Dallas "The Fifth Element"

     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)

What's the Queen Koopa like?
66 ms