(no title)
HiddenBek | 18 years ago
It really depends on what you're doing, but I can't imagine why anyone would want to write SQL by hand. If you really want simplicity, don't use a database at all.
HiddenBek | 18 years ago
It really depends on what you're doing, but I can't imagine why anyone would want to write SQL by hand. If you really want simplicity, don't use a database at all.
nostrademons|18 years ago
I moved from PHP/PearDB to Java/Hibernate3.0 to Python/DBAPI, and found that Java was by far the most verbose. Even with Hibernate annotations, I was writing more than twice as much code for equivalent functionality.
Perhaps the difference is that you have business objects defined already, and so the cost of Hibernate is only the annotations? My PHP and Python programs keep the SQL and drop the objects, and so they end up with incredibly tiny data access layers.
SQL is optimized for writing data access queries extremely concisely, so I don't see how it could end up as more than 50% of the codebase, unless you're using an exceptionally verbose database library (JDBC certainly counts) or your codebase is exceptionally tiny.
HiddenBek|18 years ago
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.