SQLwaterheadretard3 (Was: Is it just me, or is Sqlite3 goofy?)

[Bryan Olson]

Ben Sizer wrote:
> 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'.

Relational algebra got into it when you said "SQL is based on
relational algebra". SQL is based on the relation model.
Incidentally SQL's expressions are closer to relation calculus
than to relational algebra.

Furthermore, relation algebra does deal with types. One can,
for example, infer the type of a result from the type of the
operands.


>> Implementing variable width columns has nothing to do with it.
> 
> On a practical level, it has lots to do with it!

There are subtler points on that, but it's not the issue here.

>> 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?

No; it indicates that they can be different, and when they are,
value not of the given set are not legal.

> 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.

One might argue that a one-atom-type-only DBMS can still be
relational, but that's not what SQLite offers. As we've seen,
one does declare the type of a column, and the DBMS seems to
prefer the stated type in that it will sometimes convert
values of other types.


-- 
--Bryan