4 ms·

This is true, and another thing about state is also true - relational databases are much better suited to handle state cleanly and to minimize the amount of it

by ajuc 5y ago

This is true, and another thing about state is also true - relational databases are much better suited to handle state cleanly and to minimize the amount of it than programming languages (except maybe prolog). Especially OOP languages are bad at state minimalization. For example there's no commonly used equivalent to normal forms in oo. There are no indexes and no materialized views. The funny effect is - if you want to minimize state and you're serious about it - keep everything you can in database and make a 2-layered (relatively thin) client <-> relational db architecture. With stored procedures. We were there in 90s and we moved away because web and OOP became fashionable. So we took our clean, normalized, minimal state from db and made it messy and complicated with ORMs to satisfy OOP gurus :)

kaba0 5y ago
I don’t think ORMs are fair choice as prototypical examples of (good) OOP. But I agree that having data (record) primitives is very important in some given domains (and that relational databases are really powerful). There are other cases as well which are not as data-oriented though.
- ajuc 5y ago
  ORMs were the OOP way in 00s and 10s.
hardolaf 5y ago
People also moved away from that paradigm because databases are slow. I work in the world of optimizing TLP level communications over PCI-e buses. To me, a database access is already in the world of "why bother?".
- ajuc 5y ago
  We moved from DB <-> Front end to DB <-(ORM)-> APP SERVER <-> FRONT END I don't think it's any faster :)
  - t00 5y ago
    Simple reason - add local or distributed cache to the app server, scale it along front end horizontally and you can handle several orders of magnitude more traffic.