3 ms·

I agree the relational model is much closer to optimal than SQL. Looking at JQuery as a query language was a breath of fresh air, and made me realize how wonde

by artsrc 16y ago

I agree the relational model is much closer to optimal than SQL. Looking at JQuery as a query language was a breath of fresh air, and made me realize how wonderful a query language can be, and how capable the software community can be. The relational model is not a sane way to store a book, a compressed song, a code base, or many other things. SQL databases are a great way to store some kinds of data. The relational model is not a way to store anything since there are no implementations which are both faithful to the model and solid data stores. Real world SQL data stores are suboptimal in different ways for almost all tasks, so progress is possible. Ultimately a disks (and memory) is get and put. Anything model we put above that makes some assumptions, and they may be the wrong ones. So where are we going. Here is what I think: requiring the articulation of the domain twice, once for a datastore, and once for application, is spitting on humanity in a grotesque and obscene way, so SQL must die.

prodigal_erik 16y ago
Almost every database I've ever seen was used by more than one application, and from different languages. If you succeed, you're going to have ops and sales and support and finance and bizdev needing access, and they're going to want to use their favorite tools rather than wait for you to build poor imitations from scratch.
- artsrc 16y ago
  So we are stuck with SQL forever because it currently has the broadest set of access tools?
  - prodigal_erik 16y ago
    We aren't necessarily stuck with SQL (for instance, right now there are LDAP or XML or RDF-oriented datastores out there with fairly open APIs and decent interop), but we are stuck with "articulation of the domain twice, once for a datastore, and once for application" unless one programming language finally conquers all the others and becomes the only platform your schema needs to be usable with.
jimbokun 16y ago
"Anything model we put above that makes some assumptions, and they may be the wrong ones." One of the main points of the article is that if you don't have a good handle on what assumptions you need to make about your data, choose a relational database. That is because it makes the fewest assumptions about the kinds of questions you will need to ask about your data. If you pick a different solution that does not support the kinds of questions you would like to ask, you will experience much pain.
- artsrc 16y ago
  If the question you end up wanting to ask, is "Can you make it easy to distribute writes to this store?", then SQL is a poor choice. We have had a stagnant SQL monoculture as a default choice for data, for 20 years. Given a project of with an uncertain future we are now starting to get other choices. We know that using an SQL databases will create pain. Suffering that pain in the hope that later questions may be answered less painfully, is becoming a mindful decision. Especially in startups, not the default that it has been in the enterprise world. Google seems to be a lot better at answering questions than Sybase is. Out of date, offline, full text indexing is not something SQL databases do well. For content like movies, music and large documents, we simply don't (and should not) create a relational model, we use big blobs and dump them into whatever tools we have around. We all would agree that if your data looks like source code you are better off with git than with MySQL. So where else does "if you don't know use SQL" breakdown.

by artsrc 16y ago

prodigal_erik 16y ago

Almost every database I've ever seen was used by more than one application, and from different languages. If you succeed, you're going to have ops and sales and support and finance and bizdev needing access, and they're going to want to use their favorite tools rather than wait for you to build poor imitations from scratch.

artsrc 16y ago
So we are stuck with SQL forever because it currently has the broadest set of access tools?
- prodigal_erik 16y ago
  We aren't necessarily stuck with SQL (for instance, right now there are LDAP or XML or RDF-oriented datastores out there with fairly open APIs and decent interop), but we are stuck with "articulation of the domain twice, once for a datastore, and once for application" unless one programming language finally conquers all the others and becomes the only platform your schema needs to be usable with.

jimbokun 16y ago

"Anything model we put above that makes some assumptions, and they may be the wrong ones." One of the main points of the article is that if you don't have a good handle on what assumptions you need to make about your data, choose a relational database. That is because it makes the fewest assumptions about the kinds of questions you will need to ask about your data. If you pick a different solution that does not support the kinds of questions you would like to ask, you will experience much pain.

artsrc 16y ago
If the question you end up wanting to ask, is "Can you make it easy to distribute writes to this store?", then SQL is a poor choice. We have had a stagnant SQL monoculture as a default choice for data, for 20 years. Given a project of with an uncertain future we are now starting to get other choices. We know that using an SQL databases will create pain. Suffering that pain in the hope that later questions may be answered less painfully, is becoming a mindful decision. Especially in startups, not the default that it has been in the enterprise world. Google seems to be a lot better at answering questions than Sybase is. Out of date, offline, full text indexing is not something SQL databases do well. For content like movies, music and large documents, we simply don't (and should not) create a relational model, we use big blobs and dump them into whatever tools we have around. We all would agree that if your data looks like source code you are better off with git than with MySQL. So where else does "if you don't know use SQL" breakdown.