Re: Database normalization

Hi

I would create one table to log updates with type field and one id filed
that contains either client id or service id according to type. On such a
table i would forget about foreign keys (thay are better to be avoided
anyway if you have millions of records in tables).
That way you can share code that displays update history or even create some
generic components.
In my experience normalized databases have ended up with hundreds of tables
and code and screen generation that is very far from what users actually
need. Denormalizing and refactoring these databases reduces number of tables
by magnitude.

Regards,
Asko

On 8/28/07, Sebastian Ritter <ritter(dot)sebastian(at)gmail(dot)com> wrote:
>
> Hello,
>
> >
> > I have a fairly basic question about database design where im not sure
> > which approach is considered correct.
> >
> > I have two different entities: Clients and Services. Both allow users to
> > add progressive updates about the two entities.
> >
> > The update/message format is exactly the same for both. Should I make
> > two different tables:
> >
> > client_updates and service_updates
> > or
> > one table with extra columns : is_client, client_id, service_id, where
> > either client_id or service_id would be null depending on the is_client
> > boolean?
> >
> > The major problem is simply relating the foreign key in the updates
> > table back to the correct entity, client or service.
> >
> > Regards,
> > Sebastian
> >
> >
>