I am a developer (student) looking for some advice on what best approach should I follow while creating a table to model an entity that has a number of optional fields.
There exists a need to model an Organization
entity with a few key fields such as id
and name
. There is also a join table from Users
to Organization
that specifies who belongs to the Organization
and what their role(s) are.
The question I have pertains to a number of optional fields that belong to the Organization
, such as website
, email
, and social links
. Below are my ideas of approaching the problem thus far:
- Add them to the table as optional fields
- Pros: Easy CRUD on one table, faster than navigating joins, etc.
- Cons: It seems a bit dirty to me. Might it become difficult to do migrations in the future?
- Create a
contact_information
table that references anorganization_id
, references acontact_type_id
(of website, email, Facebook, etc.) from a lookup table, and has a genericvalue
field for the actual content.- Pros: feels cleaner, allows for an arbitrary number of contact types in the future
- Cons: probably a lot slower. Tons more tables.
I am leaning towards #2, because it is a similar approach to what I'm doing for physical addresses, but I'm unsure whether or not it is the best solution as DBA is not my forte. If there is a 3rd or even 4th option that I am unaware of, I'd be really interested to hear of those as well.
Best Answer
Your second option is more flexible, but I'm not sure why you're worried about "tons more tables". Usually this would be done with a single table:
populated like this:
This schema only has 3 tables (not "tons") and you can have as many contact types as you want. The joins aren't that complicated. Your
contact_details
table will be large as there is 1 record per piece of contact info, but unless you have "tons" of contact info for each organization and "tons" or organizations, this probably won't be too big a problem. ;)You could also have a
contact_details
table which stores all of the fields. Something like this:This structure is much simpler but is more static. If you don't plan to change your set of contact data very much, and you think that most records will have most (or above a certain threshold of) fields filled out, I suspect this would perform better.