Слишком много таблиц поиска

Question

Каковы неблагоприятные последствия наличия слишком большого количества справочных таблиц в базе данных?

Я должен перенести слишком много Перечислений, основанных на приложениях.

Что бы посоветовали эксперты?

Answer 1

Вначале вы должны спросить себя: «Сколько это слишком много?». Если между двумя таблицами существует логическая связь, должен быть FK.

Если вам не нужны связанные таблицы где-либо в базе данных, вы можете удалить их и использовать ограничение CHECK с предложением «IN» для обеспечения достоверности данных. Однако это может привести к изменению таблицы с каждым новым значением в перечислении.

Мой личный совет - держать ФК и столы. Это четкое решение, и базу данных лучше поддерживать, если для всех этих чисел .

доступен текст описания.

Answer 2

Позвольте мне рассказать, как ужасно иметь слишком мало таблиц поиска.Оригинальные дизайнеры в одном месте, где я работал, решили поместить все поиски в одну таблицу и определить, какие поиски были для использования typeid.Это привело к тому, что почти все запросы попали в эту таблицу, чтобы получить описательное значение поиска, что привело к снижению производительности.

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

Создайте 1000 справочных таблиц, если это то, что вам нужно.

Answer 3

Как Флориан, мне больше нравится иметь тонны внешних ключей, чем иметь CHECK IN (..) - по простой причине: вы можете вставлять другие записи в свои таблицы.

Поддержка CHECK IN() гораздо большая проблема.Представьте себе этот сценарий:

CREATE TABLE street
(
   id serial not null,
   st_type varchar(20) not null,
   st_name varchar(100) not null,
   constraint street_pk primary key (id)
   constraint street_type_check check st_type in ('STREET','AVENUE','SQUARE')
);

У вас есть 1000 строк с этими типами проверено, верно?Если вам нужно добавить еще один, вам нужно будет удалить ограничение и воссоздать его.

Если вы удалите элемент из этого списка, например, SQUARE, что произойдет с уже зафиксированными строками (и проверено в данный моментвставки), которые имеют этот тип?Они по-прежнему будут содержать недопустимый тип.

Таблицы и внешние ключи легче поддерживать и отслеживать.

Answer 4

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

если это не конечный список идентификаторов для конкретного процесса или оператора where, то они не должны быть поисковыми значениями.

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

Город и провинция / штат:

Их список ограничен, но из-за того, что их слишком много, вы, возможно, не захотите искать их.