I want to persist contact details for persons. This contact details can belong to a client, or a next of kin member, or whatever other entity. I'll be using Doctrine2 in a Symfony project, that will handle the data integrity.
It is a good practice to have such contact table which stores contacts for any kind of 'parent' entity or should a I have different tables like client_contact & next of kin?
Best Answer
Your current diagram is great as long as everyone only has one address, and a max of two phone numbers (apart from a fax).
One simple way this schema falls apart is if you have a client with a street address for their location, but a PO Box for their mailing address. This is a fairly common setup for rural communities in the United States. When I lived in Jackson, Wyoming I had a street address which had a different zip code from my PO Box. In addition my work address was in another city. The core point is people can easily have more than one address, which conflicts with your schema.
Personally I would break apart the address from the phone number. This gives you more freedom over your data. Entities can have addresses without phone numbers and phone numbers without addresses without risking a foreign key to a row full of nulls. Furthermore I would add a foreign key to the address and phone number tables that is just a link to a description. That way you don't need to remember "PhoneNumber2 is always a cell phone, unless this is a business in which case it is the point of contact's direct line" or other such nonsense. The foreign key to the description table will make it clear that Client X has two home landlines and no cell phones. You gain flexibility and clarity.
Overall, I still would keep one address and one phone number table that the various entities would link to via foreign keys. There is no need to duplicate schema. Keep in mind it might be advantageous to have the foreign key to the address/phone table on the entity for some entities and other entities might use a join table instead. That can be a per entity judgment call which can be adjusted over time with relatively little pain.
Also you might want to associate the "next_of_kin" table with someone (your clients?), because it seems kind of weird for them not to have kin... :)