Схема оформления вопроса

Question

У меня есть отраслевая справочная таблица: ID, Имя.

У меня есть другие отраслевые свойства, такие как отраслевой сектор, отраслевой сервис, отраслевые продукты и т. Д. Все эти свойства являются обязательными для каждой отрасли, поэтому для любой вводимой отрасли эти данные будут. Эти данные являются фиксированными элементами списка, такими как отраслевой сектор = (первичный, вторичный, третичный). На сайте эти значения будут либо автоматически предлагать, либо выбирать из выпадающего списка. Также они будут использоваться в качестве поисковых фильтров для дальнейшей фильтрации отраслей на сайте. И они будут использоваться для составления отчетов, таких как -> Отображение количества компаний, относящихся к отраслям первичного сектора, только от людей, с которыми вы дружите.

Для схемы я вижу два способа ее создания:
1) Таблица отраслевого поиска будет содержать все эти дополнительные данные в виде текста
2) Дополнительные данные будут храниться в виде идентификаторов, которые FK ссылаются на свои таблицы поиска.
3) Открыты и для других дизайнерских идей.

Проблема с # 1: не будет никакого обеспечения качества данных.
Проблема с # 2 заключается в том, что существует множество фиксированных элементов списка, поэтому каждый из них имеет свою собственную таблицу поиска, что означает наличие множества таблиц поиска и FK для родительских таблиц.

Я не уверен в реальном мире крупномасштабных систем, как это делается. Индустрия - это только одна организация; У меня много сущностей, и у каждого есть как минимум 40-50 фиксированных элементов списка (столбцов), так какой путь лучше? Для получения дополнительной информации это веб-сайт с пользовательским контентом - профессиональный сетевой сайт, поэтому важна производительность.

Предложения

Answer 1

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

Answer 2

Это все необходимые свойства для каждая отрасль, так что любая отрасль введенные будут иметь эти данные

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

Поэтому я предлагаю # 3:

Вместо того, чтобы искать таблицы для каждого свойства, имейте только одну. Таким образом, у вас всего четыре таблицы:

industries (id, name)
industry_property_names (id, name) // Contains the name of the property, e.g., Industry sector
industry_property_values (id, industry_property_name_id, name) // Primary, Secondary, tertiary
industry_properties ( (pk: industry_id, industry_property_name_id), industry_property_value_id)

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