Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What ORMs have taught me: just learn SQL (2014)

wozniak.ca

Post reply on HN
Print view View original

301–310 of 654 posts

Re: What ORMs have taught me: just learn SQL (2014)

#301

Post by erik_seaberg »

jdsully wrote: post #289
JesseAldridge wrote: post #227

This was my position for a while. ORMs introduce a layer of magic which obscures what's actually going on under the hood. I decided I would just make raw SQL queries and handle mapping data explicitly. I quickly ended up with a lot of duplicated code. So then I thought, "Well ok, I should add a bit of abstraction on top of this..." I started coding some simple functions to help map the tabular data to objects. One th…

SQL is great if you will have multiple applications looking at the same dataset. E.g. An employee management program and a payroll program. In this case you should design a sane schema and mold the app around it. ORMs are terrible in this sort of world since they tightly couple the application to the data. But if you will only ever have one application anyway the abstraction of a separate schema is pointless.

A lot of people who believe only one app (or one language) accesses their org's datastore are mistaken. You have to take extreme measures to prevent ad hoc uses from popping up.

Re: What ORMs have taught me: just learn SQL (2014)

#302

Post by taffer »

fastball wrote: post #284
sjwright wrote: post #233

Earlier quoted context omitted.

Even more advanced programmer: writing the ‘boilerplate’ queries out manually takes barely more time than composing them in an ORM, means less indirection, saves me a major dependency, and encourages me to think intelligently about each query no matter how boilerplate they might seem at the surface. Super-advanced programmer: allowing my database structure to be influenced by the needs of an off-the-shelf ORM will ma…

What ORM do people use that influences the structure of their database? The ORM I'm currently using the most can do whatever I need with my Postgres DB. Also, the ORM allows me to specify models that are not only used for structuring the database, but also for validation of incoming JSON requests and easily serialize queries back to JSON.

> What ORM do people use that influences the structure of their database?

Hibernate and JPA encourage designing your domain classes first and then generate the DDL from that.

> Also, the ORM allows me to specify models that are not only used for structuring the database, but also for validation of incoming JSON requests and easily serialize queries back to JSON.

Postgres has great JSON support, does the ORM something with JSON that Postgres cannot do?

Re: What ORMs have taught me: just learn SQL (2014)

#303

Post by nullspace »

rmilejczz wrote: post #299
dymk wrote: post #246

Earlier quoted context omitted.

But you shouldn’t live with a hand-rolled pseudo ORM that stumbled into existence when there’s developed alternatives

An in house solution is almost always better than an external dependency

Hah... I’m probably falling for Poe’s law here, but anyways... there are certainly cases where in-house is better than external dependency - specifically when your team knows the tech domain better than anyone external can... but in general well-maintained (preferably open source with a community, or a well funded company) external dependencies are almost always better. They usually would have the years of fixing edge cases and features that you would inevitably run into if you were to roll ur own.

Re: What ORMs have taught me: just learn SQL (2014)

#304

Post by mst »

peteretep wrote: post #287

I used SQLAlchemy and would not reach for it again, but you can prise DBIx::Class from my cold dead fingers, so I think _which_ ORM is an important consideration too.

Every time I hear somebody say that I grin.

Fun things are coming soon btw, I finally figured out a couple of design problems that have been annoying me for years and the code is close to stable :)

Re: What ORMs have taught me: just learn SQL (2014)

#306

Post by mst »

djrobstep wrote: post #285
wvenable wrote: post #61

Earlier quoted context omitted.

ORMs let you drop into SQL whenever you need, usually in a way that is fully compatible with the model, so that's entirely false.

That's absolutely not true. With any of the ORMs I've used, as soon as you do something even slightly unorthodox like using a view, you're on your own.

Try http://p3rl.org/DBIx::Class in perl sometime.

If you're on your own using a view of all the simple shit, you're using an awful and pointless ORM.

Re: What ORMs have taught me: just learn SQL (2014)

#307

Post by smitty1e »

> My contention with ORMs is that, if you need to know SQL, just use SQL since it prevents the need to know how non-SQL gets translated to SQL.

I feel the same way about Wiki syntax as ORMs.

While SQLAlchemy is great for getting the DDL done, my SQL-fu is such that I wind up just using SQLAlchemy as a glorified connection manager while I construct the SQL strings directly rather than muddy up a sophisticated query by translating it into Python.

The same holds true for Wiki syntax. If I'm already proficient at HTML, it buys me precious little to use this 'easier' syntax if sometimes I'm in Redmine, sometimes I'm in Confluence, or wherever else I land.

Just let me code the page already!

Re: What ORMs have taught me: just learn SQL (2014)

#308

Post by philwelch »

erik_seaberg wrote: post #301
jdsully wrote: post #289

Earlier quoted context omitted.

SQL is great if you will have multiple applications looking at the same dataset. E.g. An employee management program and a payroll program. In this case you should design a sane schema and mold the app around it. ORMs are terrible in this sort of world since they tightly couple the application to the data. But if you will only ever have one application anyway the abstraction of a separate schema is pointless.

A lot of people who believe only one app (or one language) accesses their org's datastore are mistaken. You have to take extreme measures to prevent ad hoc uses from popping up.

Yes, yes, yes.

Why is this the case?

1. If you are doing anything interesting, people are going to ask questions about what you are doing, and the best way to answer those questions is going to be by querying your database.

2. One day you might want to rewrite some of your service/s, split them into microservice/s, etc. At that point, there will be a minimum of two services talking to your datastore: the legacy service and whatever you're replacing it with. I suspect any alternative to this arrangement will be an even worse idea, e.g. taking a deliberate outage to perform a likely-irreversible migration.

Re: What ORMs have taught me: just learn SQL (2014)

#309

Post by philwelch »

smitty1e wrote: post #307

> My contention with ORMs is that, if you need to know SQL, just use SQL since it prevents the need to know how non-SQL gets translated to SQL. I feel the same way about Wiki syntax as ORMs. While SQLAlchemy is great for getting the DDL done, my SQL-fu is such that I wind up just using SQLAlchemy as a glorified connection manager while I construct the SQL strings directly rather than muddy up a sophisticated query by…

In terms of wiki syntax, HTML is just so damned noisy that I'm fine with Markdown--but mostly because Markdown is fairly standardized and I don't have to learn a totally different syntax for everything.

Re: What ORMs have taught me: just learn SQL (2014)

#310

Post by shade »

pjungwir wrote: post #235
stickfigure wrote: post #208

Beginning programmer: ORMs let me write code without learning SQL! Intermediate programmer: ORMs just get in the way! SQL isn't that hard after all. Advanced programmer: I write a lot of SQL, but I use ORMs to cut out most of the boilerplate.

That's pretty much exactly how I feel. I gave a talk a few years ago about doing advanced SQL things in ActiveRecord [0]. The talk suffered I think from lacking a unifying idea and because I tried to offer something to the whole spectrum of experience (from "this is a join" to "this is how you can express a CTE/lateral join/window function in AR"), but the real unifying motivation/message was that with AR you can hav…

As a note - I've done a lot of SQL in C#, and Stack Overflow's Dapper[0] library is _fantastic_ for dealing with that. You can pass in all the SQL you like, or a stored procedure, and it deals with virtually all of the query parameterization and boilerplate around getting results out of the DB. It's saved me hours of tedium and typing.

It's the perfect micro-ORM. Eliminates boilerplate, gets out of the way otherwise.

[0] https://github.com/StackExchange/Dapper

Post reply on HN