пришел на новое место работы и в текущем проекте столкнулся с неожиданным для меня приемом - большая часть справочников хранится в одной таблице. (всего таблиц, больше 100)
структура такая:
uid - уникальный суррогатный ключ
id_type - код справочника
id - код в справочнике
text - наименование
full_text - полное наименование
note - примечание
т.к. с таким приемом столкнулся впервые, то вопрос: какие преимущества и недостатки в таком методе?
Справочники в одной таблице
-
Dimitry Sibiryakov
- Заслуженный разработчик
- Сообщения: 1436
- Зарегистрирован: 15 сен 2005, 09:05
и ссылочная целостность только на триггерах?Dimitry Sibiryakov писал(а):При появлении нового справочника не приходится корежить структуру БД и приложение. Недостаток - чуть более сложные запросы если у элемента справочника еть доп.атрибуты.
что значит "самодокументируемость" и это как?WildSery писал(а):Возможна самодокументируемость справочника.
Можно написать запрос, возвращающий всю структуру справочников, для отчёта.
это почему? есть же uid. на него можно FK построить.и ссылочная целостность только на триггерах?
это значит что в справочник можно загнать описание конкретной "справочной" таблицы, и ее данные.что значит "самодокументируемость" и это как?
Посмотри например
http://www.ibase.ru/devinfo/oop_rdbms.htm
это практически то же самое.
Re: Справочники в одной таблице
Из преимуществ:Батор писал(а):какие преимущества и недостатки в таком методе?
* в простых случаях можно использовать один и тот же код на клиенте для просмотра любых справочников из этой таблицы задав условие по типу справочника.
* если бывает так что в какой-то таблице в одном и том же поле находятся ссылки на элементы разных справочников - то если в этом мета справочнике id является первичным ключом - то джойнить со справочниками можно не глядя, не промахнешься. При классическом построении - один справочник - одна таблица такой финт просто не решить.
Сорри, что поднимаю древнюю тему, но вот такой вопрос возник.kdv писал(а):это почему? есть же uid. на него можно FK построить.и ссылочная целостность только на триггерах?
это значит что в справочник можно загнать описание конкретной "справочной" таблицы, и ее данные.что значит "самодокументируемость" и это как?
Посмотри например
http://www.ibase.ru/devinfo/oop_rdbms.htm
это практически то же самое.
А есть ли реально работающие БД, построенные по такой схеме (как в статье по ссылке описаны, ООП БД)?
Хотелось бы очередной проект поднять в такой спецификации, ибо попробовал тестовые варианты - очень удобно, хоть поначалу и непривычно. Но что-то страшно за центральную таблицу с объектами. Как оно будет по скорости, и по надежности?
Интересны мнения о реально работающих разработках в таком ключе.