Комментарии 21
Я бы не был столь категоричным в
и получаем узкое место. При серьёзном изменении одного типа документов рискуем эскалировать блокировку на всю таблицу, а следовательно все документы.
Не хотите пробовать использовать ORM и наследование с разными mappings?
При этом, там где это действительно необходимо, выбрав ClassTable легко получаем то что вы описали.
А там где более выгодно (например в плане производительности и удобства партиционирования) разбить на несколько таблиц — ConcreteTable
Общие свойства всех документов размещаем в отдельной таблице
и получаем узкое место. При серьёзном изменении одного типа документов рискуем эскалировать блокировку на всю таблицу, а следовательно все документы.
Не хотите пробовать использовать ORM и наследование с разными mappings?
При этом, там где это действительно необходимо, выбрав ClassTable легко получаем то что вы описали.
А там где более выгодно (например в плане производительности и удобства партиционирования) разбить на несколько таблиц — ConcreteTable
+5
Для таких штук EAV решает, на самом деле. Особенно если система позиционируется как легко кастомизируемая.
0
Ну, наверное здесь есть что-то схожее с EAV. Только аттрибутами являются не примитивные типы, а составные.
0
А вот тут про EAV SQL антипаттерн: www.slideshare.net/billkarwin/sql-antipatterns-strike-back.
Данный подход свободен от них, кроме нестрогое ограничение полей.
Данный подход свободен от них, кроме нестрогое ограничение полей.
+1
EAV не решает, потому что дико тормозит при сколь-нибудь серьезном объеме данных.
+1
все дико тормозит при сколь-нибудь серьезном объеме данных, просто для разных технологий он слегка отличается
многие проблемы EAV можна решить материализацией
и говорить что EAV не решает, всеравно что говорить что реляционные базы данных не решают
многие проблемы EAV можна решить материализацией
и говорить что EAV не решает, всеравно что говорить что реляционные базы данных не решают
+1
Общие свойства всех документов размещаем в отдельной таблице.
Вы только что изобрели 1с 7.7. Это не может работать при большом количестве пользователей.
0
Здесь нужно определиться что такое большие нагрузки. ERP- это корпоративное интранет приложение, максимальная нагрузка не сравнима с приложениями для публичного интенсивного пользования.
0
Нагрузка для корпоративных приложений измеряется объемами обрабатываемых данных. В типичной учетной системе необходимо быстро и стабильно работать при 1М+ проводках и при 100,000 первичных документов.
Посчитать легко. Берем цикл жизни системы — 5-9 лет — умножаем на количество первичных документов и проводок в год, умножаем на Пи (оно примерно равно 15%-росту в год на все 9 лет). Получаем требуемые числа.
Посчитать легко. Берем цикл жизни системы — 5-9 лет — умножаем на количество первичных документов и проводок в год, умножаем на Пи (оно примерно равно 15%-росту в год на все 9 лет). Получаем требуемые числа.
+1
А как насчет горизонтального секционирования по подсистеме и, при необходимости, по типу документа?
0
Это зависит от запросов, можно неаккуратно писать и упереться в в одну общую таблицу сущностей, если действовать по модели, предложенной в статье. Разные таблицы для разных типов (3НФ) конечно приближает к идеалу, но её сложно поддерживать.
Еще обязательно рассмотреть такие моменты:
1) создание связей между произвольными типами
2) версионность документов
3) «корзина» удаленных элементов
4) разграничение доступа
Системы валятся от объема данных не потому что подставь_сюда_любой_движок_БД слабоват, а потому что изначально не продумывали аспекты, которые я указал выше, а потом они «внезапно» возникли.
Еще обязательно рассмотреть такие моменты:
1) создание связей между произвольными типами
2) версионность документов
3) «корзина» удаленных элементов
4) разграничение доступа
Системы валятся от объема данных не потому что подставь_сюда_любой_движок_БД слабоват, а потому что изначально не продумывали аспекты, которые я указал выше, а потом они «внезапно» возникли.
0
Спасибо за подробные ответы.
0
Секционирование неудобно тем, что на общие таблицу нельзя делать FK. Поддерживать по подсистемам будет действительно сложно. Для производительности можно секционировать актуальные и исторические данные, работая по умолчанию только с актуальными. Объем данных существенно уменьшится.
0
Для 1С 7.7, уже 70 одновременно работающих операторов в стандартной торговле большая проблема и без костылей не решается.
Так что речи о публичных сервисах даже близко нет.
Так что речи о публичных сервисах даже близко нет.
0
Тем не менее, такой подход может дать системе реактивный старт.
У нас так и было:
Все справочники имели универсальную структуру и жили в одном дереве. Можно заводить типизированные параметры, действующие на объекты от какого-то узла и ниже. Значения параметров тоже могут ссылаться на узлы дерева. Там же в дереве и юзеры, и группы. По сути чем-то LISP напоминает (все есть список => всё есть узел дерева).
Ещё и метаданные документов лежали в БД, объект-документ не содержал поля фиксированного типа, обращение к полю происходило по строковому имени, как к полю dataset. Таким образом, заведение нового документа требовало минимум кодирования.
Через несколько лет оно стало тормозить и самые популярные документы были вынесены в отдельные таблицы, а что-то и на другой сервер (благо трёхзвенка). Но для документов, создающихся в количестве не более 1E6 за год, можно и эту неэффективную схему использовать.
У нас так и было:
Все справочники имели универсальную структуру и жили в одном дереве. Можно заводить типизированные параметры, действующие на объекты от какого-то узла и ниже. Значения параметров тоже могут ссылаться на узлы дерева. Там же в дереве и юзеры, и группы. По сути чем-то LISP напоминает (все есть список => всё есть узел дерева).
Ещё и метаданные документов лежали в БД, объект-документ не содержал поля фиксированного типа, обращение к полю происходило по строковому имени, как к полю dataset. Таким образом, заведение нового документа требовало минимум кодирования.
Через несколько лет оно стало тормозить и самые популярные документы были вынесены в отдельные таблицы, а что-то и на другой сервер (благо трёхзвенка). Но для документов, создающихся в количестве не более 1E6 за год, можно и эту неэффективную схему использовать.
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Архитектура базы данных: унификация (на примере ERP)