Целесообразность псевдосправочников в БД

← →
msguns © (2005-11-02 12:24) [0]

Уважаемые Мастера !
Очень интересно ваше мнение вот по какому поводу:

Часто при проектировании БД приходится сталкиваться с объектами, которые вроде надо бы определить как справочные, но из-за их достаточно большого количества и малого диапазона значений не хочется оформлять отдельными таблицами.
Например:
Есть картотека служебной библиотеки, каждое издание или подшивка которой имеет такие реквизиты, как
- наличие ("В наличии", "В ремонте", "В розыске", "На руках")
- тип издания ("Книга", "Журнал", "Газета", "Карта", "Подшивка")
- место хранения (не более десятка адресов)
- состояние ("новая", "б/у", "ветхая")
...
Есть решение, когда в самой записи картотеки для каждого из подобных реквизитов отводится стринг небольшой длины собственно для хранения нативного текста.
При редактировании картотеки приложение дает запрос к картотеке для извлечения уникальных значений соотв-го поля таблицы и полученные тексты складывает в комбобокс для выбора. Если юзер ввел новое значение в комбобокс, то при следующей выборке оно "автоматом" попадает в подобный "псевдосправочник". Т.е. создается иллюзия справочника, в то время как реально он не существует. При этом отпадает необходимость контроля целостности, ввода в БД дополнительных таблиц и т.д.
Все это лихо работает, НО..
Не будет ли это тормозом при достаточно больших объемах (сотни тысяч записей) картотеки ?
Да и вообще, насколько это "грамотно" с т.з. профессионального разработчика БД ?

Спасибо всем участникам

← →
Desdechado © (2005-11-02 12:37) [1]

Лично я считаю, то если что-то можно формализовать, то лучше это сделать.
Т.е. справочники лучше заводить. Пусть он будет маленький, но "проблема контроля целостности" - надуманная, ибо без него еще хуже.

Единственная причина, когда я иногда не использую справочники: каждый элемент "справочника" однозначно определяет свой собственный, оригинальный способ обработки записей в зависимых таблицах. Тогда просто ставлю CHECK CONSTRAINT на поле. В этом случае справочник как бы зашивается в код программ.

← →
Sergey13 © (2005-11-02 12:40) [2]

ИМХО.
1.При таком подходе важен объем этого "справочника". Если там 2-5 значений, то вероятность, что юзер не увидит нужного мала. Если там около сотни, то вероятность резко возрастает. Типа есть уже "Конфета Марс", а узер вдолбит "Марс, просто Марс".
2.Запрос на дистинкт при индексе на 5 значений в миллионной таблице может вызывать постоянный фулскан. Т.е. плохая избирательность индекса ставит по вопрос целесообразность его применения оптимизатором. Это не факт, но вроде возможно в некоторых случаях.
3. Я бы (возможно) пошел по соседнему пути. 8-) Т.е. сделал "суперсправочник" для таких малых справочников. Т.е. один справочник с дополнительным полем "Тип значения" или вроде того. И вот его сделал бы так как предлагаешь ты.

← →
Johnmen © (2005-11-02 12:40) [3]

Классическая идеологически верная схема построения понятно какая :) Надо делать реальные справочники.
Но иногда, по самым разным (реальным!) основаниям, вполне оправданно отходить от идеологии.
У меня есть подобное описанной схеме. Но там у меня было ОСНОВАНИЕ отойти от принципа - количество и содержимое таких "текстов" заведомо неизвестно и постоянно меняется (не пользователем), а это приводит к громоздкой, медленной, замысловатой обработке в классической схеме.

А несколько сотен тыс.записей - это не очень много. Но ес-но надо проверять в реале, как там будет скорость...

← →
msguns © (2005-11-02 12:47) [4]

>Desdechado © (02.11.05 12:37) [1]
>Лично я считаю, то если что-то можно формализовать, то лучше это сделать.

Есть один, но весьма неприятный минус "псевдосправочников": - невозможность "одним махом" исправить ошибку или просто заменить значение "справочника" - надо лопатить все строки, содержащие "ошибку".
Однако я все же склоняюсь к тому, что вводит данные не обезьяна, а человек разумный. Который свои ошибки быстро заметит и своевременно исправит. Т.е. пополнение такого "справочника" будет на 99% выполнено еще на начальной стадии "забивки" данных, когда записей в "справочнике" будет немного и исправление ошибки не будет излишне затруднительным.

← →
msguns © (2005-11-02 12:52) [5]

>Sergey13 © (02.11.05 12:40) [2]
>1.При таком подходе важен объем этого "справочника". Если там 2-5 значений,..

Я акцентировал в сабже, что значений в таких "справочниках" изначально известно, что мало. Ну максимум десятки. Кроме того, что нет "сопутствующих" атрибутов, что свойственно "классическим" справочникам.

>Т.е. сделал "суперсправочник" для таких малых справочников. Т.е. один справочник с дополнительным полем "Тип значения" или вроде того

Не понял. Поясни на примере.

← →
Курдль © (2005-11-02 12:53) [6]

> msguns © (02.11.05 12:24)

Не знаю, у меня видимо есть какая-то тяга к "глобализации", но я бы все делал "по правилам РБД".
Взял бы таблицу "Документы", от нее отнаследовал "mutually exclusive" таблицы книг, журналов, газет, подшивок и т.п. (а вдруг понадобится по-разному работать с каждой из них, иметь разный набор полей и т.п.)
Наличие и состояние можно отразить простыми полями в таблице "Документы", а вот место хранения точно бы оформил таблицей.

← →
Jeer © (2005-11-02 13:04) [7]

msguns © (02.11.05 12:52) [5]

Одна таблица для реквизитов.
Вторая таблица для значений по ссылке на реквизиты.

Есть статья по поводу ведения единого справочника в псевдо-ОО РСУБД на ibase.ru

← →
Sergey13 © (2005-11-02 13:09) [8]

2[5] msguns © (02.11.05 12:52)
>Ну максимум десятки.
Мало? В видимую часть комбобокса не влезает - уже потенциальная проблема. ИМХО конечно.

>Не понял. Поясни на примере.
Код Тип Значение 1 Ед.Изм. метр 2 Ед.Изм. грамм 3 Степень износа Новое 4 Степень износа Б/У

← →
evvcom © (2005-11-02 13:51) [9]

> Однако я все же склоняюсь к тому, что вводит данные не обезьяна,
> а человек разумный. Который свои ошибки быстро заметит
> и своевременно исправит.

Если речь идет об обычном пользователе, то я не был бы так оптимистичен. Чаще всего пользователю по барабану, что набито в справочнике "Конфета Марс" или "Марс, просто Марс". Но когда речь зайдет о подсчете таких якобы одинаковых предметов, они тебе всю плешь проедят, что ты неправильно программу написал. В данном случае я за нормализацию и использование реальных справочников, а также на справочник должен быть "посажен" ответственный человек (если такое возможно).

← →
Sergey Masloff (2005-11-02 13:59) [10]

Сделай 1 (одну) справочную таблицу и забудь о проблемах.
Можно "деревянную" (я бы так и сделал) или 2 уровневую (типы->значения)
Подумай про дерево - это легко и вопреки расхожему мнению очень удобно и эффективно.

← →
Schooler (2005-11-02 14:48) [11]

> Однако я все же склоняюсь к тому, что вводит данные не обезьяна...

А вот это Ты зря...

Слушай evvcom © (02.11.05 13:51) [9] !!!

← →
msguns © (2005-11-02 18:36) [12]

>Sergey13 © (02.11.05 13:09) [8]

Долго волосы разглаживал, ибо дыбом встали ;)

>evvcom © (02.11.05 13:51) [9]
>Если речь идет об обычном пользователе, то я не был бы так оптимистичен

Я, возможно, неубедительно объяснил.
Речь идет не о справочниках каких-то названий (вы меня все каким-то "Марсом" пугаете), а о нескольких жестко заданных (если и меняемых, то крайне редко) вариантах значений какого-то атрибута.
Согласитесь, делать "дерево" для двух-трех десятков значений (в сумме) подобных атрибутов не совсем разумно.

Спасибо.

Есть еще мнения ?

← →
Sergey Masloff (2005-11-02 18:43) [13]

msguns © (02.11.05 18:36) [12]
>Согласитесь, делать "дерево" для двух-трех десятков значений (в сумме) >подобных атрибутов не совсем разумно.
Пачиму? ;-) Не согласимся (я). Какая фиг разница одна таблица. Полем больше вот тебе и дерево. Что смущает-то - вот что непонятно.

← →
Anatoly Podgoretsky © (2005-11-02 21:15) [14]

База должна отражать сущность. Разные сущности разные таблицы, количество бояться не стоит. Стоит бояться бардака.

← →
Baltika-37 (2005-11-02 21:25) [15]

Как написал Sergey13 © (02.11.05 12:40) [2],
Прекрасное решения даже для миллионов записей:

Самый простой вариант:

ID int, ClassId Int, ObjId Int ObjName varchar(200), ObjValue varchar(250)

Выборка в проидексированной странице по паре (ClassId, ObjId) либо (ClassId, ObjName) будет практически мгновенной.

← →
Sergey Masloff (2005-11-02 21:27) [16]

Anatoly Podgoretsky © (02.11.05 21:15) [14]
>Разные сущности разные таблицы,
>количество бояться не стоит. Стоит бояться бардака.
Так сущность одна - классификатор. У уж ящики/упаковки юр/физлица это все равно, вобщем-то. И хранение всего в одном дереве бардак не увеличит.

← →
evvcom © (2005-11-02 22:43) [17]

> а о нескольких жестко заданных (если и меняемых, то крайне
> редко) вариантах значений какого-то атрибута

Кому будет разрешено менять эти значения? Если безответственному пользователю, то очень скоро увидишь, что твое "крайне редко" почему-то быстренько очень превратилось в "крайне нередко". Поверь, я был свидетелем подобного, причем на этом деле сидел, как предполагалось, "ответственный" пользователь.

← →
roottim © (2005-11-03 09:09) [18]

Вариант+
create table app_bonus (ParamName varchar2(100), Value varchar2(1000)); insert into app_bonus( "издание:наличие", "В наличии;В ремонте;В розыске;На руках" ); insert into app_bonus( "издание:тип издания", "Книга;Журнал;Газета;Карта;Подшивка" );

Пишеш функции бд:
GetAppBonus(p_pname varchar2) return varchar2; SetAppBonus(p_pname varchar2, p_value varchar2);
Заполняеш свой комбобох cbox.ComaText := DelphiGetAppBonus(.., ..);
При вводе нового значения обновляеш параметры таблицы

← →
Курдль © (2005-11-03 11:38) [19]

> Sergey Masloff (02.11.05 13:59) [10]
> Подумай про дерево - это легко и вопреки расхожему мнению
> очень удобно и эффективно.

Когда преподаватель из центра оракла нарисовал на доске одну таблицу со связью "один-ко-многим" на саму себя, все заинтригованно переглядывались.
Но когда он подписал ее "ВЕСЬ МИР" - все разродились ржанием! Ведь как изящно и в то же время - как бессмысленно это выглядело! :)

← →
Sergey_Masloff (2005-11-03 11:43) [20]

Курдль © (03.11.05 11:38) [19]
>Но когда он подписал ее "ВЕСЬ МИР" - все разродились ржанием! Ведь как >изящно и в то же время - как бессмысленно это выглядело! :)
Это у них домашняя заготовка. Я слышал это же в том же контексте около 10 лет назад. Именно в аналогичной ситуации.

> Это у них домашняя заготовка. Я слышал это же в том же контексте
> около 10 лет назад. Именно в аналогичной ситуации.

Так и я это тогда же слышал! Но пробирает ведь! И гармонично переплетеатся с призывом Э.Кодда не лепить себе никаких догм, связанных с реляционными принципами, а руководствоваться лишь здравым смыслом и удобством работы.

2[12] msguns © (02.11.05 18:36)
>Долго волосы разглаживал, ибо дыбом встали ;)
Что тебя так напугало? Это же практически твоя идея. 8-)

> msguns © (02.11.05 18:36) [12]
</I
> Речь идет не о справочниках каких-то названий (вы меня все
> каким-то "Марсом" пугаете), а о нескольких жестко заданных
> (если и меняемых, то крайне редко) вариантах значений какого-
> то атрибута.

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

А по теме, как вариант.
4 таблицы.
1. Справочник реквизитов
2. Детализация реквизитов со ссылкой на реквизит.
3. Таблица собственно объектов учета.
4. Детализация по объектам. А вот здесь уже "отводится стринг небольшой длины собственно для хранения нативного текста" с возможностью выбора из
таблицы 2 либо особой пометки.

Такая модель ИМХО представляется более гибкой.

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

>Курдль © (03.11.05 11:49) [21]
>..призывом Э.Кодда не лепить себе никаких догм, связанных с реляционными принципами, а руководствоваться лишь здравым смыслом и удобством работы.

Вай, какой хороший и красивый лозунг ! Я тоже так хачу ;))

>Sergey13 © (03.11.05 12:00) [22]
>Что тебя так напугало? Это же практически твоя идея. 8-)

Идея посадить яблоню и подождать 5 лет, пока оно начнет плодоносить, вместо того, чтобы просто скушать яблоко, купленное на рынке - это моя идея ???!!!
Блин, где моя расческа ?

>TohaNik © (03.11.05 12:34) [23]

То, что Вы написали про 4 таблицы - это уже чуть ли не объектная БД. Ну нафига тут она. Надо всего-навсего картотека изданий. Для узкой специфики. Вовсе не на тираж и вообще не на продажу ;) У меня вся база состиоит из одной (!) таблицы и 5 справочников. Где тут огород городить ?

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

Абсолютно правильно понимаете. А вот на счет "приведет.. к избыточности.. и бардаку, позвольте Вам не позволить. В смысле не согласная я ;))
Ну ведь не надо в самом деле равнять сложные многопользовательские и многофункциональные модели сравнивать с "телефонным справочником".

2[24] msguns © (03.11.05 13:28)
>Блин, где моя расческа ?
Не понимаю я твоих страхов. Сам рассказал страшилку, и сам же испугался. 8-)
При показе таблицы просто соединяешь ее со справочником. При внесении новой записи, определяешь какого типа подставлен параметр и выбираешь из справочника все значения этого типа. Помоему нормально. Творческое развитие твоей идеи. 8-)
Единственное, нужно (желательно) отдельную форму для справочника, который и будет работать точно по твоему алгоритму.

> msguns © (03.11.05 13:28) [24]

Не Выкай...-те;)

> У меня вся база состиоит из одной (!) таблицы и 5 справочников.
> Где тут огород городить ?

А в прелагаемом в [23] из 2-х справочников и 2-х таблиц с общим меньшим количеством полей.

А вот представь, через полгода захотят, ну вдруг, ввести реквизит кто выдал
книгу. Ну ты начинаешь воду варить - типа жестко задано все, а потом симпатишной библиотекарше говоришь:
- ну только для Вас и только ради Вас ;)
Добавляешь в первую таблицу "Выдал", во вторую ФИО выдающих и пьешь...
чай с тортиком;)

>TohaNik © (03.11.05 14:06) [26]
>Не Выкай...-те;)

заметано ;)

>потом симпатишной библиотекарше говоришь

Да не симпатишная она. Совсем. Увы..

> Да не симпатишная она. Совсем. Увы..

:( А мы стараемся.

Целесообразность псевдосправочников в БД Найти похожие ветки