31–40 of 48 posts
I always admired micro ORMs like Dapper. The hard (or at least time wasting or error prone) tasks are: - mapping results to app entities or projections - input sanitization - dynamic query building - connection pooling and transaction management - supporting multiple SQL dialects with one code base After many years of experience with Hibernate, NHibernate, Entity Framework, and a plethora of other full ORMs, I absolu…
In the 1980's we had C/C++/Ada/Pascal/Fortran/Assembly/Lisp. Since the 1980's the languages have exploded. But we still only have one language for querying a database. And a kinda not very good one at that. Why is that? https://www.holistics.io/blog/quel-vs-sql/ One could argue that ORM's are the alternative language people are looking for.
Why is there still a C:\ drive in personal computers, and an invisible device called PRN in every directory?
I always admired micro ORMs like Dapper. The hard (or at least time wasting or error prone) tasks are: - mapping results to app entities or projections - input sanitization - dynamic query building - connection pooling and transaction management - supporting multiple SQL dialects with one code base After many years of experience with Hibernate, NHibernate, Entity Framework, and a plethora of other full ORMs, I absolu…
Drizzle [1] comes pretty close the last time I checked. [1]: https://orm.drizzle.team
Earlier quoted context omitted.
> resort to raw SQL I'm the opposite, I would rather write SQL than "resorting to" ORM queries, which is why my favourite libraries are aiosql[1] in Python, Hugsql[2] in Clojure and similar: write the queries as SQL in .sql files, which then get exposed as functions to your code. [1] https://nackjicholson.github.io/aiosql/ [2] https://www.hugsql.org/
Those tend to be great until two words come into play: Dynamic SQL.
I’ve written aiosql functions that use dynamic SQL (via plpgsql) just fine.
> Will you actually need to change between fundamentally different database technologies? Yes, use sqlite locally for development and run PG in prod. Unit tests can now use the db and finish in milliseconds. You get unit tests that have the power of integration tests and don't have to ever stub out your db. I use Redislite for the same thing. I'm of the opinion that SQLite is the musl of the SQL world. By deciding th…
Earlier quoted context omitted.
Are they worse? The popularity of them has exploded like programming languages from the 80's to now. One might say that if SQL was so great there would be no ORMs -- because there would be no need. The ORMs, if anything, are a symptom of the larger problem that is SQL.
> One might say that if SQL was so great there would be no ORMs It's not like the ORMs exist without SQL. Their primary purpose is to provide a consistent interface between different flavors of SQL so the application developer doesn't need to care what database they're using. For example, delimiting object names in Mysql uses ` and in Postgres uses ". The ORM will ostensibly have different adapters which take care of…
That's because TINA: There is No Alternative.
As someone who always prefers native SQL over ORM queries, I'll add a couple of counterpoints. Most IDEs provide intellisense/validation of ORM entities, vs treating SQL like a raw string. ORM entities also make refactoring and impact analysis slightly easier. Despite those benefits, I generally find ORMs a pain for anything besides the most basic queries.
My simple rule for databases is that if you are not actively querying on it, it doesn't need to be a separate table or column. Use the YAGNI rule here and you'll be better off. The classic example here is persons that have addresses and phone numbers. Most applications have no requirements to query on most of that: street name, postal code, phone number, etc. Less tables and columns mean simpler joins (or better, no…
Maybe, but not sure you’re getting much from that trade. If you’re not querying often, then performance shouldn’t be an issue. Modern hardware/dbms can definitely handle a couple of joins without blinking. So you’ve mostly lost flexibility. Also having to redo later will wipe out the time savings of many, many simplifications. Not to mention doc and teaching reqs you’ve added to new devs.
Comments here make me wonder if I've just been spoiled by ActiveRecord. Not that I use it for all queries but 1) it's rare that I have to resort to raw SQL and 2) it kindly gets out of the way when I do.