> Well, if you also have soundcard_products, in your example you could have a
> product which is both a networkcard AND a soundcard. No way to restrict
> that a product can be only one 'subclass' at a time... If you can make that
> restriction using the relational model, you can do the same as with
> subclasses. But afaict that is very hard to do...
>
Perhaps I'm mistaken, but it looks to me as if the relational model still
holds quite cleanly.
CREATE TABLE products (
id int4 primary key,
name text );
CREATE TABLE soundcard (
prod_id int4 REFERENCES products(id),
some_feature BOOLEAN);
CREATE VIEW soundcard_v AS SELECT * FROM products, soundcard WHERE products.id
= soundcard.prod_id;
CREATE TABLE networkcard (
prod_id int4 REFERENCES products(id),
hundred_base_t BOOLEAN);
CREATE VIEW networkcard_v AS SELECT * FROM products, networkcard WHERE
products.id = networkcard.prod_id;
Now, to get the networkcard/soundcard combos, you just need to do:
SELECT * FROM soundcard_v, networkcard_v WHERE soundcard_v.id =
networkcard_v.id;
For what it's worth, I didn't make any mistakes writing it up the first time.
It most certainly "fits my brain" well and seems simple and clean.
I am not advocating that we remove inheritance, but I (so far) agree with Curt
that it's pretty useless.
Regards,
Jeff
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
