0

I have to implement a testing platform. My database needs the following tables: Students, Teachers, Admins, Personnel and others. I would like to know if it's more efficient to have the FirstName and LastName in each of these tables, or to have another table, Persons, and each of the other table to be linked to this one with PersonID.

Personally, I like it this way, although trickier to implement, because I think it's cleaner, especially if you look at it from the object-oriented point of view. Would this add an unnecessary overhead to the database?

Don't know if it helps to mention I would like to use SQL Server and ADO.NET Entity Framework.

marc_s
  • 732,580
  • 175
  • 1,330
  • 1,459
Tanatos Daniel
  • 558
  • 2
  • 9
  • 27

4 Answers4

1

As you've explicitly mentioned OO and that you're using EntityFramework, perhaps its worth approaching the problem instead from how the framework is intended to work - rather than just building a database structure and then trying to model it?

Entity Framework Code First Inheritance : Table Per Hierarchy and Table Per Type is a nice introduction to the various strategies that you could pick from.

As for the note on adding unnecessary overhead to the database - I wouldn't worry about it just yet. EF is generally about getting a product built more rapidly and as it has to cope with a more general case, doesn't always produce the most efficient SQL. If the performance is a problem after your application is built, working and correct you can revisit and fix up the most inefficient stuff then.

chrisb
  • 2,200
  • 1
  • 20
  • 23
0

If there is a person overlap between the mentioned tables, then yes, you should separate them out into a Persons table.

If you are only tracking what role each Person has (i.e. Student vs. Teacher etc) then you might consider just having the following three tables: Persons, Roles, and a bridge table PersonRoles.

On the other hand, if each role has it's own unique fields, then you should carry on as you are and leave each of these tables separate with a foreign key of PersonID.

ElliotSchmelliot
  • 7,322
  • 4
  • 41
  • 64
0

If the attributes (i.e. First Name, Last Name, Gender etc) of these entities (i.e. Students, Teachers, Admins and Personnel) are exactly the same then you could just make a single table for all the entities with PersonType or Role attribute added to distinguish each person's role. However, if the entities has a lot of different attributes then it would be better that you create separate tables otherwise you will have normalization problem.

Edper
  • 9,144
  • 1
  • 27
  • 46
-2

Yes that is a very bad way of structuring a DB. The DB structure should be designed based on the Normalizations.

Please check the normalization forms.

U should avoid the duplicate data as much as possible, else the queries will become slower.

And the main problem is when u r trying to get data that is associated with more than one or two tables.

Sandeep Rao
  • 341
  • 3
  • 9
  • 22