Re: Contact DB, relational design, opinions please

Learn how to express the requirements in the form of an ER (Entity Relationship) model.

Learn how to normalize.

Learn when to normalize.

Learn what to do when you don't normalize.

Study some good designs.

NULLS can help you if you use them right. They can shoot you in the foot if you use them wrong.

--
Regards,
    David Cressey
    www.dcressey.com
"Elvis K. Ing" <elvis_the_king_at_web.de> wrote in message
news:3b9632dd_at_netnews.web.de...


> Hello everyone,


>

>

> I am about to design a RDB, and would like to hear your opinions regarding

some


> design issues.

>

>

> Basically, the DB will be the backend for a web based contact management


system.


> For each contact, lots of information (first name, surname, address) will


have to


> be stored. Many of these fields are optional values.


>

>

> First question: How would you design the relations? Have distinct

relations for


> each of these optional attributes, at the cost of a lot of joins? Or would


you


> stuff all closely related information in one relation and put up with NULL


values


> for some of the attributes?


>

>

> Furthermore, each contact in the database can be one of several types,

among


> these small investors, institutionals, journalists. Each type might


require some


> additional information to be stored, e. g. market segment, industry.


However,


> there are some intersections among these types. As an example, the


industry


> attribute might apply to financial analysts and institutional investors,


but not


> for small investors or journalists.


>

>

> Question: How would you design these "contact classes" in a relational

model? I


> think that there should be only one relation for each concept like market


segment


> or industry, as opposed to having a relation for additional journalist and


> additional investor attributes and having intersections among their

attributes.


>

>

> Which actions could be taken to keep the design as flexible as possible?


Maybe I


> will have to add further "contact classes" in the future, or add


additional


> attributes for a certain class. It might also happen that the domains for


some of


> the "common" attributes differ, depending on the "contact class".


>

>

> Thanks a lot for your opinions, any hints or starting points. (-> Are

there


> similar design issues documented or described somewhere?)


>

>

> Elvis

> --

> __________________________________________________________

> News suchen, lesen, schreiben mit http://newsgroups.web.de