4 ms·
Not sure where an ORM would help in this case. If anything, it might get in the way sometimes (in terms of performance), as some queries might not be well optim
by brunoluiz 6y ago
Not sure where an ORM would help in this case. If anything, it might get in the way sometimes (in terms of performance), as some queries might not be well optimised.
But yeah, people shouldn't just "follow the hype". They should always ask why would use this and not that.
- 737maxtw 6y agoI think ORM might have been brought up because in many embedded DBs there is some level of language native bindings that eliminate the need for an ORM. A couple of examples that come to mind would be mnesia (KV store rather than SQL but still an example) or some of the SQLite providers for c# which give you their own mini orm (that you will have to refactor if you change out dbs instead of using sqlite with an orm from the get go) My preference for ORMs is still on the 'give me a SQL DSL and map my objects' side. Let me use SQL as SQL, give me convenience in interfacing with the DB. Complex features like object tracking tend to be nice up front but require extra diligence down the line to avoid pitfalls, and tend to be risky from a standpoint of composability. Sorry. Almost went on an ORM rant there.
- GordonS 6y agoI guess the thought behind using an ORM here was as an abstraction over the database/storage layer, so theoretically you could change switch out the database easily. In practice though, real projects often have to sidestep the ORM and handwrite SQL, sometimes using database-specific features.
- 3np 6y agoWhat I meant more specifically was a database-independent RBDMS ORM (e.g EF Core, sqlalchemy) - for cases when there aren't resources or need for separate db driver implementations.