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

Question

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

Мне нужно включить слишком много перечислений на основе приложений.

Что посоветуют эксперты?

Answer 1

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

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

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

Answer 2

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

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

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

Город и область/состояние:

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

Answer 3

Как Флориан, мне больше нравится иметь тонны внешних ключей, а затем ПРОВЕРИТЬ В (..) - по простой причине: вы можете вставить другие записи в свои таблицы.

Maintaning 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

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

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

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