iBase.ru Forum

пришел на новое место работы и в текущем проекте столкнулся с неожиданным для меня приемом - большая часть справочников хранится в одной таблице. (всего таблиц, больше 100)

структура такая:

uid - уникальный суррогатный ключ
id_type - код справочника
id - код в справочнике
text - наименование
full_text - полное наименование
note - примечание

т.к. с таким приемом столкнулся впервые, то вопрос: какие преимущества и недостатки в таком методе?

При появлении нового справочника не приходится корежить структуру БД и приложение. Недостаток - чуть более сложные запросы если у элемента справочника еть доп.атрибуты.

Возможна самодокументируемость справочника.
Можно написать запрос, возвращающий всю структуру справочников, для отчёта.

Dimitry Sibiryakov писал(а):При появлении нового справочника не приходится корежить структуру БД и приложение. Недостаток - чуть более сложные запросы если у элемента справочника еть доп.атрибуты.

и ссылочная целостность только на триггерах?

WildSery писал(а):Возможна самодокументируемость справочника.
Можно написать запрос, возвращающий всю структуру справочников, для отчёта.

что значит "самодокументируемость" и это как?

и ссылочная целостность только на триггерах?

это почему? есть же uid. на него можно FK построить.

что значит "самодокументируемость" и это как?

это значит что в справочник можно загнать описание конкретной "справочной" таблицы, и ее данные.
Посмотри например
http://www.ibase.ru/devinfo/oop_rdbms.htm
это практически то же самое.

Батор писал(а):какие преимущества и недостатки в таком методе?

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

kdv писал(а):

и ссылочная целостность только на триггерах?

это почему? есть же uid. на него можно FK построить.

что значит "самодокументируемость" и это как?

это значит что в справочник можно загнать описание конкретной "справочной" таблицы, и ее данные.
Посмотри например
http://www.ibase.ru/devinfo/oop_rdbms.htm
это практически то же самое.

Сорри, что поднимаю древнюю тему, но вот такой вопрос возник.
А есть ли реально работающие БД, построенные по такой схеме (как в статье по ссылке описаны, ООП БД)?

Хотелось бы очередной проект поднять в такой спецификации, ибо попробовал тестовые варианты - очень удобно, хоть поначалу и непривычно. Но что-то страшно за центральную таблицу с объектами. Как оно будет по скорости, и по надежности?

Интересны мнения о реально работающих разработках в таком ключе.

Эту тему обсуждали весьма подробно на sql.ru (страниц шесть, вроде. Можешь даже поискать ее там). Лично я из всего обсуждения сделал вывод: один справочник - одна таблица.