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 <[EMAIL PROTECTED]> 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 > > > > >
