Одно истинное преимущество таблицы поиска по сравнению с недостатками

Question

Итак, я прочитал достаточно, чтобы знать, что наличие одной справочной таблицы - не лучший способ.С точки зрения производительности, почему это?Рассмотрим следующий пример:

У вас есть список школ в городах.В одном городе может быть несколько школ.Итак, у вас есть соединительный стол между городами.Теперь рассмотрим список предприятий.в каждом городе может быть более одного бизнеса.Итак, у вас есть распределительная таблица businessCities.Вопрос на самом деле таков: почему так плохо, если вы просто используете одну таблицу городов и создаете соединительную таблицу для школ и предприятий, а не для каждой таблицы школ и предприятий со своей собственной копией таблицы городов?

Answer 1

На самом деле, у конструкции OTLT могут быть некоторые преимущества (сейчас я буквально чувствую взрывающиеся головы).

Модель, которую я видел, действительно хорошо работает, будет выглядеть примерно так:

LookupId, LookupTypeId, LanguageId, Description (отображаемые данные)

Тогда ваши параметры всохраненный процесс.было бы просто typeid (чтобы получить весь этот тип).Если вам просто нужно преобразовать Id определенного типа, вы просто передадите LookupId.Будет установлен язык по умолчанию (в нашем случае это был английский).Это был отличный способ обработать отображаемые данные сайта в многоязычном формате.

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

То, как я на это смотрю, если вы имеете дело только с небольшими выпадающими данными и т. Д.(типичные приложения для отображения приложений), он может предложить большие преимущества с точки зрения производительности, обслуживания и простоты добавления новых типов.

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

Только мои 2 цента.Я уверен, что у меня будут вычтены очки или что-то еще за непопулярную позицию по этой теме.

Answer 2

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

CREATE TABLE TheOne (
    LookupType varchar(20) NOT NULL -- City, color, shoe size...?
    , LookupValue varchar(1000) NOT NULL -- how big does it have to be?
    , CONSTRAINT pk_TheOne PRIMARY KEY (LookupType, LookupValue)
)

, и у вас могут быть значения:

'City', 'Philadelphia'
'City', 'St. Petersburg'
'City', 'Paris'
'State', 'Pennsylvania'
'State', 'Florida'
'Country', 'United States'
'Country', 'France'
'Brand', 'Lucky'
'Brand', 'Diesel'
'Brand', 'Old Navy'

и так далее.Чистое зло.

Таблица городов, вероятно, связывает город с государством или другим родительским географическим регионом, поскольку может быть много разных городов с одинаковым названием (Париж, Лима, Левиттаун и т. Д.).