"Lincoln Yeoh" <lyeoh@xxxxxxxxxxxxx> 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! ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
