Re:Literate SQL
by weberc2 on Sunday June 25, 2017 @01:38PM
(#14631158)
While I prefer vanilla SQL to the current generation of ORMs, I think ORMs are trying to address a real problem--namely that SQL (despite being high level) isn't very abstraction-friendly. Abstractions in SQL can be expensive and often unpredictably so, despite how clever databases are today. I think part of the problem is the mismatch between the largely imperative OO paradigm and the largely declarative relational paradigm, but I suspect that there's some semantic impedance between SQL and a truly relational model which contributes to the problem.
[ Parent
| on HN ]
Re:Literate SQL
by DaiPlusPlus on Sunday June 25, 2017 @05:28PM
(#14632294)
I advocate ORM use for guaranteed type-safety - so long as SQL queries are processed as strings inside your application there's always the risk of column names and types not matching your entity classes - by using an ORM that generates SQL based on your classes (e.g. Entity Framework with Linq) it promotes mismatches to compile-time errors. This alone makes it worthwhile.
How does an ORM know what your database schema is at compile time? Honest question.
Re:Literate SQL
by mikaelhardo on Monday June 26, 2017 @04:50AM
(#14635134)
You either generate a model based on your database, or generate your database from your model.
That way the database and model are always in sync and you get errors in the code. In Entity Framework this is called either "Code first" or "Database first"