7 ms·

This exact debate took place in the early 70s. There were three major database models: relational, network, and hierarchical. Network and hierarchical had quite

This exact debate took place in the early 70s. There were three major database models: relational, network, and hierarchical. Network and hierarchical had quite a bit of success, technically and as businesses. IMS was (is?) an IBM product based on the hierarchical model. Network databases, which seem quite similar to graph databases, were standardized (https://en.wikipedia.org/wiki/CODASYL https://en.wikipedia.org/wiki/CODASYL). Both the hierarchical and network models had low-level query languages, in which you were navigating through the hierarchical or network structures. Then the relational model was proposed in 1970, in Codd's famous paper. The genius of it was in proposing a mathematical model that was conceptually simple, conceivably practical, and it supported a high-level querying approach. (Actually two of them, relational algebra and relational calculus.) He left the little matter of implementation as an exercise to the reader, and so began many years of research into data structures and algorithms, query processing, query optimization, and transaction processing, to make the whole thing practical. And when these systems started showing practical promise (early 80s?), the network model withered away quickly. Ignoring the fact that relational databases and SQL are permanently entrenched, an alternative database technology cannot succeed unless it also supports a high-level query language. The advantages of such a language are just overwhelming. But another factor is that all of the hard database research and implementation problems have been solved in the context of relational database systems. You want to spring your new database technology on the world, because of its unique secret sauce? It isn't going anywhere until it has a high-level query language (including SQL support), query optimization, internationalization, ACID transactions, blob types, backup and recovery, replication, integration with all the major programming languages, scales with memory and CPUs, ... (Source: cofounder of two startups creating databases with secret sauces.)

mftb 5y ago
One downside of both hierarchical and network (graph) models that is not mentioned either in the post or parent comment is, "access path dependence". Network model allows multiple paths but basically just forestalls the issue. As to sibling comment question about how to keep up on this stuff, the preceding info was in the "tar pit" paper that has been discussed a lot here on HN. So I'd say, your already doing it. Continuing education is part of any profession and this is probably a better way than some.
- geophile 5y ago
  > One downside of both hierarchical and network (graph) models that is not mentioned either in the post or parent comment is, "access path dependence". Network model allows multiple paths but basically just forestalls the issue. Yes. I think that this access path independence is an essential part of the relational query approach, (of which SQL is one example), being high-level. And once you have such a language, query optimization becomes essential.
- cratermoon 5y ago
  > the "tar pit" paper that has been discussed a lot here on HN Did you mean Mosley and Marks' "Out of the Tar Pit" http://curtclifton.net/papers/MoseleyMarks06a.pdf http://curtclifton.net/papers/MoseleyMarks06a.pdf?
  - amw-zero 5y ago
    Yes
  - mftb 5y ago
    Yes, thanks for providing the link.
jrochkind1 5y ago
This kind of history is so important, and even this fairly recent history seems kind of hard to access. I am curious how you learned it? (Books? Articles? Finding people involved to interview? usenet posts?) I learned almost none of it in my formal computer science education in the laste 90s -- maybe because at that time it was recent enough that "middle-aged prime of their career" people still remembered it, it didn't seem necessary to teach it to newcomers as "history". I wonder how much post-1950 history is taught in current undergrad CS programs, like if a "databases" course will include a summary of any of the material you summarize.
- shimonabi 5y ago
  I was taught exactly this history in my college DB course in Slovenia. I even had to know the years when each model was proposed and by whom.
- gnuvince 5y ago
  You can read this article by Michael Stonebraker about the evolution of database systems: https://people.cs.umass.edu/~yanlei/courses/CS691LL-f06/papers/SH05.pdf https://people.cs.umass.edu/~yanlei/courses/CS691LL-f06/pape.... It's the first article in the Red Book[1]. [1] http://www.redbook.io/ http://www.redbook.io/
  - dunkelheit 5y ago
    We left the exact same comment :)
- dunkelheit 5y ago
  There is quite a lot about DBMS history in the Red Book and references therein: http://www.redbook.io/index.html http://www.redbook.io/index.html For the history of data model proposals in particular, there is this paper: https://scholar.google.com/scholar?cluster=7366182905777149494 https://scholar.google.com/scholar?cluster=73661829057771494... So the info is definitely out there if you are interested in that sort of thing.
- Sharlin 5y ago
mxz3000 5y ago
> Ignoring the fact that relational databases and SQL are permanently entrenched, an alternative database technology cannot succeed unless it also supports a high-level query language. The advantages of such a language are just overwhelming. You seem to be ignoring the success of highly scalable managed NoSQL databases that has been all the rage when building high TPS services. What is your opinion on those?
- paulryanrogers 5y ago
  Not OP but my guess is NoSQL wins were data isn't very relational or traditional RDBMS and ACID don't fit. One could even argue that file systems and key value stores are NoSQL solutions that predate RDBMS. Yet a lot of businesses just need something reliable, roughly relational, and with a community of talent. All that said, the world of successful solutions is not mutually exclusive or limited to only one winner.
  - lazide 5y ago
    In my experience (having worked with both for a decade or so), NoSQL is valuable when the desired performance characteristics and consistency needs diverge wildly between ‘relations’/entities. You run across similar with file systems and database boundaries. Have a lot of data you need stored where there is limited relation between them directly, and attempting to be transactionally consistent across the boundaries there and the rest of the system is going to very expensive? Then doing some part of the data in a nosql db and the rest in a ACID compliant database is probably a good idea. Similarly, putting 50GB vm images into a nosql db is probably pretty silly when it should probably be on a proper filesystem, or at most copied out and written back periodically. And putting a bunch of data that is tightly coupled together and needs to be transactionally updated to ensure your dataset doesn’t turn to gibberish in a NoSQL backend is going to be a nightmare.
- geophile 5y ago
  They work for a very specific use case. And if you need to expand that use case, or address others, good luck. Relational database systems are complicated for good reasons. Schemas, which do cause problems, are there for good reasons, and the alternative problems obtained by going without schemas are just not worth it, nearly all the time. I think a lot of the attraction of NoSQL databases is that they are seductive for people who don't know about the problems inherent in working with shared, persistent, long-lived data, (i.e. years). A NoSQL system lets such people get started easily. They start down the path, and then they run into dragons, and muggers, and hostile aliens. This is a really good description of what I mean: http://www.sarahmei.com/blog/2013/11/11/why-you-should-never-use-mongodb http://www.sarahmei.com/blog/2013/11/11/why-you-should-never....
junon 5y ago
> It isn't going anywhere until it has a high-level query language (including SQL support), query optimization, internationalization, ACID transactions, blob types, backup and recovery, replication, integration with all the major programming languages, scales with memory and CPUs I would seriously argue that all of these are necessary for a database to be useful. The sad fact is that no graph databases in existence truly act as graph databases, without some weird caveat like "you must have schemas".
- smitty1e 5y ago
  At some point, the graph is simplified to a tree. The tree becomes lumber. The lumber becomes a table. At that point, the data on the table become is suitable for human consumption.
alfiedotwtf 5y ago
> an alternative database technology cannot succeed unless it also supports a high-level query language. The advantages of such a language are just overwhelming Neo4j's Cypher query language is beautiful to work with!
simon_acca 5y ago
For more on this topic, a good read is “what hoes around comes around”, by Michael Stonebraker (creator of Postgres, among other achievements): https://people.cs.umass.edu/~yanlei/courses/CS691LL-f06/papers/SH05.pdf https://people.cs.umass.edu/~yanlei/courses/CS691LL-f06/pape...
tuatoru 5y ago
To add to this, the debate was won in practice because the data persists, but the set of things you might want to do with it is mutable. Hierarchical and Network databases assume you can anticipate future uses of your data.

mftb 5y ago

One downside of both hierarchical and network (graph) models that is not mentioned either in the post or parent comment is, "access path dependence". Network model allows multiple paths but basically just forestalls the issue. As to sibling comment question about how to keep up on this stuff, the preceding info was in the "tar pit" paper that has been discussed a lot here on HN. So I'd say, your already doing it. Continuing education is part of any profession and this is probably a better way than some.

geophile 5y ago
> One downside of both hierarchical and network (graph) models that is not mentioned either in the post or parent comment is, "access path dependence". Network model allows multiple paths but basically just forestalls the issue. Yes. I think that this access path independence is an essential part of the relational query approach, (of which SQL is one example), being high-level. And once you have such a language, query optimization becomes essential.
cratermoon 5y ago
> the "tar pit" paper that has been discussed a lot here on HN Did you mean Mosley and Marks' "Out of the Tar Pit" http://curtclifton.net/papers/MoseleyMarks06a.pdf http://curtclifton.net/papers/MoseleyMarks06a.pdf?
- amw-zero 5y ago
  Yes
- mftb 5y ago
  Yes, thanks for providing the link.

jrochkind1 5y ago

This kind of history is so important, and even this fairly recent history seems kind of hard to access. I am curious how you learned it? (Books? Articles? Finding people involved to interview? usenet posts?) I learned almost none of it in my formal computer science education in the laste 90s -- maybe because at that time it was recent enough that "middle-aged prime of their career" people still remembered it, it didn't seem necessary to teach it to newcomers as "history". I wonder how much post-1950 history is taught in current undergrad CS programs, like if a "databases" course will include a summary of any of the material you summarize.

shimonabi 5y ago
I was taught exactly this history in my college DB course in Slovenia. I even had to know the years when each model was proposed and by whom.
gnuvince 5y ago
You can read this article by Michael Stonebraker about the evolution of database systems: https://people.cs.umass.edu/~yanlei/courses/CS691LL-f06/papers/SH05.pdf https://people.cs.umass.edu/~yanlei/courses/CS691LL-f06/pape.... It's the first article in the Red Book[1]. [1] http://www.redbook.io/ http://www.redbook.io/
- dunkelheit 5y ago
  We left the exact same comment :)
dunkelheit 5y ago
There is quite a lot about DBMS history in the Red Book and references therein: http://www.redbook.io/index.html http://www.redbook.io/index.html For the history of data model proposals in particular, there is this paper: https://scholar.google.com/scholar?cluster=7366182905777149494 https://scholar.google.com/scholar?cluster=73661829057771494... So the info is definitely out there if you are interested in that sort of thing.
Sharlin 5y ago

mxz3000 5y ago

> Ignoring the fact that relational databases and SQL are permanently entrenched, an alternative database technology cannot succeed unless it also supports a high-level query language. The advantages of such a language are just overwhelming. You seem to be ignoring the success of highly scalable managed NoSQL databases that has been all the rage when building high TPS services. What is your opinion on those?

paulryanrogers 5y ago
Not OP but my guess is NoSQL wins were data isn't very relational or traditional RDBMS and ACID don't fit. One could even argue that file systems and key value stores are NoSQL solutions that predate RDBMS. Yet a lot of businesses just need something reliable, roughly relational, and with a community of talent. All that said, the world of successful solutions is not mutually exclusive or limited to only one winner.
- lazide 5y ago
  In my experience (having worked with both for a decade or so), NoSQL is valuable when the desired performance characteristics and consistency needs diverge wildly between ‘relations’/entities. You run across similar with file systems and database boundaries. Have a lot of data you need stored where there is limited relation between them directly, and attempting to be transactionally consistent across the boundaries there and the rest of the system is going to very expensive? Then doing some part of the data in a nosql db and the rest in a ACID compliant database is probably a good idea. Similarly, putting 50GB vm images into a nosql db is probably pretty silly when it should probably be on a proper filesystem, or at most copied out and written back periodically. And putting a bunch of data that is tightly coupled together and needs to be transactionally updated to ensure your dataset doesn’t turn to gibberish in a NoSQL backend is going to be a nightmare.
geophile 5y ago
They work for a very specific use case. And if you need to expand that use case, or address others, good luck. Relational database systems are complicated for good reasons. Schemas, which do cause problems, are there for good reasons, and the alternative problems obtained by going without schemas are just not worth it, nearly all the time. I think a lot of the attraction of NoSQL databases is that they are seductive for people who don't know about the problems inherent in working with shared, persistent, long-lived data, (i.e. years). A NoSQL system lets such people get started easily. They start down the path, and then they run into dragons, and muggers, and hostile aliens. This is a really good description of what I mean: http://www.sarahmei.com/blog/2013/11/11/why-you-should-never-use-mongodb http://www.sarahmei.com/blog/2013/11/11/why-you-should-never....

junon 5y ago

> It isn't going anywhere until it has a high-level query language (including SQL support), query optimization, internationalization, ACID transactions, blob types, backup and recovery, replication, integration with all the major programming languages, scales with memory and CPUs I would seriously argue that all of these are necessary for a database to be useful. The sad fact is that no graph databases in existence truly act as graph databases, without some weird caveat like "you must have schemas".

smitty1e 5y ago
At some point, the graph is simplified to a tree. The tree becomes lumber. The lumber becomes a table. At that point, the data on the table become is suitable for human consumption.

alfiedotwtf 5y ago

> an alternative database technology cannot succeed unless it also supports a high-level query language. The advantages of such a language are just overwhelming Neo4j's Cypher query language is beautiful to work with!

simon_acca 5y ago

For more on this topic, a good read is “what hoes around comes around”, by Michael Stonebraker (creator of Postgres, among other achievements): https://people.cs.umass.edu/~yanlei/courses/CS691LL-f06/papers/SH05.pdf https://people.cs.umass.edu/~yanlei/courses/CS691LL-f06/pape...

tuatoru 5y ago

To add to this, the debate was won in practice because the data persists, but the set of things you might want to do with it is mutable. Hierarchical and Network databases assume you can anticipate future uses of your data.