Создание таблиц базы данных с одинаковыми столбцами или одной основной таблицей

Question

Я строю веб-сайт с большой базой данных, есть 6 типов данных, поэтому 6 форм для передачи данных в базу данных. Каждая форма имеет уникальные параметры, и 4 из 6 форм имеют одинаковые поля, и поля могут содержать несколько данных: адрес электронной почты, адрес и телефон могут быть множественными в 4 формах.

Для начала я хотел создать 4 разные таблицы, такие как: store_contacts, warehouse_contacts, delivery_contacts и т. Д., Чтобы разделить разные типы. поэтому у меня будет 4 аналогичных таблицы, содержащие одинаковые поля:

идентификатор, телефон, электронная почта, адрес, идентификатор магазина / идентификатор доставки / и т. Д.

Я прочитал, что лучше создать одну таблицу, содержащую их, таблица контактов:

id, тип, type_id, телефон, электронная почта, адрес

из похожих вопросов:

1. Две таблицы с одинаковыми столбцами или одна таблица с дополнительным столбцом?
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

Но я не уверен, если таблицы изменятся позже, и новые поля будут добавлены только для магазина или только для доставки. и кроме контактов у меня похожая ситуация для других областей.

Было бы удобно делать запросы с типом каждый раз, когда мне нужно получить данные для определенного типа или когда мне нужно их удалить? Не станет ли это грязным, когда будет вставлено много строк? И если для 'store' будет создано новое поле, то нормально, что другие будут содержать NULL в этом поле?

Answer 1

Возможно, вам следует прочитать немного о реляционных сущностях или объектной ориентации - наследование, в зависимости от используемой вами парадигмы.

Например, вы можете узнать об этом в статьях вроде this

Обычно вы должны хранить контакты в отдельном и эксклюзивном объекте по многим причинам. Отраслевые поля могут храниться в каждой таблице, только если вы уверены, что они не будут использоваться в других объектах. Например: warehouse_contacts будет иметь воображаемое поле идентификатора сотрудника для представления сотрудника на складе, ответственного за посещение данного контакта. Хотя, вероятно, наилучшей практикой будет создание третьей таблицы, управляющей этой информацией.

Тем не менее, если производительность является проблемой, я имею в виду, если у вас есть миллионы записей и десятки и десятки одновременного доступа на вашем веб-сайте, возможно, ваша база данных будет работать быстрее в меньшем количестве таблиц, не так нормализовано. Но эта ситуация совершенно невероятна для большинства предприятий и пользователей. Скорее, эта ситуация является обычной практикой в ​​крупных и унаследованных системах.

Удачи.