top | item 80605

(no title)

HiddenBek | 18 years ago

This app had something like 200 different tables, with 20 to 50 columns in most tables. Update and insert statements were 5 - 10 lines long, and there were hundreds of the things. There was some JDBC cruft too, but the vast majority was SQL.

This was an extreme case of course, and was mostly the result of bad design, but I haven't come across a database backed application that couldn't be trimmed down with some sort of SQL generator. SQL is fine for simple queries, but, for me at least, has always gotten unmanageable in the long term. Need to select, insert and update the same columns? Duplication. Conditionally group by or order by different fields? Duplication. Decide after the fact that you need to support multiple databases, or eager and lazy loading? There goes the weekend, and probably most of next week.

You could manage all of the above with some sort of home grown solution, but a good ORM just makes everything so painless. I was strongly anti-database for years, yet I now often find myself using ActiveRecord when a flat file would do, simply because ActiveRecord is easier.

Of course, that's just me. SQL and I were never a good fit, and I'm glad to be mostly rid of it, but I'm sure others have had different experiences.

discuss

order

fauigerzigerk|18 years ago

Streamlining SQL code generation and mapping tables to objects are two entirely different feature sets in my opinion. 90 % of the reduction in code you're talking about stems from the former whereas 90 % of the complexity of ORMs stems from the latter. That's why I prefer a leaner toolset to interface with the database.