3 ms·
> ORMs enable people who have no idea how RDBMS works to use them, which rarely ends well. In some cases, but the more frequent issue I saw back in the day was
by gedy 2y ago
> ORMs enable people who have no idea how RDBMS works to use them, which rarely ends well.
In some cases, but the more frequent issue I saw back in the day was the DBA making some really complex schema tuned for what they wanted, then an application trying to use the data in a pretty reasonable OOP manner (1 to many relationships, etc) and the DBA pissed they were using an ORM instead of their perfect SQL queries and procedures.
- sgarland 2y ago> the DBA pissed they were using an ORM instead of their perfect SQL queries and procedures. Tbh, I don't understand why this is seen as a bad thing. Correction: I know why it is (any changes are obviously going to be dramatically slowed down), but in the long run, I don't understand why people are against it. You wanted something done correctly, so you went to the SME for that specific field, and had them do it for you. Then you decided to throw it away?! Why are you bothering to ask them in the first place? > 1 to many relationships, etc I know this was just an example, but 1:M is a perfectly natural part of any RDBMS, and in no way requires an ORM to be done.
- gedy 2y ago> Then you decided to throw it away?! Why are you bothering to ask them in the first place? Usually this was a mismatch of mgmt or expectations. Hiring old school DBAs and letting them think they "own the data", while plopping them into a huge dev team changing the big SaaS features daily is a recipe for trouble. I don't fault DBAs per se, though I did work with some who wouldn't look outside their blinders at all.