Timeline for Direct database manipulation an anti-pattern?
Current License: CC BY-SA 3.0
14 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 21, 2014 at 13:00 | comment | added | JeffO | @jwenting - This answer offers some legitimate disadvantages and putting 100% of business logic in stored procs can be a bad idea. It also recommends how "likely" any of the pitfalls may occur, so I'm not interpreting this as a concrete never, ever use a stored procedure. | |
| May 20, 2014 at 13:11 | comment | added | jwenting | @JeffO yes, and that means nothing. The answer is still invalid, as it claims that using stored procedures for business logic is universally wrong. It isn't, there are places where it's very valid. And remember there are many desktop applications that use a central database rather than a local one. Of maybe you're too young to have heard of "client-server"? | |
| May 20, 2014 at 12:07 | comment | added | JeffO | @jwenting - All the world is not a website or enterprise level system. There are uses where the database only serves a particular application like a desktop app. The app has the rights to everything. There is no DBA and nothing in the database the app shouldn't have complete control over. | |
| May 20, 2014 at 7:57 | comment | added | jwenting | sorry, but your "answer" is completely bogus. There are very good reasons to centralise your business logic in the database, and allow access exclusively through stored procedures and non-updatable views. Safeguarding data integrity comes to mind as the prime reason, and is vitaly important. | |
| May 19, 2014 at 21:04 | comment | added | jordan | I agree that even triggers shouldnt be used if it is really there to handle some complicated thing (i.e. business rule). | |
| May 19, 2014 at 20:47 | comment | added | Greg Burghardt | Triggers work well until a table gets altered 5 triggers deep through a custom view. When something goes wrong, you'll spend 3 months looking for the problem only to realize a chain reaction of triggers is to blame. It's like a 14 car pile up on the freeway during rush hour. It's hard to tell who's to blame. | |
| May 19, 2014 at 20:37 | comment | added | DudeOnRock | @jordan: Great point! | |
| May 19, 2014 at 20:31 | history | edited | jordan | CC BY-SA 3.0 |
deleted 2 characters in body
|
| May 19, 2014 at 20:31 | comment | added | jordan | You should also evaluate the possibility of whether the need to update many tables when you insert an object in one table is really some business rule in disguise or something. For example suppose you have a table for audit history or something. | |
| May 19, 2014 at 20:27 | comment | added | DudeOnRock | @jordan: Thanks! I don't know much about triggers. I'll spend some time and investigate. | |
| May 19, 2014 at 20:26 | comment | added | jordan | Would triggers or other constraints work for that case? | |
| May 19, 2014 at 20:24 | comment | added | DudeOnRock | I agree that there should not be any business logic in the database, but lets say I have a normalized DB and inserting an object into the DB requires updating several tables. In my opinion the business logic should not have to know that x number of tables need to be updated... | |
| May 19, 2014 at 20:24 | comment | added | Doc Brown | There are very different schools of thought about this. Some folks use a specific database system as strategic platform and use stored procedures for keeping business logic centralized. Others want to avoid a vendor lock and prefer not to use any kind of stored procedures at all. So saying "no business logic in the database, regardless of the system you are building" could trigger a holy war. | |
| May 19, 2014 at 20:22 | history | answered | jordan | CC BY-SA 3.0 |