4 ms·

A Relational Model of Data for Large Shared Data Banks by E.F. Codd (1970) [pdf]

eru 10y ago
Oddly enough, to this day most programming languages encourage a graph or hierarchical model. Taking Codd serious suggests using relations inside programs as well. See eg http://shaffner.us/cs/papers/tarpit.pdf http://shaffner.us/cs/papers/tarpit.pdf
- fsloth 10y ago
  If the schema is fixed relations are pretty nice for various data transforms. One can implement tables in C++ with vectors, struct for row and a typed integer for references for entities. Beats object model hands down any time when complexity is only a tad above trivial.
  - eru 10y ago
    Yes, indeed. Though I'd rather have better support from the programming language than what C++ can provide.
- schoen 10y ago
  Sort of the converse of NoSQL? (Sometimes people advocate NoSQL saying that the representation of data in programs isn't relational, so the database shouldn't be either.)
  - eru 10y ago
    Yes, exactly. We did that at Standard Chartered in a functional setting. (They are still doing it, and better than before; but I left since.)
- barrkel 10y ago
  I'd love to see more use of relational concepts inside programs. One problem is that making use of relations involves very high level descriptions of computations, and computing them efficiently requires a lot of smarts - you'd risk baking half a database engine into the runtime. There would still be a bit of a mismatch between relations held locally - a kind of disconnected data set - and relations in the persistent store. Synchronization, local-remote joins, transactions - there are lots of details to get right. It's not something trivially added on via a library either, not if you want to do it right (properly typed, abstracted at the right level, e.g. creating ASTs to represent the computation).
  - eru 10y ago
    Something like Haskell might have a rich enough type system to embed relations properly. (They've done statically typed relations in Standard Chartered's Haskell dialect, recently, after having had dynamically checked relations for years.) And not only type system, but also the AST ideas you are talking about. Check out higher-order abstract syntax. > One problem is that making use of relations involves very high level descriptions of computations, and computing them efficiently requires a lot of smarts - you'd risk baking half a database engine into the runtime. I wonder if a variant of Greenspun's tenth rule applies? "Every sufficiently complex program (without formal relations) contains a half-baked database engine."
    - tome 10y ago
      > Something like Haskell might have a rich enough type system to embed relations properly. It has alread been done (and, unlike Standard Chartered's version, no weird and non-composable type-level programming required) https://hackage.haskell.org/package/opaleye https://hackage.haskell.org/package/opaleye Disclaimer: I wrote Opaleye, but most of the "embed statically typed relations in Haskell" leg work was done by HaskellDB.
      - eru 10y ago
        Sounds awesome. I'll check it out. Hmm, it says: > An SQL-generating DSL targeting PostgreSQL. Allows Postgres queries to be written within Haskell in a typesafe and composable fashion. Genering Postgres queries sounds very different from using relations as a datatype inside my program. Or is that feature buried somewhere deeper?
        tome 10y ago
        Opaleye only targets Postgres, not in-memory relations, but if one were to implement in-memory relations in Haskell then they could/should/would have roughly the same type structure as Opaleye.
- bcoates 10y ago
  I wonder what Tablizer is up to these days...
snaky 10y ago
The first, unpublished, most underrated and brilliant paper by Codd, "Derivability, Redundancy, and Consistency of Relations Stored in Large Data Banks" - http://www.liberidu.com/blog/images/rj599.pdf http://www.liberidu.com/blog/images/rj599.pdf > The true importance of relational theory is highlighted by the title of the original (and considerably shorter) version of Codd’s first paper. That version predated the published version by a year, and the title was “Derivability, Redundancy, and Consistency of Relations Stored in Large Data Banks.” The title of this unpublished version emphasizes that the real importance of relational theory is that it provides a rigorous method of asserting arbitrarily complex consistency constraints that must be satisfied by the data within the database. Strange as it may sound, Oracle Database did not enforce referential integrity constraints until Version 7 was released in the 1990s (by which time Oracle Corporation was already the world’s largest database company) https://iggyfernandez.wordpress.com/2013/04/24/whats-so-sacred-about-relational-anyway/3/ https://iggyfernandez.wordpress.com/2013/04/24/whats-so-sacr...
- nigwil_ 10y ago
  EF Codd updated his ideas too: Extending the Data Base Relational Model to Capture More Meaning by E.F. Codd IBM Research Laboratory published in Volume 1 Number 1 (March 1979) issue of AUSTRALIAN COMPUTER SCIENCE COMMUNICATIONS, which incorporated papers from the 2nd Australian Computer Science Conference 1-2 February 1979 in Hobart, Tasmania. http://www.retrocomputingtasmania.com/home/projects/history/rm-t-paper http://www.retrocomputingtasmania.com/home/projects/history/...

eru 10y ago

Oddly enough, to this day most programming languages encourage a graph or hierarchical model. Taking Codd serious suggests using relations inside programs as well. See eg http://shaffner.us/cs/papers/tarpit.pdf http://shaffner.us/cs/papers/tarpit.pdf

fsloth 10y ago
If the schema is fixed relations are pretty nice for various data transforms. One can implement tables in C++ with vectors, struct for row and a typed integer for references for entities. Beats object model hands down any time when complexity is only a tad above trivial.
- eru 10y ago
  Yes, indeed. Though I'd rather have better support from the programming language than what C++ can provide.
schoen 10y ago
Sort of the converse of NoSQL? (Sometimes people advocate NoSQL saying that the representation of data in programs isn't relational, so the database shouldn't be either.)
- eru 10y ago
  Yes, exactly. We did that at Standard Chartered in a functional setting. (They are still doing it, and better than before; but I left since.)
barrkel 10y ago
I'd love to see more use of relational concepts inside programs. One problem is that making use of relations involves very high level descriptions of computations, and computing them efficiently requires a lot of smarts - you'd risk baking half a database engine into the runtime. There would still be a bit of a mismatch between relations held locally - a kind of disconnected data set - and relations in the persistent store. Synchronization, local-remote joins, transactions - there are lots of details to get right. It's not something trivially added on via a library either, not if you want to do it right (properly typed, abstracted at the right level, e.g. creating ASTs to represent the computation).
- eru 10y ago
  Something like Haskell might have a rich enough type system to embed relations properly. (They've done statically typed relations in Standard Chartered's Haskell dialect, recently, after having had dynamically checked relations for years.) And not only type system, but also the AST ideas you are talking about. Check out higher-order abstract syntax. > One problem is that making use of relations involves very high level descriptions of computations, and computing them efficiently requires a lot of smarts - you'd risk baking half a database engine into the runtime. I wonder if a variant of Greenspun's tenth rule applies? "Every sufficiently complex program (without formal relations) contains a half-baked database engine."
  - tome 10y ago
    > Something like Haskell might have a rich enough type system to embed relations properly. It has alread been done (and, unlike Standard Chartered's version, no weird and non-composable type-level programming required) https://hackage.haskell.org/package/opaleye https://hackage.haskell.org/package/opaleye Disclaimer: I wrote Opaleye, but most of the "embed statically typed relations in Haskell" leg work was done by HaskellDB.
    - eru 10y ago
      Sounds awesome. I'll check it out. Hmm, it says: > An SQL-generating DSL targeting PostgreSQL. Allows Postgres queries to be written within Haskell in a typesafe and composable fashion. Genering Postgres queries sounds very different from using relations as a datatype inside my program. Or is that feature buried somewhere deeper?
      - tome 10y ago
        Opaleye only targets Postgres, not in-memory relations, but if one were to implement in-memory relations in Haskell then they could/should/would have roughly the same type structure as Opaleye.
bcoates 10y ago
I wonder what Tablizer is up to these days...

snaky 10y ago

The first, unpublished, most underrated and brilliant paper by Codd, "Derivability, Redundancy, and Consistency of Relations Stored in Large Data Banks" - http://www.liberidu.com/blog/images/rj599.pdf http://www.liberidu.com/blog/images/rj599.pdf > The true importance of relational theory is highlighted by the title of the original (and considerably shorter) version of Codd’s first paper. That version predated the published version by a year, and the title was “Derivability, Redundancy, and Consistency of Relations Stored in Large Data Banks.” The title of this unpublished version emphasizes that the real importance of relational theory is that it provides a rigorous method of asserting arbitrarily complex consistency constraints that must be satisfied by the data within the database. Strange as it may sound, Oracle Database did not enforce referential integrity constraints until Version 7 was released in the 1990s (by which time Oracle Corporation was already the world’s largest database company) https://iggyfernandez.wordpress.com/2013/04/24/whats-so-sacred-about-relational-anyway/3/ https://iggyfernandez.wordpress.com/2013/04/24/whats-so-sacr...

nigwil_ 10y ago
EF Codd updated his ideas too: Extending the Data Base Relational Model to Capture More Meaning by E.F. Codd IBM Research Laboratory published in Volume 1 Number 1 (March 1979) issue of AUSTRALIAN COMPUTER SCIENCE COMMUNICATIONS, which incorporated papers from the 2nd Australian Computer Science Conference 1-2 February 1979 in Hobart, Tasmania. http://www.retrocomputingtasmania.com/home/projects/history/rm-t-paper http://www.retrocomputingtasmania.com/home/projects/history/...