Почему использование является общей справочной таблицей для ограничения состояния объекта неправильно?

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

Существует множество причин, по которым «таблица поиска для завершения всех таблиц поиска» является плохим подходом, в том числе тот факт, что вы не можете определить отношения, и объединение становится более трудным, чем должно быть.

У вас уже есть правильный ответ, поэтому это замечание является дополнительным.

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

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

Если вы дадите своей единственной истинной таблице поиска другой столбец, назовите ее «CodeType» и используйте «CodeType» и «Code» в качестве составного PK, то вы усложните больше, чем вносите, имея отдельную таблицу поиска для каждого кода. тип.

Короткий ответ таков: не помещайте значения из разных доменов в один столбец. Это всегда доставляет больше хлопот, чем спасает.

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

Проблема заключается в создании центральной таблицы, в которой смешано много разных кодов. Вы либо а) должны включить дополнительные столбцы, чтобы гарантировать, что заказы ссылаются только на статусы заказов в этой таблице, или б) в итоге вы получите задание, которое отправляется, а заказ - «безнадежно и готов к вывозу»

Изменить

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

«Вы вынуждены представлять каждый тип данных как строку с этим типом общей таблицы поиска».

Если я хочу {{ 1}} представляют другой тип данных, я могу добавить столбец для него в свою таблицу поиска.

Но с одной центральной таблицей для всех поисков теперь вы добавляете столбец, который должен заполняться только для одной конкретной операции поиска. Но собираетесь ли вы добавить ограничения CHECK, обеспечивающие это (фактически создавая NULL, но НЕ NULL, если ограничение Category = 'X' для столбца). Это может превратиться в кошмар обслуживания.

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

Кроме того, вы нарушили целостность данных из-за отношений PK / FK. Если у вас есть отдельные таблицы, FK означает, что вы не можете вводить значения, не входящие в справочную таблицу. Если вы используете одну большую таблицу, вы можете вводить значения, не соответствующие ситуации. Я помню одну базу данных, в которой я работал, где значение person_type было «Да» для некоторых записей.