6 ms·
> What makes this book different? We feel there are two key features that make it stand out: its strong focus on the relational model, and its thorough treatmen
by jrochkind1 5y ago
> What makes this book different? We feel there are two key features that make it stand out: its strong focus on the relational model, and its thorough treatment of type theory (and together, of course, the relational model and type theory are precisely the foundations referred to in the previous paragraph). To amplify:
> * The relational model: We must stress that what we are not doing is proposing some kind of “new” or “extended” relational model. Rather, we are concerned with what might be called the “classical” version of that model; we have tried to provide as careful and accurate a description of that classical model as we possibly can. It is true that we have taken the opportunity to dot a few i’s and cross a few t’s (i.e., to perform a few minor tidying activities here and there); however, the model as we describe it departs in no essential respects from Codd’s original vision as documented in references [20-22]. (Indeed, we even toyed at one point with the idea of calling the book A Relational Model of Data for Large Shared Data Banks.)
> * Type theory: Relations in the relational model have attributes, and those attributes in turn have types (also called domains). Thus, the relational model certainly assumes that types exist. However, it nowhere says just what those types must be, nor does it have much to say about what properties those types must have; in other words, the relational model and type theory are almost completely independent of each other (they are orthogonal, to use the jargon). In this book, we present a detailed theory of types that complements the relational model, and we explore some of its implications. In particular, we show that our type theory serves as a basis for a comprehensive model of type inheritance.
- deleted 5y ago[deleted]
- hikerclimber1 5y agoEverything is subjective. Especially laws.
- throwaway894345 5y agoOn the subject of types, I’ve often wondered why relational databases don’t have sum types. Lots of real-world data models have these kinds of relationships, and certainly “modeling data” is well-within the purview of a database. I know that ORMs exist, but they tend to be very bad and there’s no compelling reason to have to break off part of the database responsibility, implement it terribly (it’s divorced from the query planner, so even the best ORMs are subpar) for each application language, and put it on the client side. Yes, I understand that sum types affect the way the data is arranged, but the same approaches that are used by programming languages to model sum types in memory can be used by databases to model sum types on disk and in memory (it’s all just byte vectors at the end of the day).
- zaphar 5y agoI suspect part of the problem is that true sum types are poorly represented in many of the languages that use these databases. In a sense because of the layer these sit in the stacks they have to appeal to a lowest common denominator. If they supported tables where the rows were true sum types and polymorphic as a result many languages would find it quite difficult to interact with that database.
- throwaway894345 5y agoI don't understand why that would be a problem--programming languages interact with databases at runtime via SQL. I regularly use Go which lacks sum types, but there's nothing technically difficult about generating SQL that leverages sum types--except that SQL doesn't support sum types :).
- zaphar 5y agoIn Go returning a list of items that are one of a set of different types would be poorly handled. It's possible but very awkward. You would probably drop down to just a slice of interface{} and then have to use reflection to figure out what each item was. Dynamic languages like Python or Ruby would probably be fine but there are more languages than those out there to worry about.
- throwaway894345 5y agoThere are ways of modeling sum types in Go (a struct with a few fields and a tag, an interface that's only implemented by the relevant types, etc), but that's unrelated to the database/client interface.
- blacktriangle 5y agoNot a part of the SQL standard, but would PostgreSQL enumerated types be what you're thinking of? https://www.postgresql.org/docs/current/datatype-enum.html https://www.postgresql.org/docs/current/datatype-enum.html Although I guess the question is are you thinking sum types at the attribute level or sum types at the relation level? At the relation level I'm not familiar with an answer, but I can see where that would be a nice database-level solution for polymorphic associations.