3 ms·

Unless your workload is storing deeply-hierarchical-yet loosely-related-but-otherwise-independent documents, you have a relational model. Not using a relationa

Unless your workload is storing deeply-hierarchical-yet loosely-related-but-otherwise-independent documents, you have a relational model. Not using a relational engine doesn't change that.

ibejoeb 12y ago
It's really hard to get this through to people nowadays. The relational model is powerful, and the storage systems, logic engines, languages, and ancillary toolsets that work under it--on the market, ready for production, today--are very advanced. When I work with people who claim that their models are not relational, I usually have to contend that they are. The argument goes like this: you may be able to model your problem as documents or hierarchies, but can you model all of the questions you want to ask about that data in the same way? The major vendors of relational systems have first-class support for hierarchical data structures, recursive data structures, graphs, KVs, and documents, and they can be used in conjunction with the basic relational features. Modern SQL is more that just SELECT...FROM...WHERE...GROUP BY; it has powerful, fast analytical functions, domain modeling, and reporting features. The top engines can partition your data and parallelize your access patterns to get the most value out of your commodity multi-core/SSD hardware. The support for such systems is ubiquitous in todays software libraries. These systems even have tailored hardware platforms to support them if your problems really lie far out on the curve. The downside is that none of the free/OSS systems are quite as capable. The commercial systems often require the top-tier editions to support all of the above. The good news is that it's really a good financial deal if you actually need it. A $40,000 license for Oracle or MS-SQL is 1/4 of the annual cost of an engineer that can coerce similar functionality out of a lesser product. Their are plenty of consultants that can help you get there on a one-and-done basis. PostgreSQL is getting there, too. Query parallelism is, for me, the biggest gap. There are some neat aftermarket solutions, but it's not quite there yet.
- tensor 12y ago
  I think another part of the problem is that so many people think that you need an ORM to use a relational database. That often prevents them from using advanced functionality.
- count 12y ago
  While I don't disagree with you, I think you're might be missing a higher level difference: many of todays teams are pulling functionality OUT of the storage engine entirely, and 'rolling their own' in the application code. I'm not passing judgement on if that's a good thing or not, but many teams I see today are looking at the storage engine as nothing but that: a temporary place to put things that can be swapped out if there's something that does the same job faster, where 'job' is glorified K:V and possibly sorting. Ceding advanced functionality to the database is what is being avoided: my own app code is usually easier to troubleshoot than an obscure Oracle error.

Unless your workload is storing deeply-hierarchical-yet loosely-related-but-otherwise-independent documents, you have a relational model. Not using a relational engine doesn't change that.

ibejoeb 12y ago

It's really hard to get this through to people nowadays. The relational model is powerful, and the storage systems, logic engines, languages, and ancillary toolsets that work under it--on the market, ready for production, today--are very advanced. When I work with people who claim that their models are not relational, I usually have to contend that they are. The argument goes like this: you may be able to model your problem as documents or hierarchies, but can you model all of the questions you want to ask about that data in the same way? The major vendors of relational systems have first-class support for hierarchical data structures, recursive data structures, graphs, KVs, and documents, and they can be used in conjunction with the basic relational features. Modern SQL is more that just SELECT...FROM...WHERE...GROUP BY; it has powerful, fast analytical functions, domain modeling, and reporting features. The top engines can partition your data and parallelize your access patterns to get the most value out of your commodity multi-core/SSD hardware. The support for such systems is ubiquitous in todays software libraries. These systems even have tailored hardware platforms to support them if your problems really lie far out on the curve. The downside is that none of the free/OSS systems are quite as capable. The commercial systems often require the top-tier editions to support all of the above. The good news is that it's really a good financial deal if you actually need it. A $40,000 license for Oracle or MS-SQL is 1/4 of the annual cost of an engineer that can coerce similar functionality out of a lesser product. Their are plenty of consultants that can help you get there on a one-and-done basis. PostgreSQL is getting there, too. Query parallelism is, for me, the biggest gap. There are some neat aftermarket solutions, but it's not quite there yet.

tensor 12y ago
I think another part of the problem is that so many people think that you need an ORM to use a relational database. That often prevents them from using advanced functionality.
count 12y ago
While I don't disagree with you, I think you're might be missing a higher level difference: many of todays teams are pulling functionality OUT of the storage engine entirely, and 'rolling their own' in the application code. I'm not passing judgement on if that's a good thing or not, but many teams I see today are looking at the storage engine as nothing but that: a temporary place to put things that can be swapped out if there's something that does the same job faster, where 'job' is glorified K:V and possibly sorting. Ceding advanced functionality to the database is what is being avoided: my own app code is usually easier to troubleshoot than an obscure Oracle error.