Если у вас есть небольшие выделенные таблицы, то база данных может легко кэшировать те, которые ей нужны, в памяти.
Если вы возьмете то, что в противном случае было бы маленькими таблицами, и объедините их в одну, база данных не будетзнать, какие записи важны для кэширования, а какие нет.
Что еще более важно, появляется больше возможностей для ошибок, потому что вы можете случайно ввести неправильный код типа и в конечном итоге присоединиться к чему-то не относящемуся к делу без RI или проверки типов, чтобы предупредить вас. Если вы используете небольшие выделенные таблицы, то вы можете указать ограничения RI.
Вспоминая место, где я видел единый шаблон таблицы поиска монстров, я думаю, что привлекательность заключалась в том, что разработчики могут добавлять больше видов записейбез необходимости вмешательства DBA для создания большего количества таблиц. Было много разработчиков и только несколько администраторов баз данных, и именно так администраторы баз данных избегали необходимости создавать выделенные таблицы поиска каждый раз, когда вводился новый тип записи поиска. (Очевидно, что предоставление прав на создание таблиц в dev было неприемлемо для администраторов баз данных.)
Это похоже на обходной путь для сред, в которых изменения схемы базы данных трудно найти. Но другое соображение заключается в том, что может быть проще интернационализировать, если все ваши записи находятся в одной таблице.
И шаблон имеет установленное имя, он называется One True Lookup Table . Связанная статья называет это антипаттерном и перечисляет больше недостатков этой техники. Вот маркированный список из статьи:
Это делает SQL выглядит уродливо.
Многие операторы требуют нескольких объединений длясправочная таблица. Дополнительные столбцы соединения делают операторы больше и страшнее. При использовании отдельных справочных таблиц будет одинаковое количество объединений, но эти объединения будут проще.
Несколько ссылок на одну и ту же таблицу могут затруднить определение того, что происходит вплан выполнения, как вы увидите эти повторяющиеся ссылки там, и вам нужно обратиться к предикатам, чтобы понять контекст ссылки на таблицу. Если бы вы использовали отдельные таблицы поиска, было бы ясно, к какой таблице вы обращались в любой точке плана выполнения.
Нельзя использовать внешний ключ для этого типа таблицы. Технически это можно сделать, если вы хотите поместить в таблицу оба столбца (lookup_type_code и lookup_key), но этого не произойдет, потому что это ужасно. Это означает, что есть большая вероятность того, что ваша целостность данных со временем будет нарушена. Очень легко получить внешний ключ к отдельным справочным таблицам и, следовательно, защитить ваши данные.
Контролировать содержимое таблицы сложно. Это общий ресурс, поэтому проверить ограничения и триггеры проблематично. Если вам нужно, чтобы у пользователей были разные привилегии, в зависимости от того, с каким поиском они имеют дело, все будет беспорядочно. Это было бы действительно легко с отдельными справочными таблицами.
Если вам нужно внести изменение для одного ссылочного типа, например, увеличить размер ключа или значения, это повлияет на все справочные данные. Использование отдельных справочных таблиц изолирует изменение.
Со временем многие справочные таблицы принимают дополнительные данные. Чтобы смоделировать это, вам нужно будет либо выделить эти справочные данные из этой общей справочной таблицы, либо начать добавлять дополнительные столбцы, чтобы справиться с «одноразовыми» проблемами. Такое изменение действительно просто для отдельных справочных таблиц.
Типы данных имеют значение. Вы должны всегда использовать правильный тип данных, так как это уменьшит количество необходимых преобразований типов данных. Неявные преобразования типов данных - это ошибки, ожидающие своего появления!
Производительность может быть проблемой с подходом OTLT, так как оптимизатору сложно составить здравое суждение о данных. Оптимизатор заботится о количестве элементов, но может быть трудно принять это решение, если вы имеете дело с большим количеством строк, большинство из которых не имеют отношения к какому-либо конкретному контексту. Оптимизатор также заботится о высоких / низких значениях, но они не относятся к какому-либо одному поиску, а являются общими. Мы также упомянули, что вы, вероятно, не будете использовать внешний ключ для этих данных, что сократит объем информации, которую имеет оптимизатор при принятии решения. Вы можете сделать искусственно сделанные столбцы необязательными, которые на самом деле являются обязательными, ключ должен иметь значение, но какой столбец? Я думаю, вы получите сообщение.