Database normalisation on user types

Question

I am trying to design a user database to cater for multiple users. Each type of user will have a different profile to fill out, e.g. business user will have a website field, business name while normal user will have e.g. data of birth, home address.

They will also share some common such as active, date registered, first name. From an object orientated approuch I would have a common base then inherit from the base to form seperate profiles. But from a database design approuch how should this be achieved? Should we have a common userProfile table then businessProfile. The user types will grow over time so the problem of repeating the same fields over and over could prove annoying but having a total normalised database could prove slow on joins.

Could anyone help me regarding this?

Answer 1

I would go with one main table containing everyone and several specialized (1 to 0 or 1) tables that only contain users of that type:

AllUsers
    UserID          int identity PK
    Active          char(1)?
    DateRegistered  date
    FirstName       {string}
    ..all other common columns here

BusinessUsers
    UserID    int PK and FK to AllUsers
    Website   {string}
    ..all business only columns

NormalUsers
    UserID    int PK and FK to AllUsers
    BirthDate date
    ..all normal user only columns

..any other user types tables as needed

If you need to load everything for a user do:

SELECT
    * --please only return the columns you actually need!
    FROM AllUsers                     u
        LEFT OUTER JOIN BusinessUsers b ON u.UserID=b.UserID
        LEFT OUTER JOIN NormalUsers   n ON u.UserID=n.UserID
    WHERE u.UserID=123

if you need to only load data for a specific type use:

SELECT
    * --please only return the columns you actually need!
    FROM AllUsers                     u
        LEFT OUTER JOIN NormalUsers   n ON u.UserID=n.UserID
    WHERE u.UserID=123
--or
SELECT
    * --please only return the columns you actually need!
    FROM NormalUsers   n
    WHERE n.UserID=123

Answer 2

I personally would go with profile tables (organized in logical groups - or one table to start but seriously, it gets possibly wide) and then handle "which profile needs which fields" in a separate metadata layer.