Док, слушай сюда.

У любой штуки есть и про и контра. Нет абсолютного зла и абсолютного добра. И эти про и контра надо иметь в виду применительно к своей конкретной задаче и принимать осмысленное решение. Так вот, касательно FK на короткие справочники, вопрос про иннеры с аутерами поднимем чуть позже, пока считаем, что живём с иннерами.

С точки зрения целостности FK - это триггер, видящий за счёт использования индекса больше, чем твой триггер, работающий в контексте уровня изоляции твоей транзакции. Поэтому он и не даст тебе сослаться на удалённую в справочнике запись или запись, ID которой был изменён, независимо от того, когда это произошло - до старта твоей транзакции или после и закоммичено оно или нет. Аналогично такой же триггер на справочнике не даст удалить позицию или изменить её ID если есть даже незакоммиченные ссылки в содержательных таблицах. Отсюда следует, что если удаления или изменения ID в справочнике не предусмотрены бизнес-логикой, то в этом и только в этом случае FK не особо и нужен, его вполне можно заменить твоими триггерами на содержательной таблице.

Что при этом про. На содержательной таблице из 100500 записей нет херового индекса с 5 значениями. Вред от него двоякий. Не, даже троякий. Во-первых, по мере роста таблицы его херовость в смысле затрат на перестройку при вставках-удалениях-модифицированиях (последнее - например, изменение статуса записи, стадии существования от необслуженной совсем через инстанции рассмотрения к завершению обслуживания). Но это так, тормозишки, на твоих объёмах ты их скорей всего и не заметишь. Настоящие тормоза ты заметишь на ресторе, при построении этого индекса целиком, это во-вторых. В-третьих, если в селективном запросе на эту ссылку наложено условие, оптимизатор может этот индекс и подцепить, независимо от иннер или аутер. Просто при иннере он его может подцепить и при наложении условия на поле в справочнике и построить перебор от справочника. Вот это в-третьих имеет свои про и контра. Если распределение значений в этом поле более-менее равномерное, ты получишь серьёзные тормоза. Если же, как в случае статуса, через годик работы в таблице из 100500 записей 100000 закрытых и 500 в работе, то запрос, отбирающий эти 500 на этот индекс не нарадуется, что есть про. А вот наоборот - заплачешь горючими слезами. Контра в том, что надо об этом помнить и гасить в этом случае ноликами.

За иннеры-аутеры. При современном развитии печатного дела на Западе вероятность использования оптимизатором в таких простых случаях херового индекса имхо невелика. На полуторке - да, в полный рост. Должен отметить, что в моей практике, тоиссь, на примерно миллионе сконструированных запросов, раз 5 был случай, когда оптимизатор действительно сложный запрос на иннерах выворачивал даже не через жопу, а через три, причём слоновьих, так что у меня просто глаза на лоб лезли, и при этом результат получался в разы лучше чем у меня при всём моём глубокомудрии в составлении явных планов Но обычно всё-таки наоборот. Напоминаю - речь о полуторке. При запросе-ёлке, тоиссь, соединениях со справочниками одной ведущей таблицы, в общем, похрен, что иннер, что аутер. В случае чего иннер направить легко можно ноликами. А вот если этот запрос впоследствии берётся как основа или компонент действительно сложного с аутерами в смысловой части, то наступить на грабли просто нефиг делать.

За композиты. Это мощное оружие, которое может быть как созидательным, так и разрушительным. Если все его сегменты по отдельности херовые, то к нему относится всё, что относится к херовому односегментному индексу. И построение долгоиграющее, и обслуживание нагрузочное, и оптимизатор не особо склонен его подхватывать и результат использования сильно зависит от распределения значений в сегментах, плюс условия на ведущие сегменты должны быть на равенство. Короче, смысл в нём фактически может быть для одного конкретного запроса. И не дай бог его оптимизатор подхватит для другого. Поэтому их обычно усиливают высокоселективным, а то и уникальным сегментом. Если этот сегмент ведущий, то всё чики-пуки, но тогда выгода от него проценты - меньше и быстрее загружаются страницы чем при использовании раздельных индексов на те же сегменты в нужном порядке. А если его прилепляют на жопу для обмана оптимизатора, то опять упираемся в экстремальную выгоду за счёт распределения значений в первом сегменте для запросов, отбирающих антипик распределения и дикие тормоза для остальных, тоиссь memento +0, а то оптимизатор будет его тыкать куда ни пОпадя.

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

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

Ма-ма, ма-ма, что мы будем делать... ыыы...
Ма-ма, ма-ма, как мы будем жить... кууу...

Так тут же речь об индексированном - статус есть ссылка на справочник.