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

What ORMs have taught me: just learn SQL

wozniak.ca

Post reply on HN
Print view View original

241–245 of 245 posts

Re: What ORMs have taught me: just learn SQL

#241

Post by Daishiman »

walshemj wrote: post #238
Daishiman wrote: post #224

Earlier quoted context omitted.

"Perfectly acceptable" doesn't reach the standard of type inference and feedback that you can get with modern IDEs for their supported languages. Visual Studio gives far more feedback for LINQ than SQL, and it's damn more useful for debugging queries.

I suggest you need to learn to code SQL and the procedural extensions for the dialect in use then - and OO is not the be all and end all of development.

I have over a decade of writing SQL, thank you very much. I still stand by my assertion and I there's no way I'll be writing procedural SQL for the use cases I deal with on a daily basis.

Re: What ORMs have taught me: just learn SQL

#242

Post by Ma8ee »

buro9 wrote: post #207

The one thing I like about ORMs (where I control the ORM): I can prevent any SQL query from being run that doesn't have a WHERE statement. Especially when dealing with anything that changes data, lack of WHERE is very dangerous. That said, I write raw SQL. It's the only way to get the performance. As an abstraction it's already great and I don't feel I need another abstraction on top of it. An example of the kind of…

I'm almost 100% certain that the function will be called only 25 times no matter which way you write the query. Not only is the select statement semantically at the end, but any engine worth anything optimizes this kind of things.

Re: What ORMs have taught me: just learn SQL

#243

Post by [deleted] »

buro9 wrote: post #207

The one thing I like about ORMs (where I control the ORM): I can prevent any SQL query from being run that doesn't have a WHERE statement. Especially when dealing with anything that changes data, lack of WHERE is very dangerous. That said, I write raw SQL. It's the only way to get the performance. As an abstraction it's already great and I don't feel I need another abstraction on top of it. An example of the kind of…

[deleted]

Re: What ORMs have taught me: just learn SQL

#244

Post by buro9 »

Ma8ee wrote: post #242
buro9 wrote: post #207

The one thing I like about ORMs (where I control the ORM): I can prevent any SQL query from being run that doesn't have a WHERE statement. Especially when dealing with anything that changes data, lack of WHERE is very dangerous. That said, I write raw SQL. It's the only way to get the performance. As an abstraction it's already great and I don't feel I need another abstraction on top of it. An example of the kind of…

I'm almost 100% certain that the function will be called only 25 times no matter which way you write the query. Not only is the select statement semantically at the end, but any engine worth anything optimizes this kind of things.

You are 100% incorrect when it comes to Postgres. Feel free to try it out.

Re: What ORMs have taught me: just learn SQL

#245

Post by anko »

gaius wrote: post #235
anko wrote: post #67

Earlier quoted context omitted.

I think the problem is not that an ORM often influences schema design, it's that Relational Databases/SQL often influence application design. People complain that an ORM isn't using a relational database effectively. The greatest contribution of the rise of ORMs is that relational databases are hard to use properly. Bring on the ACID compliant document databases.

No you have it backwards. RDBMS are as they are because maths (relational algebra and calculus). There is deep theory behind doing things this way. You can put data in without needing to know how it will be accessed and used (and vice versa). NoSQL just doesn't have this rigor. You have to tightly couple what creates the data with what consumes it. THAT is just begging for trouble down the line.

That is absurd. Saying that using a certain data access api tightly couples you to it is as crazy as saying using variables tightly couple you to ram (and using ram is obviously bad!).

I honestly don't think you understand what tight coupling means.

You have data. To access the data you use an api. SQL is forcing you to use a generalised API, which is very old, hard to use and more importantly; hard to test.

If you actually want rigor in your SQL API, you use stored procedures. So now you're maintaining two languages (SQL and stored procedures) in addition to your application language.

For me, for most things, I just write a webservice which talks to whatever database I want. That's the API I expose. Anything can consume the API as long as it follows my RESTful spec.

With this architecture, I; 1) Don't have to struggle with SQL, making development faster. 2) Don't need a DBA making development cheaper. 3) Get to write in one language making testing a lot easier, which in turn makes quality higher. 4) can scale easier, picking whatever data storage characteristics are important to me.

Lastly, saying that NoSQL just doesn't have this rigor really makes me wonder what you think of google's bigtable or amazon's simpledb?

Post reply on HN