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)

woz.posthaven.com

Post reply on HN
Print view View original

191–200 of 360 posts

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

#191

Post by dizzystar »

pmontra wrote: post #170
JamesBarney wrote: post #123

Earlier quoted context omitted.

4. The pain in the butt of writing and maintaining your own mapping code. 5. Type checking all your queries. 6. In code query composability. But I totally agree that ORMs are too leaky of an abstraction for 2 to be really useful, and that 3 is much harder than it appears to be.

+1 for these three points. But I'm really surprised every time people tell me they look at the schema as defined into the ORM instead of at the table in the database. I'm really jaw dropped the few times I know somebody doesn't even know SQL, only the ORM. Maybe they look at it as if it were the reaction of somebody that thinks you must know assembly if you want to program Ruby, Python or Node (I don't.) Still, if yo…

Woah, who are you interacting with that not knowing SQL is rare?

In my experience, nearly no one knows SQL, and the attitude seems to be that learning it at all is a waste of mental bandwidth.

On the other hand, I wonder if knowing none at all is better than knowing a little.

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

#192

Post by tkyjonathan »

niftich wrote: post #71
hamburglar wrote: post #64

Earlier quoted context omitted.

The DSL for your database is called SQL.

This is a quip that misses the parent's point. SQL isn't very composable, because its syntax requires infix notation, position-dependent phrases, separators, and the like. The abstract syntax tree of SQL is much more valuable than its syntax, which is essentially just a bad English serialization that resembles a natural language sentence. A DSL which manipulates queries and then produces syntactically valid SQL is tr…

Bare in mind that SQL was designed to allow non-technical business users to use it. In most offices, a vetern business user or BI person will know how to use SQL. So SQL is a DSL for relational deconstructing of data models that is conceptually simple enough for people to grasp.

Templating can absolutely save time and boilerplate, but adding a DSL over a DSL in the form or ORM may well be the problem.

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

#193

Post by dizzystar »

zkomp wrote: post #133
blaisio wrote: post #14

I think saying "Just use SQL" is probably a bad idea. You'll most likely end up implementing an ORM anyway, or you will end up with your model code mixed up everywhere with your views. I do think a lot of people use ORMs as a crutch, which sucks. Also, ORMs often provide too much abstraction, forcing people who actually know SQL to relearn how to do everything the way the ORM happens to like it. I should not have to…

No. You should really wind up with a DAL. Define some stored procedures for accessing and working on the data and use only stored procedures. No need for ORM, and no inline sql logic in your application code.

In some flavors of SQL, the query planner can't see in a stored procedure.

You can then start combining stored procedures. Great way to build a slow mess quickly.

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

#194

Post by pmontra »

dizzystar wrote: post #191
pmontra wrote: post #170

Earlier quoted context omitted.

+1 for these three points. But I'm really surprised every time people tell me they look at the schema as defined into the ORM instead of at the table in the database. I'm really jaw dropped the few times I know somebody doesn't even know SQL, only the ORM. Maybe they look at it as if it were the reaction of somebody that thinks you must know assembly if you want to program Ruby, Python or Node (I don't.) Still, if yo…

Woah, who are you interacting with that not knowing SQL is rare? In my experience, nearly no one knows SQL, and the attitude seems to be that learning it at all is a waste of mental bandwidth. On the other hand, I wonder if knowing none at all is better than knowing a little.

I expect that everybody with a degree knows SQL and I'm realizing that I could be wrong. Maybe sometimes I'm the only one in the room that knows it. I'll check it next time I'm at a technical event leaning on the backend side.

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

#196

Post by mattmanser »

rjbwork wrote: post #60
jeswin wrote: post #57

The post is from 2014, so I won't be too harsh here. The author's problem is with some specific flavors of ORM he's used, and shouldn't be generalized. Hibernate's expressiveness is/was crippled by Java itself. C# ORMs on the other hand are way better because they benefit from LINQ which adds queries natively into the language. Other more expressive languages have excellent ORMs as well. The objective of ORMs is not…

I've been writing C# professionally for ~5 years at this point. While I was initially quite infatuated with LINQ2SQL and EF, I have gone through the same situation as this fellow. I just write SQL in-line using Dapper for parameterization/data mapping, and use stored procs when I need some of the more arcane features of SQL (merges, CTE, etc).

I've been writing C# professionally for ~12 years at this point. I'm extremely comfortable with SQL, the first startup I worked for for 3 or 4 years in the mid-2000s did amazing things with it and was extremely anti-ORM. We did things like write SQL that would automatically get translated into XML, which we'd combine with xslt to create dynamic pages.

Yes, I've hit major problems with the EF (including one on Friday which was causing huge CPU and Mem spikes at the busiest time of our year). Yes, it's a PITA to debug the queries. Yes, it can do stupid things. Yes, some programmers can massively over-complicate it.

But you can prise the EF from my cold, dead hands before I give it up. ORMs rock. It's such a huge time saver as long as you KISS and accept you have to drop down to SQL sometimes.

And screw switching to Core until they've sorted out lazy loading. Lazy Loading can also screw you, but again, it's just wonderful when you use it right.

I've also turned into a huge fan of Code-First and Migrations, having been against them at first.

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

#197

Post by akvadrako »

avmich wrote: post #107
erikpukinskis wrote: post #79

Earlier quoted context omitted.

Ok, let’s break this down: > Good ORMs are there to automate the repetitive tasks of composing largely boilerplate DML statements, facilitating query composition, providing abstraction for database-specific and driver-specific quirks None of that requires an ORM. A simple query builder will suffice and it will be much easier to debug and much less error prone than an ORM. > providing patterns to map object graphs to…

> A simple query builder will suffice and it will be much easier to debug and much less error prone than an ORM. What's the difference? To me, an ORM is largely a query builder.

SqlAlchemy Core vs SqlAlchemy ORM

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

#198

Post by yason »

An ORM is both a more native way to represent data rows in the application and a convenient wrapper to automate much of dealing with SQL and result sets. But only a fool would wish to see an ORM as an object-based abstraction over SQL.

Dynamic languages such as Lisp and Python can often make-do without a specific ORM layer because it's easy to stash data into lists and dictionaries. If you can read rows from your result set into a list, make dicts or structs out of each row, and pass around that list or its entries to various functions you've just implicitly implemented a LRM: lispy relational mapping. But sometimes it just fits to create objects out of rows.

Simple wrappers will do for an ORM: the best kind always make it clear that you're just using a machinery to operate an SQL database instead of updating an object and then "saving" it back to disk in the end.

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

#199

Post by empthought »

mythz wrote: post #88

You can do both. My preference is to use "Micro ORMs" which provide a thin, light-weight, typed RDBMS-agnostic API around the most popular CRUD operations but also allow you to execute custom parameterized SQL when you need to run more complex queries but still let you use their fast mapping to populate clean POCOs/POJOs to take the tedium away from forcing you to become a manual bookkeeper from extracting the result…

I wonder why Git, CircleCI, test runners, and IDEs all have that “reject stored procedure code” logic built into them...

> doesn't benefit from the investments around maintaining source code, e.g. development environments, source control, CI, static analysis & compiler feedback, fast unit testing, REPLs, etc.

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

#200

Post by GFischer »

dizzystar wrote: post #191
pmontra wrote: post #170

Earlier quoted context omitted.

+1 for these three points. But I'm really surprised every time people tell me they look at the schema as defined into the ORM instead of at the table in the database. I'm really jaw dropped the few times I know somebody doesn't even know SQL, only the ORM. Maybe they look at it as if it were the reaction of somebody that thinks you must know assembly if you want to program Ruby, Python or Node (I don't.) Still, if yo…

Woah, who are you interacting with that not knowing SQL is rare? In my experience, nearly no one knows SQL, and the attitude seems to be that learning it at all is a waste of mental bandwidth. On the other hand, I wonder if knowing none at all is better than knowing a little.

Wow, I've never met a developer that didn't know SQL.

Even 1 year "learn programming fast" courses here in Uruguay have at least the basics. OTOH, Javascript is not taught in many courses so YMMV...

Post reply on HN