Комментарии 11
Статья както… незавершенной выглядит. Поподробней бы.
Как, по мне, то в 85% случаев самое удачное решение,
+ это лист с сушностям (ent_id, ent_value)
+ любое кол-во классифицирующих деревьев (типа id, link, parent_id)
+ справочник возможных свойств (prop_id, prop_type)
+ спаравочьник значений свойств для нужных сущьностей (ent_id, prop_id, prop_value)
Самое по-моему мегауниверсальное решение.
+ это лист с сушностям (ent_id, ent_value)
+ любое кол-во классифицирующих деревьев (типа id, link, parent_id)
+ справочник возможных свойств (prop_id, prop_type)
+ спаравочьник значений свойств для нужных сущьностей (ent_id, prop_id, prop_value)
Самое по-моему мегауниверсальное решение.
справочник
спаравочьник
Не можете выбрать? :)
Вообще, насколько помню курс БД в универе, понятие «справочник» подразумевает как раз хранение связей «Код-Имя». Т.е. справочник предполагает некую избыточность (ведь Имя в пределах справочника уникально), однако необходим для избегания возможного дублирования информации, если юзер будет не выбирать Код/Имя, а вводить Имя вручную. Кстати, чем в таком случае расширяемый справочник (на примере стран) отличается от прочих справочников, я не понял.
Ну и напоследок, то, что сущности типа «товар» достойны отдельных таблиц (причем именно как справочников), это сильно. Вообще-то обычно товар это главная сущность, вокруг которой строится остальная часть БД, и выделяется он в отдельное отношение при нормализации БД…
Ну и напоследок, то, что сущности типа «товар» достойны отдельных таблиц (причем именно как справочников), это сильно. Вообще-то обычно товар это главная сущность, вокруг которой строится остальная часть БД, и выделяется он в отдельное отношение при нормализации БД…
Я к справочникам отнес вообще все кроме основных сущностей. В начале проектирования о них обычно можно не задумываться и навешивать на схему позже. Ну и описал эту самую систему «навешивания»
Расширяемый отличается тем что можно добавлять в него значения. Но при этом не заводим отдельную таблицу.
От дубликатов избавляемся на уровне интерфейса с выпадающим списком вариантов. Требовать от пользователя вводить каждый раз уникальный код жестко слишком.
Про <товар> это зависит от того чего проектируем. В какой-нибудь логистической системе это не что иное как справочник.
Расширяемый отличается тем что можно добавлять в него значения. Но при этом не заводим отдельную таблицу.
От дубликатов избавляемся на уровне интерфейса с выпадающим списком вариантов. Требовать от пользователя вводить каждый раз уникальный код жестко слишком.
Про <товар> это зависит от того чего проектируем. В какой-нибудь логистической системе это не что иное как справочник.
Так так и надо было написать в статье. А то прочитает какой-нибудь начинающий разработчик такое, полениться посмотреть комментарии и будет с пеной изо рта доказывать, что он прав.
По поводу справочника стран я с вами не согласен. Заходит к вам пользователь из Папуа — Новая Гвинея, пытается выбрать страну. А её там нету. Представьте, какое он испытывает негодование, что его страну не включили в этот список. Чем он хуже. Это история надуманная, но вполне реальная. Ваш вариант, который Вы предложили, обладает избыточностью данных. А она нужно ну только в очень критических к производительности ситуациях. Выбор города, мне кажется не так критичен :)
По поводу справочника стран я с вами не согласен. Заходит к вам пользователь из Папуа — Новая Гвинея, пытается выбрать страну. А её там нету. Представьте, какое он испытывает негодование, что его страну не включили в этот список. Чем он хуже. Это история надуманная, но вполне реальная. Ваш вариант, который Вы предложили, обладает избыточностью данных. А она нужно ну только в очень критических к производительности ситуациях. Выбор города, мне кажется не так критичен :)
Тогда давайте говорить про нормализацию таблиц :)
Если какой-то набор полей, обозначающих некую сущность, повторяется более одного раза, имеет смысл его вынести в отдельное отношение. И справочники тут ни при чем. Они как раз призваны заменить неудобоваримый для пользователя Код объекта неким Именем. Поэтому по барабану, заносим ли мы в справочник города или цвета радуги.
По поводу расширяемости — имеет ли вообще смысл зарекаться называть справочник нерасширяемым? Принципиально ничего в реализации не поменяется, что будет возможность добавить еще строчку, что нет. В конце концов, помимо «м» и «ж» может быть «не скажу» и любимое многими «я — НЛО».
ЗЫ. Определитесь, чем по Вашему отличаются справочники от таблиц, если некоторые справочники достойны выделения в отдельные таблицы, а другие — нет :)
Если какой-то набор полей, обозначающих некую сущность, повторяется более одного раза, имеет смысл его вынести в отдельное отношение. И справочники тут ни при чем. Они как раз призваны заменить неудобоваримый для пользователя Код объекта неким Именем. Поэтому по барабану, заносим ли мы в справочник города или цвета радуги.
По поводу расширяемости — имеет ли вообще смысл зарекаться называть справочник нерасширяемым? Принципиально ничего в реализации не поменяется, что будет возможность добавить еще строчку, что нет. В конце концов, помимо «м» и «ж» может быть «не скажу» и любимое многими «я — НЛО».
ЗЫ. Определитесь, чем по Вашему отличаются справочники от таблиц, если некоторые справочники достойны выделения в отдельные таблицы, а другие — нет :)
Если нормализовать все, то мы получим огромный набор таблиц типа
Таблица Имя
Таблица Фамилия
Таблица Отчество
Ведь и имена и фамилии и отчества часто повторяются. Нормализовать всегда имеет смысл до определенной грани.
Ситуация «Не скажу» не всегда возможна. К примеру записываясь к врачу так ответить точно нельзя. Если мы такое допускаем, то надо сразу это предусматривать. А объявив справочник нерасширяемым мы сильно упрощаем и дизайн БД и работу с ним.
Справочник понятие логическое, а таблица физическое. Теплое и мягкое.
Таблица Имя
Таблица Фамилия
Таблица Отчество
Ведь и имена и фамилии и отчества часто повторяются. Нормализовать всегда имеет смысл до определенной грани.
Ситуация «Не скажу» не всегда возможна. К примеру записываясь к врачу так ответить точно нельзя. Если мы такое допускаем, то надо сразу это предусматривать. А объявив справочник нерасширяемым мы сильно упрощаем и дизайн БД и работу с ним.
Справочник понятие логическое, а таблица физическое. Теплое и мягкое.
1. Конечно, грань надо чувствовать :) Только вот судя по Вашему примеру с городами, придется сделать в таблице с ФИО несколько наиболее употребляемых сочетаний (aka «Иванов Иван Иваныч»).
2. Объясните мне, неразумному, как Вы упростите дизайн+работу, если справочник нерасширяемый? Разве селекты (что SQL-ские, что HTML-ские) от этого поменяются? :)
В общем-то главный вопрос вот в чем — какое отличие у упомянутых Вами в статье типов справочников? Именно в плане структуры, использования и т.д. Почему одно надо относить к расширяемым, а другое — к Код-Имя?
2. Объясните мне, неразумному, как Вы упростите дизайн+работу, если справочник нерасширяемый? Разве селекты (что SQL-ские, что HTML-ские) от этого поменяются? :)
В общем-то главный вопрос вот в чем — какое отличие у упомянутых Вами в статье типов справочников? Именно в плане структуры, использования и т.д. Почему одно надо относить к расширяемым, а другое — к Код-Имя?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Классификация типов справочников в базах данных