Архитектура базы данных: унификация (на примере ERP)

[pil0t]

Я бы не был столь категоричным в

Общие свойства всех документов размещаем в отдельной таблице

и получаем узкое место. При серьёзном изменении одного типа документов рискуем эскалировать блокировку на всю таблицу, а следовательно все документы.

Не хотите пробовать использовать ORM и наследование с разными mappings?

При этом, там где это действительно необходимо, выбрав ClassTable легко получаем то что вы описали.
А там где более выгодно (например в плане производительности и удобства партиционирования) разбить на несколько таблиц — ConcreteTable

[gkislin]

Простите, не понял- каким образом я могу получить блокировку на всю таблицу (если конечно уровень изоляции не Serializable)?
Изменение типа документа- это в дизайне?

[pil0t]

msdn При блокировании значительного количества строк блокировка может эскалироваться на страницы, и далее на всю таблицу.

[arni]

Поведение, характерное для блокировочников, или даже отдельных СУБД отдельных поставщиков не должно приниматься как должное ко всем СУБД. Не MsSQL единым живо реляционное хранение данных.

[qw1]

Вообще MS SQL, начиная с 2005, легко может быть честным версионником.

[gkislin]

По поводу ORM (не имею ничего против него) — дописал вступление.

[r0zh0k]

Для таких штук EAV решает, на самом деле. Особенно если система позиционируется как легко кастомизируемая.

[gkislin]

Ну, наверное здесь есть что-то схожее с EAV. Только аттрибутами являются не примитивные типы, а составные.

[gkislin]

А вот тут про EAV SQL антипаттерн: www.slideshare.net/billkarwin/sql-antipatterns-strike-back.
Данный подход свободен от них, кроме нестрогое ограничение полей.

[gandjustas]

EAV не решает, потому что дико тормозит при сколь-нибудь серьезном объеме данных.

[KAndy]

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

[gandjustas]

А чем eav + материализация лучше отдельных таблиц? Все равно ведь схему менять надо, на каждое добавление атрибута.

[Fragster]

Общие свойства всех документов размещаем в отдельной таблице.

Вы только что изобрели 1с 7.7. Это не может работать при большом количестве пользователей.

[gkislin]

Здесь нужно определиться что такое большие нагрузки. ERP- это корпоративное интранет приложение, максимальная нагрузка не сравнима с приложениями для публичного интенсивного пользования.

[gandjustas]

Нагрузка для корпоративных приложений измеряется объемами обрабатываемых данных. В типичной учетной системе необходимо быстро и стабильно работать при 1М+ проводках и при 100,000 первичных документов.

Посчитать легко. Берем цикл жизни системы — 5-9 лет — умножаем на количество первичных документов и проводок в год, умножаем на Пи (оно примерно равно 15%-росту в год на все 9 лет). Получаем требуемые числа.

[gkislin]

А как насчет горизонтального секционирования по подсистеме и, при необходимости, по типу документа?

[gandjustas]

Это зависит от запросов, можно неаккуратно писать и упереться в в одну общую таблицу сущностей, если действовать по модели, предложенной в статье. Разные таблицы для разных типов (3НФ) конечно приближает к идеалу, но её сложно поддерживать.

Еще обязательно рассмотреть такие моменты:
1) создание связей между произвольными типами
2) версионность документов
3) «корзина» удаленных элементов
4) разграничение доступа

Системы валятся от объема данных не потому что подставь_сюда_любой_движок_БД слабоват, а потому что изначально не продумывали аспекты, которые я указал выше, а потом они «внезапно» возникли.

[gkislin]

Спасибо за подробные ответы.

[gkislin]

Секционирование неудобно тем, что на общие таблицу нельзя делать FK. Поддерживать по подсистемам будет действительно сложно. Для производительности можно секционировать актуальные и исторические данные, работая по умолчанию только с актуальными. Объем данных существенно уменьшится.

[solver]

Для 1С 7.7, уже 70 одновременно работающих операторов в стандартной торговле большая проблема и без костылей не решается.
Так что речи о публичных сервисах даже близко нет.

[qw1]

Тем не менее, такой подход может дать системе реактивный старт.

У нас так и было:
Все справочники имели универсальную структуру и жили в одном дереве. Можно заводить типизированные параметры, действующие на объекты от какого-то узла и ниже. Значения параметров тоже могут ссылаться на узлы дерева. Там же в дереве и юзеры, и группы. По сути чем-то LISP напоминает (все есть список => всё есть узел дерева).
Ещё и метаданные документов лежали в БД, объект-документ не содержал поля фиксированного типа, обращение к полю происходило по строковому имени, как к полю dataset. Таким образом, заведение нового документа требовало минимум кодирования.

Через несколько лет оно стало тормозить и самые популярные документы были вынесены в отдельные таблицы, а что-то и на другой сервер (благо трёхзвенка). Но для документов, создающихся в количестве не более 1E6 за год, можно и эту неэффективную схему использовать.