Contact DB, relational design, opinions please

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