3 ms·
ORMs are dangerous abstraction layers. SQLObject literally cost a previous employer of mine tens of thousands of dollars due to an obscure bug (needless to say
by mrshoe 17y ago
ORMs are dangerous abstraction layers. SQLObject literally cost a previous employer of mine tens of thousands of dollars due to an obscure bug (needless to say we switched to SQLAlchemy posthaste). Use them at your own risk.
Transparency is one more arrow in the quiver of the NoSQL camp. Throwing a SQL query at a black box and hoping that it figures out the most efficient way to execute that query is a scary way to access your data in a real-time application, especially when the query plan can change drastically based on what data is in the database.
I hope to never have to sleep with my hand on my phone waiting for Nagios text messages again. I'll take consistent data access performance characteristics, thank you very much.
- neilc 17y agoI'll take consistent data access performance characteristics, thank you very much. And if the distribution of your data changes, or you move the application to a new machine? Hard-coding a particular data access strategy into your application logic is like hard-coding assumptions about the distribution of your data and the relative costs of various operations. That's not necessarily the wrong choice, but it isn't a panacea, either. (If you're that concerned about query plan stability, many DBs give you the ability to force the optimizer to choose a particular query plan.)