Re: Is multi-type data in one field normal?

>> At best you can claim that SQL was inspired by the relational
model. <<

Agreed. Welcome to the real world!

>> Second the relational model is orthogonal to the type system used
for the domains. Relational algebra and relational calculus deal with <<calculus over relations (which by the way is not supported in SQL). <<

No. The types in a relational algebra or calculus have to support joins and set operations. In Codd's relational model that means Theta operators, scalar values and NULLs.

>> Chris Date clarified this subject, both in his books, and in a not
so old post on comp.database.theory. <<

I have never seen Chris post to a newsgroup...

>> I'm affraid that the kuldge you are referring to belong to the SQL
standard itself. It is unacceptable in 2003, after 4 decades of advanced research in type theory, and after 30 years from the implementation of the first advanced type system *provably* sound, to "debate" about basic things like whether to support *boolean* as a data type, or even about a sum types. <<

You are missing the point of SQL. It is a data retrieval language designed to work with ANSI/ISO standard host languages. Its type system has to be simple and fairly universal to match host languages, present and future. It is not an exercise in Computer Science research; how many applications are written in any of the languages you mentioned in this thread?

>> Please have a break and at least read the very basic introduction:
Robert Constable "Naive Type Theory", <<

Thanks for the reference. I noticed that some of the websitews you gave are only a year old, so I don't feel too far behind.

>> My collection of books on databases include books by Date,
Abiteboul Hull & Vianu, Thalheim and a few others. I think it is enough until database theory advances a bit more. <<

Date's essay collections and books are good; you can follow the evolution of his relational model and his constant claims that there are no changes to his RM. You also need to look at Stonebreaker and the last few decades of SIGMOD, ACM and IEEE publications -- databases have changed a bit <g>.

>> So more to the point, if this is being done in SQL database, that
is
absolutely no justification for us to descend to the primitive level of
the typical SQL database implementation. <<

Well, if you don't want your code to work or really like writing kludges, that would be the way to do it ...

>> There is the notion of sum types and the term "sum" is not randomly
chosen, it has a direct correspondent in category theory where you have the sum category, also it has an analogue in vectorial spaces where you have the sum space and in many other branches of mathematics. <<

Never run into the term before; I've seen "variant" or "union" for the same concept in Comp Sci.

>> The fact that SQL's type system is limited should not prevent you
from using a better type system in the abstract (including union type), and then "encode" or translate your design using whatever SQL facilities you see most fit for that purpose. <<

Because SQL was based on Codd's relational model, you need to move from the conceptual level down to the implementation level via a relational approach, not with an abstract type system that is not supported in SQL or in the host languages (note the plural -- never write a database for one and only one host language).

>> [There's nothing wrong in principle with having a column that is a
type discriminant] ... [Yes, there is. It's called First Normal Form (1NF) and it required scalar, atomic values from one domain.] In the case we're talking about the first column was all integers. <<

Integers are HOW a domain is represented; you have not told me what the domain itself is. Consider a column for the attribute "temperature"; I might use Fahrenheit, Celsius or Kelvin as as my scale and show them as integer values (or I could use a ranking scale ('hot', 'warm', 'cool', 'cold') for that matter. You are confusing the levels in the model again.

>> And speaking of that case you presented no satisfactory practical
solution. <<

Unh? Why do you think that a normalized database is not a satisfactory practical solution? I make a living fixing databases because people haved that attitude ...

>> ... in practical languages like ML, Haskell and most advanced
programming languages of today support union types. <<

"practical"?? How many lines of code do you think I will find in the ML and Haskell languages on the entire planet? The longest Haskell program is a Haskell compiler. APL, FP, etc. are pretty much gone. Most programmers don't have the math to do Lambda calculus or list processing. The compilers are not that good for any functional languages except LISP.

Obviously, I like functional languages with strong typing, but SQL and LISP are the only ones that have caught on to any extent. Maybe .NET and WebSphere might be the answer.

>> You can bet modern languages make the sum type not only safe, but
an essential instrument into expressing algorithms and data structure in an elegant and efficient way.

 type 'a binTree=

          Empty
          | Node of  'a binTree * 'a * 'a binTree
 

This one is a tree of elments of type 'a (meaning any type can be substitude for `a) composed either from an empty node, or a node that is defined as the triple (left subtree, element in the node, right subtree) <<

Now do a JOIN on columns with that type, using theta operators that EVERY database on earth agrees go with the binary tree type. This is the problem with User defined types -- given (n) users, you get (n) different data types with subtle differences.

>> Most of the programming languages in current don't support even the
numeric types form SQL standard. <<

Unh? Look at the X3J language Standards and their conversion rules for SQL datatypes. We spent a lot of time getting the rules in place.

>> Not to mention that in spite being unable to introduce basic "type
constructors" like the sum type (aka union, but it is much more than the C union), they ventured into murky waters by specifying OBJECT features that no sane software engineer should ever want to use. <<

I have a big hate for some of the OO influence in SQL-99; arrays, XML, etc. just need to be dropped as soon as possible. I don't even like cursors! Received on Fri Apr 25 2003 - 04:08:09 CEST