The relational model for database management

What Hacker News says

1. necovekFeb 2022
   I mostly keep them for reference purposes and when I feel like casually exploring a topic.

   If I am actively learning something, I usually need to be hands-on with my toy project (which is never really a toy project as in it has to do something of value to me), and books are too slow to go through questions I might have while building stuff.

   I do enjoy an ocassional "historical" programming book for a subject I care about (eg. Codds Relational Model for Database Management), but rarely will I read a book cover to cover.

   Show morethread
2. amw-zeroDec 2020
   Read this paper. Then read his book, The Relational Model for Database Management: https://codeblab.com/wp-content/uploads/2009/12/rmdb-codd.pd....

   It’s mind boggling how much he anticipated about data management, and was absolutely accurate about. As someone who unfortunately learned databases via ORMs, I started to dive into his writing directly and learn more about the relational model itself.

   It’s amazing how much power is in the model that I was completely unaware of, like domains: https://www.postgresql.org/docs/9.5/sql-createdomain.html.

   It also inspired me to learn more about math, specifically set theory. Set theory is the most practically useful math you can learn as a programmer. It’s a shame that it’s not common to communicate in terms of set theory more at work, considering how much we intuitively use it. You can’t work in a complicated data model without talking about unions, and the relational model itself is just an extension of set theory, very clearly defined via set theory.

   It’s funny. Almost every popular tool or technique we use has a clear and direct lineage from math, yet we have a huge anti-math sentiment in our industry at large. I mean. It’s not funny. It’s tragically ignorant.

   Show morethread
3. reshloJan 2025
   UNDEFINED would not be accurate. If your signup form has an optional field for a full name which I don’t fill in, I still have a name. Just because a value is not known by your database doesn’t mean it isn’t defined.

   E. F. Codd thought about this issue.[0]

   > Codd indicated in his 1990 book The Relational Model for Database Management, Version 2 that the single Null mandated by the SQL standard was inadequate, and should be replaced by two separate Null-type markers to indicate why data is missing. In Codd's book, these two Null-type markers are referred to as 'A-Values' and 'I-Values', representing 'Missing But Applicable' and 'Missing But Inapplicable', respectively. Codd's recommendation would have required SQL's logic system be expanded to accommodate a four-valued logic system. Because of this additional complexity, the idea of multiple Nulls with different definitions has not gained widespread acceptance in the database practitioners' domain. It remains an active field of research though, with numerous papers still being published.

   [0] https://en.wikipedia.org/wiki/Null_(SQL)

   Show morethread
4. da_chickenDec 2018
   Nonsense.

   First of all, Codd's early work didn't propose it because Codd's propositions were idyllic and rooted in mathematics and not software engineering. In Codd's world, you would never create a FirstName/GivenName and a LastName/Surname field. You'd just create a Name field. The fact that you might want to sort by last name or the fact that someone named "Alice Taylor Smith" has a surname of "Smith" while "Robert Taylor Smith" has a surname of "Taylor Smith" isn't relevant. In Codd's world, you'd just define Name as a Name type, and the Name type itself would know everything about the entire domain of names. It would be about as complicated as working with a DATETIME. The same would be true for an Address type. Such a type would support both Western and Japanese addresses, which are wildly different. Codd doesn't need NULL because he has complex types which perfectly and comprehensively represent their domains. That's not realistic. Parsing Names and Addresses for even a single culture is notoriously difficult.

   Second of all, Codd's later major work, The Relational Model for Database Management, includes his Twelve Rules (numbered 0 to 12) for database design in order for a DBMS to be considered relational[0]. Rule number 3 is:

   > Rule 3: Systematic treatment of null values:

   > Null values (distinct from the empty character string or a string of blank characters and distinct from zero or any other number) are supported in fully relational DBMS for representing missing information and inapplicable information in a systematic way, independent of data type.

   So Codd clearly thought that nulls were essential.

   [0]: https://en.wikipedia.org/wiki/Codd%27s_12_rules

   Show morethread
5. laichzeit0Jul 2018
   E. F. Codd - The Relational Model for Database Management - Version 2.
   thread
6. beachstartupMay 2014
   From wikipedia: It was at this time that Ed Oates[4] introduced Miner and Ellison to a paper by E. F. Codd on the relational model for database management.

   yet the PDF it references says ellison did it. i think this is one of those things that will always be up for debate, as everyone is going to have a slightly different recollection of it. it doesn't matter though - no question that IBM wrote it, but oracle as a company decided to pursue it, meaning that everyone was on board.

   the book "the difference between god and larry ellison" goes into a lot of this detail. it was basically 3 or 4 guys doing intense technical work for several years, including larry ellison.

   in my opinion the book paints him as a fair businessman with a knack for over-the-top personal behavior. i don't remember it saying he ever tried to screw over his cofounders or run-of-the-mill employees.

   also, i don't think i've ever read him claim that he invented databases or had the initial idea to commercialize ibm's ideas. that's something that the media projects onto him since he's such a celebrity compared to his co-founders.

   Show morethread