5 ms·

I've always wondered what's the best way to integrate a database engine with the application. 1) Use a middleware/ORM/Whatever which abstracts away the query-l

I've always wondered what's the best way to integrate a database engine with the application. 1) Use a middleware/ORM/Whatever which abstracts away the query-lang of the db, and provides a pluggable multi-db support 2) Just use native db query language with all exclusive features of the engine. Companies like workshape.io, why do they prefer the latter?

mbrock 12y ago
Abstractions are leaky. [1] ORM systems are highly complicated abstractions. Most of your developers will use them without understanding how they work. In many cases, the only way to understand how they work is to read the source code. They have magic features that are advertised as convenient but when they inevitably do something you don't want them to do you'll tear your hair out trying to circumvent them. They put lots of complicated weird stuff in your stack traces so when something goes wrong with "the database stuff," which is probably going to happen every day, you will feel confused and overwhelmed. ORM was famously referred to as "the Vietnam war of computer science" by Ted Neward. [2] There's a point that I think is even more important than the unruly and bewildering complexity of ORM, but I'm not sure I know how to formulate this point. One way to formulate it would be to point out that your dichotomy of two choices is missing an alternative, so I present: 3) Code your data access in a separate module exposing query & save functions that make sense within your domain model. In a reasonably complex system, this module might consist of fifty functions that concatenate SQL strings or whatever. In most cases, I'd bet money that rewriting this module to support some other data storage—especially if there are integration tests—would be easier and more pleasant than switching your ORM and then dealing with the random problems that will inevitably occur. And when some query fails or is slow, the developer issued to fix it will just go into the file, find the query, and change it. It's simpler, there's less obscure technology to worry about, fewer things to get angry at. [1]: http://www.joelonsoftware.com/articles/LeakyAbstractions.html http://www.joelonsoftware.com/articles/LeakyAbstractions.htm... [2]: http://blog.codinghorror.com/object-relational-mapping-is-the-vietnam-of-computer-science/ http://blog.codinghorror.com/object-relational-mapping-is-th...
- tracker1 12y ago
  Alternatively.. wrap each domain's data as a separate micro-service, with a convenient API... Though it really depends on how you can break down the boundaries of your application's data. Then you can persist/represent that data however you like.
- neumino 12y ago
  You should check out thinky. Because of the chainable query language you don't have to build a new abstractions. You can just use the same. Meaning that there is nothing (or very little) to learn yp switch from the driver to thinky.
- politician 12y ago
  Preprocessed prepared queries that are shipped along with whatever package is using them is a far easier solution than quirky ORM tools that can do the simple things, but have a tendency to break on the harder things or encourage an authoring style that destroys performance. That said, I think the world could use a CoffeeScript-esque transpiler for targeting SQL. Preferably with some kind of frontend/IL/backend separation, so that everyone can take a crack at replacing the awful SQL syntax.
hiphipjorge 12y ago
Well, here's where the difference between query builders and ORMs comes in. Query builders (usually integrated with ORMs) are usually used by people who don't want to write any SQL. SQL is very performant and powerful, but not that easy to understand or write. This is especially so when you think about the context switch between programming languages and SQL. The advantage of some of the NoSQL databases (MongoDB and RethinkDB, for example) is that you have the luxury of using an ORM only when it makes sense to use it, instead of relying on ORMs as crutch for not knowing SQL. The second approach seems better, but obviously SQL (power, performance, and prevalence) cannot be ignored.
- nightski 12y ago
  I disagree. I use ORMs/Query Builders for two reasons (even if deeply familiar with SQL syntax and semantics). 1. Dynamic queries for reporting purposes. Is it possible to hand roll this with SQL string concat for every query? Yes. Some of us value time and correctness. 2. Type safety/Refactoring and change management. Sure even a Query Builder/ORM model doesn't know if it matches the production database at compile time. But when your database does change and you need to update the model to match it then it is a lot easier to do a refactoring on the record than to manually update every SQL query string where that table is involved and hope there isn't a missing test or invalid query out there which will now be broken.

mbrock 12y ago

Abstractions are leaky. [1] ORM systems are highly complicated abstractions. Most of your developers will use them without understanding how they work. In many cases, the only way to understand how they work is to read the source code. They have magic features that are advertised as convenient but when they inevitably do something you don't want them to do you'll tear your hair out trying to circumvent them. They put lots of complicated weird stuff in your stack traces so when something goes wrong with "the database stuff," which is probably going to happen every day, you will feel confused and overwhelmed. ORM was famously referred to as "the Vietnam war of computer science" by Ted Neward. [2] There's a point that I think is even more important than the unruly and bewildering complexity of ORM, but I'm not sure I know how to formulate this point. One way to formulate it would be to point out that your dichotomy of two choices is missing an alternative, so I present: 3) Code your data access in a separate module exposing query & save functions that make sense within your domain model. In a reasonably complex system, this module might consist of fifty functions that concatenate SQL strings or whatever. In most cases, I'd bet money that rewriting this module to support some other data storage—especially if there are integration tests—would be easier and more pleasant than switching your ORM and then dealing with the random problems that will inevitably occur. And when some query fails or is slow, the developer issued to fix it will just go into the file, find the query, and change it. It's simpler, there's less obscure technology to worry about, fewer things to get angry at. [1]: http://www.joelonsoftware.com/articles/LeakyAbstractions.html http://www.joelonsoftware.com/articles/LeakyAbstractions.htm... [2]: http://blog.codinghorror.com/object-relational-mapping-is-the-vietnam-of-computer-science/ http://blog.codinghorror.com/object-relational-mapping-is-th...

tracker1 12y ago
Alternatively.. wrap each domain's data as a separate micro-service, with a convenient API... Though it really depends on how you can break down the boundaries of your application's data. Then you can persist/represent that data however you like.
neumino 12y ago
You should check out thinky. Because of the chainable query language you don't have to build a new abstractions. You can just use the same. Meaning that there is nothing (or very little) to learn yp switch from the driver to thinky.
politician 12y ago
Preprocessed prepared queries that are shipped along with whatever package is using them is a far easier solution than quirky ORM tools that can do the simple things, but have a tendency to break on the harder things or encourage an authoring style that destroys performance. That said, I think the world could use a CoffeeScript-esque transpiler for targeting SQL. Preferably with some kind of frontend/IL/backend separation, so that everyone can take a crack at replacing the awful SQL syntax.

hiphipjorge 12y ago

Well, here's where the difference between query builders and ORMs comes in. Query builders (usually integrated with ORMs) are usually used by people who don't want to write any SQL. SQL is very performant and powerful, but not that easy to understand or write. This is especially so when you think about the context switch between programming languages and SQL. The advantage of some of the NoSQL databases (MongoDB and RethinkDB, for example) is that you have the luxury of using an ORM only when it makes sense to use it, instead of relying on ORMs as crutch for not knowing SQL. The second approach seems better, but obviously SQL (power, performance, and prevalence) cannot be ignored.

nightski 12y ago
I disagree. I use ORMs/Query Builders for two reasons (even if deeply familiar with SQL syntax and semantics). 1. Dynamic queries for reporting purposes. Is it possible to hand roll this with SQL string concat for every query? Yes. Some of us value time and correctness. 2. Type safety/Refactoring and change management. Sure even a Query Builder/ORM model doesn't know if it matches the production database at compile time. But when your database does change and you need to update the model to match it then it is a lot easier to do a refactoring on the record than to manually update every SQL query string where that table is involved and hope there isn't a missing test or invalid query out there which will now be broken.