Hacker News Reader

Comment by ignu | Hacker News Reader

"The birth of ORM lies in the fact that SQL is ugly and intimidating"

The notion that people steer away from SQL because it is intimidating is absurdly ignorant.

The communities that embrace ORMs and NoSQL are the ones who are learning and creating new things all the time. No one's first language is Ruby, they didn't learn node.js in college, they didn't take an (N)Hibernate certification course. They learn in their free time!

Meanwhile, if you were good in SQL 12 years ago then you still are today!

Smarter people than me have written on these subjects, but for me, the answer is simple. As Fowler says, the most pervasive smell in software is duplication. If I litter my code with all the CRUD SQL (even worse with sprocs that contain column sizes) then my software is quite brittle.

View on HN

If you little all your code with CRUD, your code is horrible indeed.

If I hard code filenames all over my code, I also have horrible code. This doesn't mean that files and file names are a problem or that they caused duplication.

The normal (I hope) practice is to this in terms of transactions or activities and create functions that wrap those activities. SQL should only live within those functions that provide a logical interface to the DB. Its called TAPI or XAPI (transaction API). Think of it as your own domain specific ORM.

> SQL should only live within those functions that provide a logical interface to the DB. Its called TAPI or XAPI (transaction API). Think of it as your own domain specific ORM.

Which is generally repetitive and full of duplication, exactly the thing that drives people to use ORM's in the first place. It doesn't matter that it's isolated into a separate layer, it's still more manual work than an ORM.

It is more work than ORM, but if efficient access to data is an important part of your application, it seems to be extra work that brings benefits. At least that has been my experience.

I'm not clear on why this layer has to be repetitive and full of duplication.

> I'm not clear on why this layer has to be repetitive and full of duplication.

Let's say you have a database with 100 tables in it. How many insert statements might there be, just a rough estimate, in your layer of functions? My ORM has 1. At the most basic level, a simple ActiveRecord ORM has 1 insert, 1 update, 1 detele, and 1 select statement. How many are in your typical app? If it's more than 1 of each, then it's duplication.

I haven't written an insert/update/delete statement in years because I don't need to. When I need a fancy select that's an aggregate of several tables, I write a view and then map it into a list of objects with the ORM. This is virtually no work, I spend all of my time working on the actual problem at hand and virtually none marshaling data in or out of the database.

I'm totally not following here...

How can multiple insert statements be considered duplication if they are inserting different things to different tables? My apps have multiple insert statements. They also have multiple calls to "print". Do you count that as a duplication as well?

We can continue the discussion by email if you prefer. It is interesting to me, but we may be getting off topic.

> How can multiple insert statements be considered duplication if they are inserting different things to different tables?

Because they're all the same pattern of code. Whenever you see common patterns, you're missing an abstraction that can greatly simplify things.

Why would I write 100 different insert functions when I can write one that generates itself dynamically using reflection over whatever object it is given? You only need one insert statement, it just needs to be smarter rather than static hand written code.

You need only tag your objects with a little bit of metadata using attributes to give a generic insert/update/select/delete everything it needs to dynamically generate parameterized statements on the fly for every table in the db that you use. Put simply, the only thing I need to do to use a User table in an app is write something like the the following...

    class User : ActiveRecord<User> {
        [PersistentString(MaxLength=50, Required=true)]
        public string UserName;

        [PersistentString(MaxLength=50, Required=true)]
        public string Password;

        [PersistentString(MaxLength=5000)]
        public string About;

        public User(){}
    }

And I'm done, I can now Find, FindAll, Save, Delete, Count, Sum, Min, Max, Avg, Count, Exists, Not Exists, etc... on those records without writing a line of SQL. All of these methods are inherited from the superclass and work on the table User. The same thing applies to view and stored procedures.

CRUD duplication is fine, because if you're doing it right it's all generated from the schema at build time. It'll have columns sizes in the stored procedures, because those are the sizes of the columns as of last time you updated the schema.

Rule One is "Don't touch the CRUD".

The code you write touches the auto-generated base classes that wrap the auto-generated CRUD. It never need concern itself with the duplication you speak of.

Reply on news.ycombinator.com