4 ms·

Perhaps you are suffering from Blub? http://wiki.c2.com/?BlubParadox http://wiki.c2.com/?BlubParadox One reason for wanting to shift databases is testing. The u

• 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.