3 ms·
SQL is nice but most of those features work best when the user is a finance person doing reports (which was the original purpose for SQL, I think?). Developers
by towelguy 12y ago
SQL is nice but most of those features work best when the user is a finance person doing reports (which was the original purpose for SQL, I think?). Developers don't want the sql server to format their numbers as money, that's a work for the UI. The main reason for me to use an ORM is to standarize on one way to retrieve data whatever the database engine is. Maybe an intermediate solution would be better, like a query builder or a sql-like syntax that transforms to the correct SQL for the database in use like Doctrine's DQL.
- RangerScience 12y ago> whatever the database engine is I know, but... How often does that flexibility come up? How often do you write code first against one DB type, and then switch to a different that would require a re-write? It's admirable and fun to think about, for sure, but how much use does that feature actually get?
- xj9 12y agoI think the advantage isn't so much the ability to switch, but the luxury of not having to know anything specific about the database you are interfacing with. This is especially useful in heterogeneous environments (like my workplace).
- matwood 12y agoUnfortunately to do any real optimizations or something even minimally complex you have to know the underlying rdbms. For example, techniques that work well in Oracle may not work well in MSSQL. If you throw mysql in there, then you have an entire set of standard sql that simply does not work or works but with horrible performance.
- towelguy 12y agoI already said this in another thread, it's not about switching databases in one project, but using the same skillset across projects regardless of the database.
- brlewis 12y agoCan you use the same skillset across projects regardless of the ORM, or do you have to standardize on one? Why not just standardize on one database?
- spacemanmatt 12y agoI find SQL is pretty portable. You have to learn each server's ins and outs to do performance work, but then, those differences are part and parcel of why there are different servers, beyond basic business-competitive reasons. ORMs just add a thick layer of fluff over an otherwise (mostly) portable language, where I'm concerned. I rather keep it simple between DBs and apps. If there is gross SQL in the app, make a view or function in the database. It isn't rocket surgery but you do need experienced staff to get it right.
- lukaseder 12y ago> It's admirable and fun to think about, for sure, but how much use does that feature actually get? (Lukas from jOOQ here) Surprisingly, that feature gets quite a bit of use. There are two use-cases (among many others) why our customers choose jOOQ: - They're using a test database (e.g. H2) and a production database (e.g. Oracle), and things still work very nicely, while staying close to SQL - They're using a client database (e.g. HSQLDB) and a server database (e.g. SQL Server), and can easily replicate without needing to remember subtle syntax differences all the time. - They're selling complex products that run on as many databases as DB2, MySQL, Oracle, SQL Server, Sybase and they want to use SQL, because their queries have an average of 10 joins each.
- bqe 12y agoMy favorite query builder for SQL is jOOQ, works on the JVM. It has a great, fluent syntax and lets you get real objects back while writing what is essentially SQL. http://www.jooq.org/ http://www.jooq.org/
- toddkaufmann 12y agoI second jOOQ. The fluent interface actually catches SQL errors at compile time (brief example is in the wikipedia entry[1]). [1] http://en.wikipedia.org/wiki/Java_Object_Oriented_Querying http://en.wikipedia.org/wiki/Java_Object_Oriented_Querying