Есть ПО, в числе прочего функционала есть:
- фактический склад (документы + таблицы с движениями и остатками с фиксированным набором измерений),
- учет задолженностей (документы + отдельные таблицы с движениями и остатками с фиксированным набором измерений),
- учет загрузки произв. подразделений (опять же отдельный регистр со своим набором измерений),
- для анализа по некоторым предметным областям (продажи продукции, производственные процессы, сервис/обслуживание) сделан недо-OLAP: SSAS (на одном с БД сервере) + факты и измерения на представлениях (view), процессится все по ночам, в продажах 1.6млн фактов за 5 лет + 5 измерений дат + ~10 измерений "по справочникам"- пока "успевает").
Полноценного бухгалтерского учета нет (выгрузки в 1С).

Получается, что там, где для статистики/аналитики достаточно "суточной" (и менее) точности - прижился недо-OLAP :), там где нужны итоги онлайн - недо-регистры :-)))

В рамках "непрерывного совершенствования" :) сделал прототип учетной подсистемы (справочник регистров + произвольное число настраиваемых измерений + произвольное число доп. мер + проводки + расчет итогов на триггерах). Синтетический тест делает ~1млн движений в час (0.5млн "полных" проводок) с 5 клиентов в непрерывном цикле делающих проводки/движения по разным регистрам + каждый 10 ввод данных задним числом. Сравнивать не с чем, но думаю - для нашей системы вполне приемлемо.

И теперь у меня возникает два связанно-независимых :) направления, по которым хочется получить совет:

1. Все, что касается "движений и остатков/оборотов" я точно переведу на "новый" подход. Но вот имеет ли смысл в одном наборе таблиц совмещать и складской учет и прочие регистры (задолженности, мощности и т.п.)?
Как вариант, можно просто клонировать решение.
Плюс: для складов/номенклатуры можно сделать чуть более предметно ориентированный интерфейс.
Минус: в общем-то 90% дублирование функционала и отчасти кода.

2. На регистрах с остатками/оборотами можно реализовать по сути те же отчеты, что дает и OLAP.
Плюс OLAP'а - условно "привычный" клиент (Excel/XtraPivotGrid) c возможностью легко крутить данные. Для регистров придется изобретать "универсальный построитель отчетов".
Минус: опять же дублирующийся функционал + кривоватая реализация OLAP + нехватка компетенций сделать OLAP "как положено".
Вопрос: что с этим делать?
По идее можно двинуться в сторону отказа от регистров и реализации онлайн итогов через OLAP.
Куда копать?: на каждый куб/регистр генерить таблицу движений/фактов с заданным в справочнике кубов/измерений нужным количеством столбцов (по кол-ву измерений).

Заранее спасибо.

iscrafmAleksey Kh.нехватка компетенций сделать OLAP "как положено"
а как положено?
Чтобы можно было обновлять и анализировать данные без существенного влияния на OLTP.
Т.е. отдельный dwh + etl (перенос только изменений).

Многобукоф, понял
Делаю выжимку.

Вопрос 1: Стоит ли совмещать регистры складского учета с прочими регистрами (задолженности, обороты и т.п.)?

Вопрос 2: Если в ПО есть возможность реализации аналитических отчетов по разным процессам через регистры, механизм которых есть в системе (но в настоящее время для этих целей не используется) - то стоит ли развивать тему OLAP через SSAS (который сделан "по простому" и перестает удовлетворять требованиям по быстродействию).

Злой Бобр1. Однозначно нестоит. Мухи отдельно, котлеты отдельно.
Так в том то и дело, что нет котлет - одни и те же мухи.
По факту, нет разницы в реализации расчёта итогов задолженности контрагента в валюте и остатка номенклатуры на складе.

Злой Бобр
2. Если объемы данных большие то OLAP через SSAS является единственным выходом. Например та же 1С прекрасно формирует OLAP на небольших данных, но когда пытаемся анализировать средний объем данных то 1С "умирает". Поэтому если есть необходимость в анализе то лучше сразу использовать OLAP через SSAS, а не пытаться протолкнуть слона в игольное ушко.Совет понятен, но вот с аргументацией как то не очень :)

iscrafmнакопление информации по регистрам и есть по сути создание предметно-ориентированного информационного хранилища.
Понятно. Но у направления "Отказ от SSAS, переход на регистры" есть и недостатки:
- отсутствие готового "клиента" (придется разрабатывать "универсальный построитель отчетов"), в то время как у "ssas olap" уже все есть.
- я пробовал считать и получать итоги - это получилось, будет ли быстрой произвольная аналитика - пока не пробовал, народ вот пишет "в 1С медленно".

iscrafmЕсли умеете этим пользоваться, то конечно используйте. Подготовленная агрегированная информация гораздо лучше простой OLTP свалки, которую потом пытаются всеми средствами от безысходности алапизироватьЭто только если там свалка и безысходность. Я о нашем ПО такого не писал :)

up!
Вопрос 1:
Стоит ли совмещать в одних таблицах хранение информации и по складским регистрам и по бухгалтерским и по прочим?
Разницы в технической реализации нет. Смущают только объемы данных и смешение предметных областей.
У кого какой опыт?
Поделитесь мыслями, пож.

Злой БобрAleksey Kh.,
Я тебе уже сказал что нестоит. Зачем повторяться? Или что-то непонятно? Ну тогда конкретно спрашивайте что именно. Не стоит, потому что не стоит? :) Хотелось бы все же понять почему, в технических терминах, а не кулинарных :)
iscrafmвы лучше на форум по 1С пройдите. Не всем понятны ваши специфические термины.
Предлагаете посмотреть, как сделано в 1С и сделать так же?
Не понимаю, чем кроме рассказать, как уже сделано в 1С они мне могут помочь - у них выбора варианта реализации нет.
iscrafmНе всем понятны ваши специфические термины.Да, по неопытности, я могу что-нибудь не тем словом обозвать. Какие термины? Я расшифрую.

Злой БобрВ "кулинарных" терминах - потому что товар это товар, нематериальные активы тоже совсем другое, ну и т.п.
В "технических" - если у вас будет одна таблица то чтение/запись из одной таблицы, мягко говоря не очень хорошо
Регистры (в ИС) - способ организации работы с агрегированием значений мер в разрезе измерений, как я это понимаю.
В общем случае, кмк, абсолютно пофигу кто является объектом измерения, будь то остаток номенклатуры, стоимость нематериальных активов или доступные у произв. подразделения ресурсы.
Дальше получается, что количество того, что мы хотим измерять - произвольно.
В настоящее время в нашем ПО нет фин. учета, количество регистров невелико и до сих пор под каждый регистр создавалась своя пара таблиц с количеством полей равным количеству мер и измерений: движения + итоги. Предлагаете в таком направлении и дальше двигаться?
Злой БобрИ насчет 1С. Ненужно смотреть как сделано у них. Они как немогли так и неумеют делать учетное ПО.У кого, на Ваш взгляд, учетная подсистема сделана хорошо?

mad_nazgulADempiere/iDempiere например :-)
Есть описание реализации складского или упр. учета?