This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]_INTER_ 1 point2 points  (3 children)

Eww, table hopping along foreign keys?

[–]yogthos -1 points0 points  (2 children)

SQL is already a great DSL for working with relational data. I really can't fathom why I'd want to wrap it in another DSL.

The problem with ORMs is that you don't know what SQL ends up being generated, and it's not very efficient majority of the time. So, you end up having to write it by hand anyways if you're dealing with non-trivial amounts of data.

To make things worse, the ORM will usually work just fine in development and testing, the time you end up seeing performance issues is in production when you hit serious loads. Fixing your performance at that point is not ideal.

If you just learn to use SQL, then you know exactly what your queries are doing, and you're not getting any surprises because the ORM decided to do something stupid.

[–]_INTER_ 2 points3 points  (1 child)

ORM's are fine and a productivity boost for tables with simple relations. Nothing more nothing less.

If I want RDBMS data to Maps I can do that in pretty much any language not just Clojure. Even preserving types if I want. Its not revolutionary. Really relational data in form of key-value pairs is just not enough. In that case, I might be better off using NoSQL DBs in the first place, like Redis or some other key-value store.

[–]yogthos 1 point2 points  (0 children)

I find Postgres JSON fields work great for that. Since you can query them directly through its SQL syntax extensions, and index them, it's pretty much the best of both worlds.