При проектировании любой базы данных всегда возникает необходимость хранить море справочной информации. Всевозможные классификаторы списки товаров, людей
К справочникам я отношу всю ту информацию, которая необходима исключительно для красивого вывода пользователю. И как вариант от нее будет нужно брать пару циферок. Какой-нибудь (вес коробки). Внутри приложения все равно будут всевозможные ID и константы. При проектировании от них можно абстрагироваться и считать что они просто есть и будут показываться как надо.
Одно из решений, к которому все приходят рано или поздно это вообще не создавать никакой структуры под справочники, а хранить все в некой универсальной структуре. Которая с виду отлично ложится на классы в приложении.
EAV модель
В интернете про нее написано много чего. Но основная идея, подверженная на практике использовать ее только в том случае когда необходимы сущности задаваемые пользователем. Это настолько редкий класс проектов, что о них даже не стоит говорить.
В любом другом случае мы получаем неудобочитаемую, медленно работающую структуру. Без каких-либо плюсов.
Классические справочники
• Нерасширяемые справочники
Пример: Пол человека.
Плюсы выделения этого класса в том что мы сразу, на этапе проектирования, определяем сколько и каких значений в них будет лежать.
Благодаря этому мы можем соответсвенно проектировать интерфейс пользователя, писать CASE по всем возможным вариантам, итд. С ограниченным числом значений в справочнике работать всегда проще чем с неограниченным.
Например:
Если сделать справочник расширяемым, такая конструкция не заработает. Надо делать дополнительные таблицы, писать дополнительные запросы.
Нерасширяемые справочники проще всего делать просто константами в соответствующих полях объектов. Не нужно никаких таблиц, ключей, ничего. Для контроля целостности накладываем на это поле ограничение с перечислением всех возможных вариантов.
• Расширяемые справочники
Пример: Страна проживания
Плюсы выдления этого класса в том что мы не будем требовать задавания уникального кода для каждого нового значения. Нам такие коды вообще будут не нужны.
Есть большой соблазн сделать таблицу со списком всех стран. И реализовать выбор из списка. В лучшем случае с поиском по первой букве. Но на практике оказывается что 95% людей будут из России. А остальные 5% из десяти других стран. И весь этот список из сотни наименований полностью никогда не будет использоваться.
Куда лучше сделать обычное текстовое поле для ввода, и показывать список отфильтрованный по первым буквам. Эстеты могут добывить кнопочку показывающую весь список сразу. Сам список генерить по всем ранее введенным значениям.
Расширяемые справочники лучше всего делать просто текстовыми аттрибутами. Контроль дубликатов будет осуществляться благодаря выпадающему списку подходящих вариантов. Ну и совсем хорошо добавить администратору возможность заводить синонимы РФ = Россия для автозамены.
Как и с нераширяемыми справочниками, не надо делать отдельных таблиц, ключей. Не надо проверять целостность, и думать о том как хранить изменения. Они выраждаются до обычных аттрибутов объетов.
• Справочники достойные отдельных таблиц
Пример: Товары
К этому типу относятся все справочники имеющие собственные аттрибуты или ссылающиеся на что-либо. Делаем для них отдельные таблицы.
Их надо проектировать, думать. Общего подхода тут нет.
Коды
Иногда возникает необходимость хранить много связей Код-Имя. Под такие связи лучше всего выделить отдельную таблицу. И во всех остальных таблицах хранить только коды. Этот подход полностью совместимо с этой системой хранения справчников. К примеру для нераширяемого справочника Пол можно довавить коды (“М”, “Ж”, “Н”) и соответвующие им имена (“мужской”, “женский”, “НЛО”)
UPD: Критика выслушана. Статья обновлена.
К справочникам я отношу всю ту информацию, которая необходима исключительно для красивого вывода пользователю. И как вариант от нее будет нужно брать пару циферок. Какой-нибудь (вес коробки). Внутри приложения все равно будут всевозможные ID и константы. При проектировании от них можно абстрагироваться и считать что они просто есть и будут показываться как надо.
Одно из решений, к которому все приходят рано или поздно это вообще не создавать никакой структуры под справочники, а хранить все в некой универсальной структуре. Которая с виду отлично ложится на классы в приложении.
EAV модель
В интернете про нее написано много чего. Но основная идея, подверженная на практике использовать ее только в том случае когда необходимы сущности задаваемые пользователем. Это настолько редкий класс проектов, что о них даже не стоит говорить.
В любом другом случае мы получаем неудобочитаемую, медленно работающую структуру. Без каких-либо плюсов.
Классические справочники
• Нерасширяемые справочники
Пример: Пол человека.
Плюсы выделения этого класса в том что мы сразу, на этапе проектирования, определяем сколько и каких значений в них будет лежать.
Благодаря этому мы можем соответсвенно проектировать интерфейс пользователя, писать CASE по всем возможным вариантам, итд. С ограниченным числом значений в справочнике работать всегда проще чем с неограниченным.
Например:
CASE
WHEN sex = ‘М’ then caption = ‘Он’
WHEN sex = ‘Ж’ then caption = ‘Она’
WHEN sex = ‘Н’ then caption = ‘НЛО’
END
Если сделать справочник расширяемым, такая конструкция не заработает. Надо делать дополнительные таблицы, писать дополнительные запросы.
Нерасширяемые справочники проще всего делать просто константами в соответствующих полях объектов. Не нужно никаких таблиц, ключей, ничего. Для контроля целостности накладываем на это поле ограничение с перечислением всех возможных вариантов.
• Расширяемые справочники
Пример: Страна проживания
Плюсы выдления этого класса в том что мы не будем требовать задавания уникального кода для каждого нового значения. Нам такие коды вообще будут не нужны.
Есть большой соблазн сделать таблицу со списком всех стран. И реализовать выбор из списка. В лучшем случае с поиском по первой букве. Но на практике оказывается что 95% людей будут из России. А остальные 5% из десяти других стран. И весь этот список из сотни наименований полностью никогда не будет использоваться.
Куда лучше сделать обычное текстовое поле для ввода, и показывать список отфильтрованный по первым буквам. Эстеты могут добывить кнопочку показывающую весь список сразу. Сам список генерить по всем ранее введенным значениям.
Расширяемые справочники лучше всего делать просто текстовыми аттрибутами. Контроль дубликатов будет осуществляться благодаря выпадающему списку подходящих вариантов. Ну и совсем хорошо добавить администратору возможность заводить синонимы РФ = Россия для автозамены.
Как и с нераширяемыми справочниками, не надо делать отдельных таблиц, ключей. Не надо проверять целостность, и думать о том как хранить изменения. Они выраждаются до обычных аттрибутов объетов.
• Справочники достойные отдельных таблиц
Пример: Товары
К этому типу относятся все справочники имеющие собственные аттрибуты или ссылающиеся на что-либо. Делаем для них отдельные таблицы.
Их надо проектировать, думать. Общего подхода тут нет.
Коды
Иногда возникает необходимость хранить много связей Код-Имя. Под такие связи лучше всего выделить отдельную таблицу. И во всех остальных таблицах хранить только коды. Этот подход полностью совместимо с этой системой хранения справчников. К примеру для нераширяемого справочника Пол можно довавить коды (“М”, “Ж”, “Н”) и соответвующие им имена (“мужской”, “женский”, “НЛО”)
UPD: Критика выслушана. Статья обновлена.
