3 ms·
> a conscious effort to stick with a portable subset of SQL. Or perhaps just a validation tool. Since you mentioned testing, it might even be enough to use a s
by mmt 8y ago
> a conscious effort to stick with a portable subset of SQL.
Or perhaps just a validation tool. Since you mentioned testing, it might even be enough to use a stripped-down parser from something like SQLite. Granted, integration could be tough if these don't already exist.
> It is much easier to have an ORM do that job for you.
> For complex applications, that is very difficult, yes.
I was hoping for more than the bare assertion. What makes it so difficult? What makes an application "complex" in this context?
> Some of the earlier Java EE ORM:s were truly garbage.
So modern ones are all (or mostly) well-written?
> For example, in C# Linq is already used for functional list processing. Using them for SQL is just a change of backend.
This sounds very much like an application developer treating the database as merely a dumb datastore, which I suspect (and I admit I'm speculating here) the OP would consider an anti-pattern.
Perhaps that's the real source of the OP's question, the perspective of someone who's well-versed enough with RDBMSes and their ability to manipulate/process data before it even reaches the application, even with only portable[1] SQL.
Hopefully the OP, or someone who responded with a "me too" to the OP can chime in to support or refute my speculation.
[1] I would expect the intersection of MSSQL, Oracle, and Postgres to be suitably powerful
- xupybd 8y agoop here. I'm not sure about using the database as a dumb database. The only times I've seen that done the code was so bad that the datbase structure was not really the main concern. I will say that often there are a lot of missing indexes and foreign keys in those situations. I get my understanding of the data model from the database. Foreign keys not only help constrain things to valid data but they provide a nice map to navigate the database with. > Perhaps that's the real source of the OP's question, the perspective of someone who's well-versed enough with RDBMSes and their ability to manipulate/process data before it even reaches the application, even with only portable[1] SQL. Yeah you are totally correct here. I find I can significantly reduce the complexity of the code by putting a lot of logic into the SQL. SQL is a very good domain specific language. Additionally the database is very efficient at it's job. I've never been able to replicate this in an ORM. In ORMs I have found the large number of database queries can make it difficult to move the database to a different machine to the application. But even this aside I have to learn a lot to use a tool such as hibernate. All that learning and added complexity has to pay for itself somewhere. I'm not sure I've seen that pay off. But I honestly think I'm missing something.
- mmt 8y ago> But I honestly think I'm missing something. Since you confirmed my presumption, I don't think you're missing anything. Put another way, I think you're mostly missing the perspective of the typical ORM proponent. From that perspective, even if the datastore isn't necessarily dumb, as such, it's more like an afterthought, conceptually subservient/inferior to the application, perhaps even a necessary evil. The job of the ORM is to release the data from that terrible (relational) paradigm and bring it into enlightened (object) world of whatever language the application is written in. This is, of course, a bit of a caricature for effect. There was a fairly extensive discussion of a database-first paradigm a few weeks ago here on HN: https://news.ycombinator.com/item?id=17247088 https://news.ycombinator.com/item?id=17247088 https://blog.jooq.org/2018/06/06/truth-first-or-why-you-should-mostly-implement-database-first-designs/ https://blog.jooq.org/2018/06/06/truth-first-or-why-you-shou... It's worth noting that even that author didn't suggest entirely avoiding an ORM, but, rather, using code-generation (in one that offers it).