3 ms·

Oracle, DB2 or SQLServer? >The reducing load on the database claim is nonsense since the application would have to query the database anyway and less efficient

by count 3y ago

Oracle, DB2 or SQLServer? >The reducing load on the database claim is nonsense since the application would have to query the database anyway and less efficiently that the database could, avoiding numerous round trips between application and database. Ah, but by shifting the logic to the app, I can now query multiple databases (of disparate types even! vector, document, object, relational, etc.), each optimized for its particular data and query types and combine the result. That's very....not easy in stored procedures. I can also scale out different tiers of the application based on its needs (heavy compute, gpu-based, etc.). How do you do that when everything is a stored proc on a database?

dkjaudyeqooe 3y ago
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.

by count 3y ago

dkjaudyeqooe 3y ago

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.