"Lincoln Yeoh" <lyeoh@pop.jaring.my> writes:
> The correct way to store types and subtypes in the database is to store them
> in the columns. In other words, choose attribute VALUES from a TYPE SYSTEM.
> Nothing else in the relational model needs to be changed. Something like
> this, in hypothetical SQL-like language:
That's what we call "denormalized" data in the database world. This is why
there's such a big impedance mismatch between procedural languages and
relational databases.
The natural place to end up in his world would be to have every table have
precisely one column which is some kind of object. Then you access fields and
methods on those objects.
The problem is that then you don't have a relational database since it's
awfully hard to tell the database you have a foreign key from whatever this
method returns here to whatever that method returns there for some record
somewhere... And it's awfully hard to index and join between complex
expressions picking data out from inside objects on both sides, etc.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's PostGIS support!