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 I'm coming down on the side of your data integrity comment
This is coming up because we contracted out development of an integration with another app. They wrote a process to sync data between our schema and the new app's schema. When they checked it in, they were using raw inserts instead of some existing stored procs that did additional housekeeping.

If we had proper constraints in the DB we could have had cascading updates and the procs would have been unnecessary, or at least the inserts would have failed immediately instead of creating inconsistent data.

So it's not necessarily procs that I want, it's that somehow the data integrity should be managed in the DB, so there's no way for a developer to write code that breaks our data.
--

Drew
New Sounds like a management problem.
Surely the documentation told them they should use the stored procedures instead of direct inserts. It sounds like your architect is correctly upset, but possibly for the wrong reason.

Data integrity can be done down in the database, if the app knows how to cope when the database says "No". It can be up in the app if it can cope with integrity broken from below (e.g. from an explicit insert).

Wade.
New You think?
What if I told you there is no documentation of the requirements? How surprised would you be?
--

Drew
New Not surprised at all.
Which means that those complaining about using Inserts instead of the not-at-all-documented stored procedures kind of don't have all that much to complain about! :-D Though I'd be surprised if they were to take that to heart.

Wade.
New Someone's going to be writing something that deals with integrity.
So there's always a way to write code somewhere that breaks your data. :-) Note that I view DDL as code as well.

If you insist on using SPs to manage integrity then you have to restrict access to the underlying tables. Whatever the problems with specification, they shouldn't have been able to do what they did. Two routes into that data were provided and they just happened to pick the one that blew things up.
Regards,
-scott
Welcome to Rivendell, Mr. Anderson.
     Are stored procs "hiding functionality"? - (drook) - (23)
         wag, the same as a shared library, you dont know where it came from -NT - (boxley)
         Interesting question. - (Another Scott) - (1)
             Better to manage that sort of problem through services - (malraux)
         Depends on how they're managed. - (malraux) - (10)
             And don't forget about sp's providing better performance on the database. -NT - (mmoffitt) - (9)
                 That depends - (malraux) - (8)
                     For OLTP applications, I disagree, with MS Sql Server anyway. - (mmoffitt) - (7)
                         Performance is the least of my concerns at this point - (drook) - (1)
                             Until it isn't any more. :-) - (malraux)
                         Performance != throughput - (malraux) - (4)
                             Interesting - (drook) - (2)
                                 I've looked at DB scale out, though not recently. - (static)
                                 Eventually the amount of work exceeds the capacity of a single machine to do it - (malraux)
                             sure, lets take the speed out of the cpu and replace it in multiple small connected units, :-) -NT - (boxley)
         Implementation detail, someone else's problem. - (pwhysall)
         Who is responsible for what? - (crazy) - (5)
             I'm coming down on the side of your data integrity comment - (drook) - (4)
                 Sounds like a management problem. - (static) - (2)
                     You think? - (drook) - (1)
                         Not surprised at all. - (static)
                 Someone's going to be writing something that deals with integrity. - (malraux)
         Re: Are stored procs "hiding functionality"? - (mvitale) - (1)
             I used utPLSQL in a former life. - (malraux)

Maybe this thing does have "macros".
62 ms