Live data from Hacker News

What ORMs have taught me: just learn SQL

wozniak.ca

51–60 of 245 posts

Re: What ORMs have taught me: just learn SQL

#51
post #8

In Django, for me the killer feature of the ORM is that it's (mostly) database agnostic, which means that you can use Postgres in production and in-memory sqlite when testing, which makes testing a gajillion times faster. If you start writing custom SQL you have to introduce horrible bodges to work with whatever database is in use.

Database portability is a poor argument for using ORM in my opinion. In the real world, most apps don't change database engines during their lifetime. You wait for the rewrite and then you pick a new engine. If you stick to ANSI compliant SQL, you should be fine when porting over databases. It's not perfect but it'll get you most of the way.

> Database portability is a poor argument for using ORM in my opinion.

Especially since SQL abstraction layers exist that are not also ORMs (e.g., Sequel for Ruby -- which, yes, has an ORM included, as well.)

> If you stick to ANSI compliant SQL, you should be fine when porting over databases.

This would be true if most real RDBMSs implemented a superset of any particular ANSI SQL standard, but that's not actually the case. Most real SQL-based RDBMSs support different subsets of the standard plus different extensions, so its not all that common that non-trivial code ports well without conversion.

Re: What ORMs have taught me: just learn SQL

#52
post #7

Here's a thought experiment. Lets say we lived in a world without SQL and the default way to talk to DB's was through an ORM.... And then someone came and said: "I created this concise and super flexible language for querying data." Would people want it? I think they would, and we'd see tons of articles about vast forests of objects being replaced by small snippets of SQL.

> And then someone came and said: "I created this concise and super flexible language for querying data." Would people want it?

Sure, but if we're going to imagine that, hopefully it looks a lot more like a D [1] than like SQL.

[1] As described in The Third Manifesto, http://www.dcs.warwick.ac.uk/~hugh/TTM/TTM-2013-02-07.pdf

Re: What ORMs have taught me: just learn SQL

#53
post #49

ORMs are great for simple CRUD operations. As soon as you want to do anything mildly complex or desire efficiency, you need to write SQL. As long as the ORM helps me with the former and gets out of my way for the latter, I'm totally happy to utilize then.

I agree with this, but SQL is also great for writing CRUD, and 99% of database interaction is CRUD.

Re: What ORMs have taught me: just learn SQL

#54
post #44

Over and over I keep finding that just an ORM is not enough, but raw SQL is hideous in a different way. ORMs map nicely when you are indeed modifying objects, but somethings don't map well that way. So don't map them that way! What we need is a low level abstraction layer alongside the ORM. The main problem with raw SQL is that what you really want is a genuine programming language. You almost want programmatic acces…

Take a look at my library, swigql[1]. You can create a base query and then extend that query however you want via template inheritance. [1] https://github.com/civitaslearning/swigql

My personal opinion on such libraries is that they're cool, and I think they do make life easier but they're just a more advanced form of string concatenation. No notion of SQL types, syntax or structure. To follow the template analogy, a low level abstraction library allows me to not only change the variables but also change the template programmatically. And not by concatenating more stuff onto the template either :P

Prepared statements, by contrast, are also a form of string concatenation. And they have some understanding of type and syntax, but only because they learn them from the server:

http://www.postgresql.org/docs/9.2/static/sql-prepare.html

http://dev.mysql.com/doc/refman/5.0/en/sql-syntax-prepared-s...

Re: What ORMs have taught me: just learn SQL

#56
For long time, I have no idea that SQL & OO are not friends. I work in a language where such problems don't exist. And it have nice ways to move data between tables and data structures and objects (For example: SELECT..INTO Array NAME).

Is FoxPro. Even the stored procedures were foxpro, all along the stack, from UI to inner DB actions. Is a shame that this kind of programming is "lost" today.

This is kinda like work with the postgresql main language everywhere, but the language is not half-powerfull. You don't need a "database" language and a "application" language. In fact, the whole experience was very good, and even let some people to do his own apps (kinda like Acces) because the approach was not intimidating, like VB, C or Python is (ie: Torwards do database apps).

So in short: Back them we don't use a ORM, we don't need it, we still have nice syntax and helpers. I still try to backport some of this to my own code, but the SQL is SOOOO restrictive that the effort stop fast.

Re: What ORMs have taught me: just learn SQL

#57
post #49

ORMs are great for simple CRUD operations. As soon as you want to do anything mildly complex or desire efficiency, you need to write SQL. As long as the ORM helps me with the former and gets out of my way for the latter, I'm totally happy to utilize then.

I agree with this, but SQL is also great for writing CRUD, and 99% of database interaction is CRUD.

That may be true by frequency of query execution, but not by frequency of appearance in an application.

Re: What ORMs have taught me: just learn SQL

#58
Like anything, you always need to learn at least what is going on one layer below the abstraction layer you are working in. So if you are using an ORM you need to learn SQL. If you are using ruby or python you need to learn what the interpreter is actually doing. If you are using C you need to know what the machine code is doing, etc.

Re: What ORMs have taught me: just learn SQL

#59
post #30
post #10

Earlier quoted context omitted.

There is another theory which states that this has already happened. See: ISAM databases as found in COBOL programs.

The problem was SQL got standardized, and became static. There is so much room for innovation in the database language space, but that would mean breaking compatibility with the SQL standards...

> The problem was SQL got standardized, and became static.

SQL hasn't been static since it was first standardized, much like C++ hasn't. However, there's may be a good case that many of the central, underlying design decisions that are by now difficult to extract without tossing the whole thing overboard could have been done better with the benefit of several decades more experience in PL design and understanding of how databases are used.

Re: What ORMs have taught me: just learn SQL

#60
I haven't seen anyone say this yet but it seems that this guy used the wrong tool for the job he was doing. He needed to get off of the ORM long before his attribute count got up to 600. ORM is not the right tool to use for his problem. He was trying to fit the glass slipper onto the giant ugly step sister and then wrote an article about how all glass slippers are garbage.
Post reply on HN