Однажды была поставлена задачка в короткие сроки реализовать универсальную PDM-систему для хранения проектных данных. В качестве СУБД - Firebird. Из того что нашел в инете на тему деревьев в SQL больше всего понравилась статья ООП в РСУБД, и идея была упрощена до предела. Основная структура БД состоит всего из четырех таблиц: Objects, Attribs, Links, Rights.
На нижнем уровне абстракции всё является объектом: классы, пользователи, атрибуты,классификаторы, меню администрирования. Это сразу дало кучу преимуществ: практически всё API сводится к манипулированию объектами. Недостатки тоже проявились сразу же: любой запрос свойств объектов превращался в кучу рекурсивных запросов. Пришлось создавать локальный кэш объектов.
В упрощенном виде схема БД выглядит так:
Таблица AttribTypes вспомогательная, для ускорения выборки некоторых типов атрибутов.
В принципе, схему можно еще упростить, выкинув таблицу Links и добавив поле в таблицу Attribs для хранения ссылок на другие объекты.
Описанная схема уже больше года работает:
Всё, что вы видите в дереве, это объекты.
2 комментария:
На мой взгляд, как и в подобных ветеранских системах, ускорения при получении информации об объекте(ах) можно получить путем написания хранимых процедур на стороне сервера. Тогда запрос от клиента будет один, все множественные запросы будут происходить в рамках сервера, а клиенту вернется только результат. Мое дилетансткое имхо :)
Само собой разумеется, что рядом с этими таблицами куча ХП, тем не менее, от кэширования на стороне клиента тоже свои выгоды. Одно другому никак не мешает.
Отправить комментарий