Win a copy of Re-engineering Legacy Software this week in the Refactoring forum
or Docker in Action in the Cloud/Virtualization forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

SQL antipatterns: decisions on business logic

 
Gian Franco
blacksmith
Ranch Hand
Posts: 979
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Bill,

I'm not sure if this is a good question given that the title
of your book mentions SQL explicitly...but anyway...

Does your book also elaborate solutions concerning application
design in general, but in particular those decisions regarding
for example whether to put business logic in the database
(e.g. with PL/SQL) or not, when to do so, when not...etc.
 
Bill Karwin
author
Ranch Hand
Posts: 32
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
My book tries to identify common blunders. I didn't write about the merits of using stored procedures in my book, because I consider neither using stored procedures nor using application code to be a blunder. As developers, we should use the language and environment where we are the most productive. So it depends on the tools you have available, and the skills and experience of the individuals in your team.

There are those who say every database interaction should be through a stored procedure interface. There are others who insist the database should be a dumb persistence store, and all constraints and domain logic should be implemented in application code. I think both of these positions are too inflexible, too unequivocal.

I'm a proponent of using referential integrity constraints (foreign keys) in the database, and of using these constraints to implement cascading delete and cascading update. But on the other hand, I seldom write triggers or stored procedures unless there's a significant advantage for the sake of logic or performance.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic