Creating database tables with same columns or one master table

Question

I am building a website with large database, there's 6 types of data, so 6 forms to pass data to database. Each form has unique parameters, and 4 of 6 forms have the same fields and the fields can contain multiple data: email, address and phone can be multiple on 4 forms.

For the first i wanted to created 4 different tables like: store_contacts, warehouse_contacts, delivery_contacts, etc. to keep different types separated. so i would have 4 similar tables containing the same fields:

id, phone, email, address, store_id/delivery_id/etc

I have read that better practice to create one table containing them, table Contacts:

id, type, type_id, phone, email, address

from similar questions:

1. Two tables with same columns or one table with additional column?
2. https://softwareengineering.stackexchange.com/questions/302573/one-wide-table-or-multiple-themed-tables
3. https://dba.stackexchange.com/questions/46852/multiple-similar-tables-vs-one-master-table

But i'm not sure if tables will change later and new fields will be added for store only or only for delivery. and apart from contacts i have similar situation for other fields.

Would it be comfortable to make queries with type every time i need to pull data for certain type or when i need to delete them? Won't it get messy when a lot of rows will be inserted? And if a new field will be created for 'store', it is okay that others will contain NULL on that field?

Answer 1

Probably you should read a bit about Relational Entities or Object Orientation - inheritance, depending on the paradigm you are working.

For example, you can get aware about it in articles like this

Usually you should store contacts in a separate and exclusive entity, for a plenty of reasons. Sector-specific fields can be stored in each table, only if you are sure that there would be no use for them in another entities. For example: warehouse_contacts would have an imaginary employee id field to represent an employee in warehouse repsonsible for attending a given contact. Even though, proably the best practice would be to build a third table managing this information.

Nevertheless, if performance is an issue, I mean, if you have millions of records and dozens and dozens of simultaneous access in your website, maybe your Data Base would run faster in fewer tables, not so normalized. But this situation is quite improbable for most enterprises and users. Rather, this situation is kind a common practice in large-scale and legacy systems.

Good luck.