Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

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

Страницы: < 1 2
msguns © (2005-11-02 12:24:00)
Уважаемые Мастера !
Очень интересно ваше мнение вот по какому поводу:

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

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

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

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

Jeer (2005-11-02 13:04:00) [22]
msguns © (02.11.05 12:52) [5]

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

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

Курдль (2005-11-02 12:53:00) [23]

> msguns © (02.11.05 12:24)

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

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

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

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

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

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

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

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

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

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

Desdechado (2005-11-02 12:37:00) [28]
Лично я считаю, то если что-то можно формализовать, то лучше это сделать.
Т.е. справочники лучше заводить. Пусть он будет маленький, но "проблема контроля целостности" - надуманная, ибо без него еще хуже.

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

Страницы: < 1 2

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »