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 Then see my response to Scott
However I find your argument for using stored procedures to be a non sequitor.

If you're using stored procedures as your single point of entry, then you are still vulnerable to developers using a non-standard tool to get around them. If you want guaranteed safety that can't be worked around, then you need to use triggers.

However once you get into the game of trying to protect yourself from your developers, you have a lot of other problems that follow directly. I'm not saying that in some environments you don't have to take that step. (In fact the larger the group, the more likely it is that it is a good choice to not trust freely.) But it adds a lot of immediate overhead and complexity when you do.

Cheers,
Ben
To deny the indirect purchaser, who in this case is the ultimate purchaser, the right to seek relief from unlawful conduct, would essentially remove the word consumer from the Consumer Protection Act
- [link|http://www.techworld.com/opsys/news/index.cfm?NewsID=1246&Page=1&pagePos=20|Nebraska Supreme Court]
New I did. And how?
If you're using stored procedures as your single point of entry, then you are still vulnerable to developers using a non-standard tool to get around them.

Only if the crack the db admin's password. If no one has access to the base data and no one has anything but select permissions on views, excluding a crack in the database engine/password for the admin/etc. how am I vulnerable to a developer "getting around" the stored procedures to manipulate the data directly?

In short, if you can only manipulate data via the stored procedures you have execute only permissions on, how are you going to get around that?
bcnu,
Mikem

If you can read this, you are not the President.
New Ah, good point
However how much that accomplishes depends on how much logic you have in the database layer, and who maintains it.

At my job, developers are responsible both for application code and stored procedures. Furthermore the stored procedures are responsible for rather little. Keeping update_dm accurate. Making sure that basic required fields are filled.

The business logic, authorization logic, and most data validation is kept in the application. Locking down the stored procedures buys you rather little.

Reversing this would require having a lot of development work move into PL/SQL. It also requires having a lot of development work move from developers to DBAs. And it requires a lot of tight integration during the development cycle between different people.

All moves that are going to significantly hinder productivity. And in the end what it means is that you still have to trust someone, you're just choosing to trust a different set of people.

Cheers,
Ben
To deny the indirect purchaser, who in this case is the ultimate purchaser, the right to seek relief from unlawful conduct, would essentially remove the word consumer from the Consumer Protection Act
- [link|http://www.techworld.com/opsys/news/index.cfm?NewsID=1246&Page=1&pagePos=20|Nebraska Supreme Court]
New Problem is rollback
With source code you can easily roll back to a previous revision. Once you break data, you're hosed. It's changing constantly, so you don't want to go back to last night's version. That's why the goal (in this context) of stored precedures is explicitly to make it harder for anyone to change how the application interacts with the DB. Worst case, a delete statement without a where.

So yes, you are just trusting a different group of developers. But hopefully the DBAs are more concerned with, and more trained in, maintaining the data than with adding features.
===

Implicitly condoning stupidity since 2001.
New That's only an argument for a wrapper
As soon as you have a wrapper that all access goes through, which prevents you from accidentally dealing with all of the data at once, then using that wrapper solves the "delete world" issue.

As for DBAs being better equipped to deal with data than development, I agree. Which is why I question making DBAs even more critical path on interactive development than they need to be. Pushing responsibility for more and more features and complex requirements makes them do a job they aren't supposed to be doing, and puts up roadblocks for developers.

Cheers,
Ben
To deny the indirect purchaser, who in this case is the ultimate purchaser, the right to seek relief from unlawful conduct, would essentially remove the word consumer from the Consumer Protection Act
- [link|http://www.techworld.com/opsys/news/index.cfm?NewsID=1246&Page=1&pagePos=20|Nebraska Supreme Court]
     Discussion topic: data-aware controls on forms - (admin) - (31)
         How active? Context? - (ben_tilly) - (3)
             Re: How active? Context? - (admin) - (2)
                 Are you really asking why Access is a bad idea? -NT - (ben_tilly) - (1)
                     Whoops. - (admin)
         Bad idea. - (mmoffitt) - (18)
             Implementation vs effect - (ben_tilly) - (17)
                 Consider what goes on in most such setups. - (mmoffitt) - (12)
                     Don't be sure about the surely - (ben_tilly) - (11)
                         Re: Don't be sure about the surely - (admin) - (4)
                             That I agree with - (ben_tilly) - (3)
                                 Why more? - (admin) - (2)
                                     Duplication of information - (ben_tilly) - (1)
                                         Must depend on what you're doing. - (admin)
                         I can't add much to what Scott said. - (mmoffitt) - (5)
                             Then see my response to Scott - (ben_tilly) - (4)
                                 I did. And how? - (mmoffitt) - (3)
                                     Ah, good point - (ben_tilly) - (2)
                                         Problem is rollback - (drewk) - (1)
                                             That's only an argument for a wrapper - (ben_tilly)
                 Er, what headaches? - (admin) - (3)
                     Depends how you're set up - (ben_tilly) - (2)
                         Re: Depends how you're set up - (admin) - (1)
                             More moving parts - (ben_tilly)
         always thought that all forms should be a view of the table - (boxley)
         Depends on the kind of data - (ChrisR) - (2)
             Mostly agree - (ben_tilly) - (1)
                 Love 'impedance mismatch' ! - (Ashton)
         You didn't specify stateful or stateless system - (drewk) - (2)
             Stateful. - (admin) - (1)
                 Then the issue is multi-column constraints - (drewk)
         Neat idea, but marginal in practice - (JayMehaffey)

Can anyone here PLAY this game??
61 ms