I’ve really only ever worked in web development. 90+% of web developers regard doing anything at all clever in the database with suspicion.
I’m considering working on a book about implementing business logic in Postgres, and I’m curious about how common that actually is.![]()
Well, there are 2 schools of thought:
- Put the business logic into the application
- Put the business logic into the database
Putting the business logic into the application can give you more flexibility around enforcing them. On the other hand, you also increase chances of inconsistency. There will likely be more than one application using reference tables like ADDRESS, ZIP_CODE, STATE, COUNTRY, QUARTER, ACCOUNT, CUSTOMER and similar. If there is a rule that a country must exist before you add an address in that country into the table, that can be enforced by a foreign key. Enforcing it within the application does 2 things:
- Move the rule code to the application server which is traditionally weaker than a database server. In other words, you are more likely to run out of CPU juice and memory on an application server than you are likely to run out of resources on the DB server.
- There is a possibility for inconsistency. Different applications can use different business rules for the same set of tables. That means that data entered by one application may make the table internally inconsistent for another application.
I am a big proponent of using foreign keys, check constraints and triggers to enforce business rules. I am also a big proponent of avoiding NULL values wherever possible. Database design is an art. CAD software used to be popular once upon a time, in a galaxy far, far away. Properly enforcing the business rules in the database itself makes the application more clear and easier to write.
Regards
-- Mladen Gogala Database Consultant Tel: (347) 321-1217 https://dbwhisperer.wordpress.com
