5 ms·

Well depends on the requirements, does it? I'm not suggesting you try to stick all your processing of all things inside a database, I'm saying put all critical

Well depends on the requirements, does it? I'm not suggesting you try to stick all your processing of all things inside a database, I'm saying put all critical processing of data stored in said database within it. Put all related data in the same database where is makes sense. Whatever data doesn't belong in that database can be merely referenced from it. > I can now query multiple databases This is another thing I disagree with. Wherever possible related data should be centralised to improve ACID properties and to create a reliable single "source of truth". I know this is unfashionable. with everyone claiming they need massive scale (which does cause some issues with this design), but much like microservices, it ends up being mostly busy work for programmers and related professions. Having said that, multiple databases, if largely orthogonal to each other present no real problems, and the same design concept is applied to each.

bvirb 3y ago
FWIW I think I agree with you if you consider "critical processing of data" data validations (IME via constraints, checks, triggers, etc...). I think where things can really go wrong is when the DB accepts anything the application layer thinks is valid. My favorite ORM says the same thing: https://sequel.jeremyevans.net/rdoc/files/doc/validations_rdoc.html#label-Data+Integrity https://sequel.jeremyevans.net/rdoc/files/doc/validations_rd... I wouldn't be surprised if more people agree with that as well, maybe just using different terms.
- dkjaudyeqooe 3y ago
  > I think where things can really go wrong is when the DB accepts anything the application layer thinks is valid. No, my view is the opposite of that: the database doesn't allow anything invalid to enter the database.
  - bvirb 3y ago
    Hmm well if I understand you correctly that's what I was saying as well: Things go wrong when the DB trusts the application layer (rather than doing its own validation) -- e.g. the DB should control what is valid data, not the application layer.

bvirb 3y ago

FWIW I think I agree with you if you consider "critical processing of data" data validations (IME via constraints, checks, triggers, etc...). I think where things can really go wrong is when the DB accepts anything the application layer thinks is valid. My favorite ORM says the same thing: https://sequel.jeremyevans.net/rdoc/files/doc/validations_rdoc.html#label-Data+Integrity https://sequel.jeremyevans.net/rdoc/files/doc/validations_rd... I wouldn't be surprised if more people agree with that as well, maybe just using different terms.

dkjaudyeqooe 3y ago
> I think where things can really go wrong is when the DB accepts anything the application layer thinks is valid. No, my view is the opposite of that: the database doesn't allow anything invalid to enter the database.
- bvirb 3y ago
  Hmm well if I understand you correctly that's what I was saying as well: Things go wrong when the DB trusts the application layer (rather than doing its own validation) -- e.g. the DB should control what is valid data, not the application layer.