|
|
|
|
|
|
by bob1029
6 days ago
|
|
|
The best way to cure a developer of their ORM dependency is to put them on a project with a complex OLAP / data warehouse component. OLTP workloads are reasonably well aligned with a lot of ORM patterns so it's more difficult to demonstrate the caveats here (but it's definitely still possible). The limitations of ORMs are much more apparent with OLAP workloads. ORMs simply cannot cope with provider specific requirements. All ORMs fall on their asses when it comes time to load any meaningful amount of data into the provider. The biggest consequence of forcing the RDBMS through a lazily evaluated object graph is that we've become decoupled from the mechanical realities of what the database provider can do. I had a client quickly drop the "you must use EF" commandment for the project I was assisting on once they saw how many rows it was loading per unit time without EF. "I didn't know that was possible". Many such cases. |
|
|
They think they can bolt on dashboards or make interface having basically OLAP in the same project and make it perfectly performant.
Here in this thread you have bunch of devs claiming ORM doesn’t work - it works perfectly fine for OLTP. Those devs who claim to be so great knowing SQL also don’t seem to understand that business people are throwing them under bus requiring OLAP stuff to be bolted on OLTP application.
To add on that business people expect OLAP views or dashboards to be „real time” — only after they have dashboard developed to look at it once a month or once a quarter.
What also pains me when I deal with devs is that they pick up synchronization jobs, well batch jobs are fine but then they are scolded by business that batch jobs are slow. Where we have all kinds of tech to make event driven updates to OLAP environments.