Проектирование баз данных - Несколько Таблиц Поиска/Перечисления или Одна Большая Таблица?

This topic has been discussed at length over the last fifteen years, under the subject "One True Lookup Table" (abbreviated OTLT). The advantages of such an approach leap out to the database newbie. The drawbacks emerge over time. See these links for OTLT drawbacks:

• http://tonyandrews.blogspot.com/2004/10/otlt-and-eav-two-big-design-mistakes.html
• http://web.archive.org/web/20100130062850/http://www.dbazine.com/ofinterest/oi-articles/celko22

Or search for OTLT to find more discussions.

If you create many lookup tables, and many maintenance screens for them, you can create a view that simulates the OTLT by creating a gigantic UNION that includes every code, every description, and the name of the table where the code-description pair is stored. Такой союз можно создать полуавтоматическими методами, если вы знаете, что делаете. Я мог бы предположить, что полуавтоматические методы позволили бы вам создать единый экран обслуживания для сотен таблиц поиска, а затем поместить некоторую логику между этим экраном и таблицами, которая вставит новый код в правильную таблицу.

Что касается разрешения пользователи вводят новые ТИПЫ кода, а не только новые ЗНАЧЕНИЯ кода, которые открывают целую банку червей. См. Статью выше, посвященную EAV. Это очень соблазнительно, потому что позволяет пользователям разрабатывать свою собственную структуру данных. Если не обращать внимания на производительность, какое-то время это работает неплохо. Вы получаете совершенно общую базу данных без необходимости изучать структуру данных у пользователей или экспертов в предметной области.

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

(Отредактировано, чтобы заменить «интеллектуальный анализ данных» на «археологию данных»)

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

Итак, что я узнал?

• для статических значений, просто используйте enum - это намного быстрее и удобнее. Это решение необходимо принимать в зависимости от того, сколько других таблиц могут ссылаться на одну и ту же переменную.
• придерживайтесь меньшего количества таблиц поиска, чем создавайте столько, сколько вы можете придумать. СОЕДИНЕНИЯ выполняются намного медленнее.
• чтобы помочь себе ориентироваться, проектируйте представления базы данных. Это сделает вашу жизнь намного проще.
• в качестве бонуса, если вы не хотите, чтобы ваши клиенты касались определенных таблиц (т.е. ваших статических) или касались значений столбцов перечисления, вы можете использовать MySQL (например) штраф расширенные разрешения для отключения изменений определенных столбцов в определенных таблицах. Многие люди не понимают, насколько гибкими могут быть эти разрешения.

Существует потенциальная разница в производительности.

Таблица всего с двумя строками занимает много места в кеше для этих двух крошечных строк.

Если у вас много значений поиска в одной таблице вы, по сути, более плотно упаковываете эти значения в кеш.