gkislin Mar 10 2013 at 18:56

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

3 min

16K

PostgreSQL*SQL*

Comments 21

pil0t Mar 10 2013 at 19:17

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

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

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

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

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

gkislin Mar 10 2013 at 20:04

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

pil0t Mar 10 2013 at 20:46

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

arni Mar 11 2013 at 05:31

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

qw1 Mar 12 2013 at 19:36

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

gkislin Mar 11 2013 at 06:13

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

r0zh0k Mar 10 2013 at 19:59

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

gkislin Mar 11 2013 at 06:07

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

gkislin Mar 11 2013 at 10:34

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

gandjustas Mar 10 2013 at 20:30

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

KAndy Mar 10 2013 at 21:14

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

gandjustas Mar 11 2013 at 06:23

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

Fragster Mar 11 2013 at 04:22

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

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

gkislin Mar 11 2013 at 06:11

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

gandjustas Mar 11 2013 at 06:21

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

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

gkislin Mar 11 2013 at 10:40

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

gandjustas Mar 11 2013 at 12:12

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

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

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

gkislin Mar 12 2013 at 11:33

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

gkislin Mar 12 2013 at 11:40

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

solver Mar 11 2013 at 10:55

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

qw1 Mar 12 2013 at 19:30

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

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

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