Question

I'm trying to workout the best database design for the following :

1) I have two (or more) tables in the database. "Sports", "Teams", "Leagues", etc..

2) Each of these tables can have a one to many relationship with another table in this case "Feeds"

The idea being that various database entities can each have a list of associated "Feeds"

It seems wrong to me to have multiple foreign key columns on the "Feeds" table, one for each of the tables (Sport, League, etc..), so my question is how best to model this?

It's worth mentioning that each feed can only belong to one of the other tables. A feed can't be associated with a "Sport" and a "League"

I've considered the following :

1) Add an additional column to each of the "Sport" "League" etc.. tables with a GUID.

2) Add another column to the "Feeds" table also with a GUID and populate this with the GUID from my other table, then query on this.

This would allow me to have multiple tables referencing the same column of the "Feeds" table but is this any better than having multiple nullable foreign keys, one for each table?

Was it helpful?

Solution

It is not a bad idea to have a foreign key pointing to Feeds in several tables. Foreign keys can be used to handle the 1:n relation (one-to-many).

It seems wrong to me to have multiple foreign key columns on the "Feeds" table, one for each of the tables (Sport, League, etc..), so my question is how best to model this?

Why do you think it is not a good practice, what would be the downside of this design?

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top