Please start any new threads on our new site at We've got lots of great SQL Server experts to answer whatever question you can come up with.

Our new SQL Server Forums are live! Come on over! We've restricted the ability to create new threads on these forums.

SQL Server Forums
Profile | Active Topics | Members | Search | Forum FAQ
Save Password
Forgot your Password?

 All Forums
 General SQL Server Forums
 Database Design and Application Architecture
 Design Optimisation
 Reply to Topic
 Printer Friendly
Author Previous Topic Topic Next Topic  

Starting Member

United Kingdom
1 Posts

Posted - 01/18/2014 :  14:09:54  Show Profile  Reply with Quote

I am a University student and as part of our assignment we have been asked to optimise a given database design. I am not looking for a solution, just a topic/ area to research, as I need to learn this and need to reference it.

The current design has a "Person" entity and several inherited entities: "Owner", "Renter", "Buyer" & "Staff". I.e. The Primary key for "Person" is also the Primary Key for "Owner", "Renter", "Buyer" & "Staff" (They each have separate, additional, attributes).

I have been reading around Normalisation and security considerations but, I am not sure if these are the right areas. My thought is to separate the inherited entities into separate tables, making each one smaller and more secure. However, this will create multiple occurrences of data.

When it comes to database design, I am hopeless and apologies if this is a trivial issue. But, thanks in advance for any help.



Very Important crosS Applying yaK Herder

52326 Posts

Posted - 01/19/2014 :  05:26:12  Show Profile  Reply with Quote
It really depends. If attributes of Owner,Renter,Buyer and Staff are mostly the same, then best thing would be to keep them in same table with an additional column to indicate the Type value (Owner,Renter etc). You can either choose to store description itself inside type or you have a separate table to store type values and have an id as primary key. then add this field as foreign key field in your table to make it flexible. In case you need to store any (small number of) additional specific attributes you may ad an extended attribute table for that with fields AttributeID,AttributeName,AttributeValue and Maintable's id as FK.

SQL Server MVP
Go to Top of Page
  Previous Topic Topic Next Topic  
 Reply to Topic
 Printer Friendly
Jump To:
SQL Server Forums © 2000-2009 SQLTeam Publishing, LLC Go To Top Of Page
This page was generated in 0.04 seconds. Powered By: Snitz Forums 2000