Abstract versus Separate table design

Question

My question is what are the best practices for database/application design for the following ?

I use Code First Entity Framework and .Net MVC 5. There are common functions I want to implement on different entities. For example consider the following simplified example:

class Person{
 int PersonId;
 string name;
}

class Member{
 int PersonId;
 int GroupId;
}

class Group{
 int GroupId;
 string name;
}

class Label{
 string name;
}

So 2 entities person and group that have a many-to-many relationship. Now I want to add Labels to each to filter the data based on business logic. There are a few ways to go about it:

1. Separate "ObjectLabel" table that has "fake" FK references to any table with a type column. This is probably bad practice but can simplify code implementation and give greater flexibility.
2. A string column on each entity to save e.g. comma delimenated list of labels. Benefit of simple database but will be slower when the data scales.
3. Seperate tables namely "PersonLabel","GroupLabel" etc to preserve referential integrity for quick look ups but seems redundant and will require more work.

Now I would like some advice on which approach is best and why ?

Answer 1

Depending on what the labels are, and how dynamic they will need to be, you could look into using Enum flags. That would still only require a single column per table, and would certainly scale better than having a comma separated list in a column.

You can see an example here or here of how to go about it.