3 ms·

> One reason for wanting to shift databases is testing. The unit tests might be running on the developers own sqlite instances because running them on the compa

by mmt 8y ago

> One reason for wanting to shift databases is testing. The unit tests might be running on the developers own sqlite instances because running them on the company-wide SQL Server installation is prohibitive. That doesn't strike me as a shift, though. Presumably, if sqlite (or, say, its heavier weight, also free, cousin PostgreSQL) can mimic enough functionality of the proprietary company-wide db, why isn't bare SQL enough to access those functions? Why is SQL not a good enough abstraction? Too difficult to ensure one is writing a portable subset of the language? > A well-written ORM This runs into the danger of being a "true Scotsman" type argument if it doesn't apply to at least most popular ORMs (or at least one for each popular language). > aren't more complex than the equivalent sql statements. They are, by definition, if one already knows the equivalent SQL statement: one has to learn the additional, separate syntax.

bjourne 8y ago
> That doesn't strike me as a shift, though. Presumably, if sqlite (or, say, its heavier weight, also free, cousin PostgreSQL) can mimic enough functionality of the proprietary company-wide db, why isn't bare SQL enough to access those functions? It is, but then developers have to make a conscious effort to stick with a portable subset of SQL. It is much easier to have an ORM do that job for you. > Too difficult to ensure one is writing a portable subset of the language? For complex applications, that is very difficult, yes. > This runs into the danger of being a "true Scotsman" type argument if it doesn't apply to at least most popular ORMs (or at least one for each popular language). Some of the earlier Java EE ORM:s were truly garbage. They included way to much convenient magic. For example, it was often hard to predict whether a someObj.getFoo() call would trigger a database lookup or not. OP might have cut his teeth on one of those and therefore believe they all introduce extra complexity. > They are, by definition, if one already knows the equivalent SQL statement: one has to learn the additional, separate syntax. For example, in C# Linq is already used for functional list processing. Using them for SQL is just a change of backend.
- 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 ago
    op 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.

by mmt 8y ago

bjourne 8y ago

> That doesn't strike me as a shift, though. Presumably, if sqlite (or, say, its heavier weight, also free, cousin PostgreSQL) can mimic enough functionality of the proprietary company-wide db, why isn't bare SQL enough to access those functions? It is, but then developers have to make a conscious effort to stick with a portable subset of SQL. It is much easier to have an ORM do that job for you. > Too difficult to ensure one is writing a portable subset of the language? For complex applications, that is very difficult, yes. > This runs into the danger of being a "true Scotsman" type argument if it doesn't apply to at least most popular ORMs (or at least one for each popular language). Some of the earlier Java EE ORM:s were truly garbage. They included way to much convenient magic. For example, it was often hard to predict whether a someObj.getFoo() call would trigger a database lookup or not. OP might have cut his teeth on one of those and therefore believe they all introduce extra complexity. > They are, by definition, if one already knows the equivalent SQL statement: one has to learn the additional, separate syntax. For example, in C# Linq is already used for functional list processing. Using them for SQL is just a change of backend.

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 ago
  op 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.