I am sure you've all run across the idea of 'required' duplication of information in your databases. This is the idea of for instance, a person in the employees table can also be a customer but you must enter the information twice, once in the employees table and once in the customers table.

Not 'really' a big deal, but we are investigating methods to automatically handle this without entry duplication.

In this simple example, we see unique information as a 'Person' so we have a Persons table

Persons

• PersonId
• LastName
• FirstName

Then we have an Employees table

Employees

• PersonId
• SocialSecurityNumber

And we have a Customers table

Customers

• PersonId
• ShipAddress
• BillAddress

I wish I knew at the moment how 'abstract' the Person is going to be to say, 'we won't create a Person Entity (datarow) directly, but I would like to have that as an option in my pocket if needed.

I am wondering the best way to handle this and use typed DataSets.

What is the best design path to design Typed DataSets for Employees and Customers. Is this a simple matter of two DataTables with a DataRelation? Or is it better/cleaner to Design a PersonData DataSet and have everything MustInherit (DataTable, DataRow, etc) in the DataSet?

I want it to be as straight foreward as possible from a UI and/or BusinessLayer developer. I want to keep the hoop jumping down to a bare minimum and still maintain a high standard of 'usefulness'.

I hope I wasn't too vague or hard to understand, we are only in the process of thinking about this idea/design.

Best regards,

CN

I might be able to help YOU this time!

Ignoring for the moment the .Net bits, in Access you can handle this with an intermediate table that holds all the data common to the two types (Employees and Customers) such as firstname, secondname etc.

You then have a 1-1 relationship to the other two tables which contain the additional data that differs between the types. The personid can then link to either Employees or Customers or both.

I used this some time ago but can't help you with the .Net bit yet!!

Hope this is of some use. Thanks for help on the other matter.

Ken

My opinion is that I think you would be best served making a single DataSet with multiple DataTables in it and add primary/foreign keys to the tableswith DataRelations between them.

I know we struggled with this question when we first started using .NET a few years ago. We'vetried bothand we've found this way to be much clearer and easier to work with than one table with everything in it. It's still easily accessible and bindable and it will be simpler looking at the DataSet and Database since they will look the same.