Re: Attribute-values in separate table

From: Brian Selzer <brian_at_selzer-software.com>
Date: Tue, 4 Sep 2007 00:51:51 -0400
Message-ID: <Hv5Di.8005$924.4606_at_newssvr23.news.prodigy.net>


<anjasmedts_at_hotmail.com> wrote in message news:1188551701.232978.17290_at_r23g2000prd.googlegroups.com...
>> Why not just have a "HasLock" relation with the id's of the furniture
>> with locks? And a "HasWheels" relation with the id's of the furniture
>> with wheels?- Tekst uit oorspronkelijk bericht niet weergeven -
>
> Your solution creates a lot of similar tables, whereas mine groups all
> those tables into one.
> Creation of new attributes on the fly is done adding a record in my
> solution and creating a new table in yours.
> So my opinion is that my solution is preferable.
>
> But I'm open to all remarks!
>

You are vastly oversimplifying. If you need to create a new attribute, you need to add a record for each piece of furniture to which that attribute applies. Your solution also makes it very difficult to define constraints. How, for example, do you control which attributes apply to which types of furniture? How do you prevent the insertion of a record that does not make sense? Constraints are supposed to be defined and enforced in the database, not the application. Stuffing everything into one table increases the complexity of those constraints. You can't even use simple type checking, since (correct me if I'm wrong) the attribute, Value, can have values with different types! There is nothing wrong with having a lot of similar tables. Having a separate relation for each type of atomic fact is a good thing, because it simplifies the representation of information. Received on Tue Sep 04 2007 - 06:51:51 CEST

Original text of this message