Hacker News Reader

Part of the attraction to ORMs is that you just define your classes and essentially freeze-dry and thaw objects with a couple of lines of code.

[tangent] That's part of the attraction to NoSQL as well. You just serialize your objects to JSON or something else (probably already being done if you target the web). It's simple.

Back to ORMs, you can't avoid SQL wrappers at least to help w/ injections, and you probably want a layer that serializes/deserializes your objects as well. Once you've written that a few times it's boring so you abstract it. ORMs are pretty much inevitable when writing the common web app.

ORMs should borrow good things from SQL, like LINQ. Mainstream languages are better now than when SQL was created. I mean, it's not the exact syntax you like right? I prefer writing code rather than preparing and parsing strings. Plus if you ever decide to swap out the backend it's far easier when things are loosely coupled.

SQL is akin to JS in the browser in that you need a library to abstract away the implementation differences or you'll be tightly coupled to a specific one. Maybe you don't need to run on all backends simultaneously but options are always nice.

It all depends what the task is anyway though.

In contrast to client-side JS in case of SQL, there are at least some cases where limiting oneself to a single target can make sense. Not every application needs to run on a pletora of different databases.

In addition, over time, the official SQL standard got better and better (quite unlike EcmaScript which took a 10 year break and then returned with minimal improvements) and the databases began following the standard more and more as being standards compliant became a selling feature (which is also quite unlike the ecmascript case where not even the innovative browsers support all of the new features from ES5)

Hence, I would claim that the need for an SQL abstraction layer is way smaller than it is for client-side JS

Part of the attraction to ORMs is that you just define your classes and essentially freeze-dry and thaw objects with a couple of lines of code.

That's not unique to ORM. We don't use an ORM at Expat, yet all our objects still have .Load() and .Save() methods. I hope you didn't read my post to mean I advocate hand-writing your CRUD!

I think LINQ is a great example of needlessly re-inventing something that wasn't very hard in the first place. Especially since its syntax is so close to SQL. Why not simply write your ad-hoc reports in SQL itself and save a lot of trouble?

LINQ is far more useful than just as language sugar over SQL. The amount of boilerplate it removes is substantial for anything working with sequences. I actually havent used the SQL backend for it.

But since I often work with large collections of heterogenous data outside of a DB, I use it all the time to transform and filter collections in ways that would be very tedious in other languages. Libraries can get you some of the way there, but the language integration is what makes it so painless.

There's a lot of power and flexibility using a Model with LINQ. The strongly typed nature has saved me many times. When you alter a table and remove or rename a column you know exactly which queries are now broken at build time. If you were generating or hardcoding sql there's a chance that you hosed a lot of things and need to dig through all the code.

Dynamically creating queries is amazing in LINQ. Building them with strongly typed expressions is much better than messy string concatenation.

Again, that's not unique to LINQ. Drop a db column in the thing we use and the project will fail to compile until you fix up the references. And of course, if you're keeping your stored procedures in source control and recompiling them at build time (which of course you should), you'll know when you break them too.

As you say, strongly typed dataobjects are pretty cool. Regardless of how they interface with the database.

Part of the attraction to ORMs is that you just define your classes and essentially freeze-dry and thaw objects with a couple of lines of code.

The problem here is that you stop thinking about your data as an independent thing that must be designed for long-term persistence.

Code itself should be mutable, easily changed and modified. The on-disk data is the opposite of this -- it must be iterated on carefully, and its requirements must be clearly defined as to be supported in the long-term.

I'm very wary of tools that do not make it easy to explicitly and rigorously define the data model entirely separately from the object model that will be used to represent it in a specific version of one application.

I think tools like LINQ are valuable because they make working with relational algebra and projections cleaner, but do not abstract the fact that you are working with a long-term persistent data store that is not the same thing as your comparatively short-lived object graph.

Agreed. Personally, I really like SQL and whenever possible I'm going as much straight SQL skipping strange abstraction in ORM layers.

Performance wise too, nothing beats hand-optimizing queries rather than hoping that the ORM of your choice doesn't decide that the particular method of retrieving the total value of a specific order will need one query per line item plus manually calculating the total.

I've never understood why programmers don't love SQL the language.

Many programmers do love SQL. It's not a perfect solution, but it's better than most of the via alternatives.

Anyone that "hates" SQL should be forced to read C.J. Date's Database in Depth, after which, if they still hate SQL, it will at least be for the right reasons.

http://www.amazon.com/Database-Depth-Relational-Theory-Pract...

Hey, that's my joke:-) I've always imagined one of the old Star Trek episodes where Kirk says "Computer, select course where Klingons equal to zero" or something to that effect.

SQL, or rather the relational model, is great for what it does. A thorough knowledge of both is central to most of what I've done over the last many years.

But there are places where you don't really want named attributes with the names known beforehand, you want to generate new attributes, perhaps named on the fly, perhaps designated ordinally. The relational model doesn't really have room for this. The various flavors of SQL offer bolted-on ways to do this, incompatible & quite different. But it's a living...

I've been using SQL heavily for 12 years and mostly agree. The problem with SQL though is that it lacks abstractions. Any time you're forced to use dynamic SQL, the language has failed.

For example: suppose you want to write a SQL script that populates a database with dummy data. There's no way to do it without dynamic sql, since SQL doesn't let you parameterize table and column names.