Bryan Olson wrote: > Ben Sizer wrote: > > It's not a crackpot theory. It's a completely reasonable theory. SQL is > > based on relational algebra, which provides a mathematical set of > > operators for grouping data that is stored in separate sets. That data > > is selected and projected according to its value, and nothing else. The > > concept of it having a 'type' has been overlaid on top of this, > > presumably to facilitate efficient implementation, which tends to > > require fixed-width rows (and hence columns). It's not necessary in any > > sense, and it's reasonable to argue that if it was trivial to implement > > variable width columns as efficiently as fixed width columns, that > > explicit data types might never have needed to exist. > > The mathematical definition of the relational model includes > that data values are drawn from specific sets.
Well, I did say relational algebra, which from what I understand predates the official 'relational model'. > Implementing variable width columns has nothing to do with it. On a practical level, it has lots to do with it! > Here's > the reference: > > 1.3. A Relational View of Data > > The term relation is used here in its accepted mathematical > sense. Given sets S1, S2, ยทยทยท, Sn, (not necessarily > distinct), R is a relation on these n sets if it is a set > of n-tuples each of which has its first element from S1, > its second element from S2, and so on [1]. We shall refer to > Sj as the jth domain of R. Does it specify anywhere that sets S1...Sn cannot each be the universal set? To put it another way - although the spec implies the existence of limited set domains, and data types enforce limited domains, I don't think a requirement to allow limited domains is a requirement for static data types. -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
