kogerbnz wrote:

> Hello
>
> Let me start by saying that I'm new in the database world. So now that
> you know, here is my problem :-)
>
> I have multiple "items" that share several attributes. So being a
> OO-programmer, I instantly think of a class hierarchy. Having a
> abstract base class with the common attributes, and then multiple
> entity classes inheriting from the abstract base class, and adding
> their specific attributes.
>
> But how do I implement such a relationship in Firebird. Here is my idea:
>
> Item table:
> ID (PK) (auto incremented)
> ItemType (FK or domain, more on that later)
> The common attributes
>
> Book table:
> ID (PK) (same ID as in item table, so not auto incremented)
> The book specific attributes
>
> CD table:
> ID (PK) (same ID as in item table, so not auto incremented)
> The cd specific attributes
>
>
> Is that a good generalization design?
>
>
> About the ItemType column. I see two ways to implement this
>
> 1)
> Use a ItemType table:
> ID int (ID, is going to be foreign key in Item table)
> Type string (would be "book" or "cd")
>

Your suggested implementation would be ok, even though *if* the BOOK and
CD items have a lot in common, it would probably be better to use the
same table, even if there are a few fields that have to remain NULL for
either item eg:

ITEMTYPES(ItemTypeId int, descr varchar(20));
[ 1, 'cd'
2, 'book'
]

ITEMS(ItemId, ItemTypeId int REFERENCES ItemTypes(ITEMTYPEID),
Author, , Title, ISBN....)
[ 1, 1, 'Bob Marley', 'Exodus', NULL, ...
2, 1, 'Stevie Wonder', 'Time to Love', NULL, ...
3, 2, 'Hellen Borrie', 'The Firebird Book', 'XXX-XXX', ...
]

In this case, there is a lot more generalization than probably would be
acceptable in strict OOP. Grab a good book, or Google for 'Relational
Database Concepts' for more details.

> 2)
> Another way would be using a Domain, it seems easier.
> But is domain good practice?
> If I in the future would move to another database, would using domain
> give me trouble?

A domain is usually a good idea but when moving to a DBMS that is not
Domain-aware, it may present a problem when exporting the schema, but
not when exporting the data. I however do not see how a domain or lack
thereof, is relevant to the design issue at hand.

Regards

James