Дублирование данных смежных модулей

[Likefire]

Всем доброго дня!
Меня озадачили анализом функциональности ERP-систем в части, касающейся CRM. Так вот, заметил одну интересную особенность, которую опишу на примере как раз стандартного функционала Нава. Кто не знает: в Наве существует такая возможность создавать из Контакта (Управление Отношениями) - Клиента (Продажи & Клиенты), Поставщика (Покупки & Поставщики) и Банковский счет. В целом логика такого преобразования понятна - необходимо обеспечить модульность: кому не нужен функционал CRM, а нужны Продажи & Клиенты - те спокойно могут расчитывать на то, что их функционал будет содержать базовые данные о субъектах их деятельности, а если и то и другое разом, то клиента сначала надо "вырастить" из контакта, а уж когда он созрел - переводить его в качественно новый статус. Так вот: при таком переводе в статус клиента (покупателя) получается, что львиная доля данных контакта попросту дублируется, а то и затраивается в базе данных. Такая же точно картинка наблюдается в Аксапте и ещё более усугубленная - в SAP R/3. Анализ массовой доли задвоений дал результат на уровне 10-15% задвоения данных. То есть прикидывайте сами: если база у вас занимает в районе 10 гига, то получается, что где-то около 1 гига данных - дублированные? То есть получается, другим словами: функционал ERP-систем организован нерационально? Основной мой вопрос заключается в следующем: есть кто-либо вообще, кто может ответить, зачем (кроме обеспечения модульности) производители приняли подобную организацию данных касательно контактов/клиентов/поставщиков? На мой взгляд эффективнее будет использовать совмещенную сущность, к примеру "Контрагенты" (Бизнес-партнеры - кому как больше нравится), которая была бы общей для нескольких модулей одновременно и не допускала бы задвоения информации. Какие преимущества имеет существующая схема реализации? Какие ещё данные в каких модулях дублируют таким же образом данные? Навскидку могу назвать Сотрудники (Персонал&Зарплата) - Менеджеры (Управление Отношениями) - Ресурсы (Ресурсы). Кто ещё? Какой в результате объем неэффективно используемых данных (задвоенных) вмещают ERP-системы?

[rootadmin]

Вопрос не существенен по моему, т.к. основной прирост размера БД составляют не справочники, а транзакции (товары, проводки, ГП и т.д.).
Так что если база 10гиг, это не значит, что там огромные задвоенные справочники Контактов и Клиентов. Просто там миллионы записей в учетных таблицах.

С уважением..

[Likefire]

Цитата:

Сообщение от rutadmeen

Вопрос не существенен по моему, т.к. основной прирост размера БД составляют не справочники, а транзакции (товары, проводки, ГП и т.д.).
Так что если база 10гиг, это не значит, что там огромные задвоенные справочники Контактов и Клиентов. Просто там миллионы записей в учетных таблицах.

С уважением..

Ну пускай прирост не существенен, ну а вопросы оптимизации и эффективизации организации баз данных как тогда? На основании каких данных строить отчеты: откуда брать ну скажем адрес местонахождения какой-нить организации, если она есть и в контактах и клиентах, а отчет скажем вообще какой-нить логистический, по которому нужно определять точки маршрута? Или в момент формирования этого отчета сверяться: а синхронизированы ли данные полностью? соответствует ли адрес клиента и адрес контакта?

[Fordewind]

Цитата:

Сообщение от rutadmeen

Вопрос не существенен по моему, т.к. основной прирост размера БД составляют не справочники, а транзакции (товары, проводки, ГП и т.д.).
Так что если база 10гиг, это не значит, что там огромные задвоенные справочники Контактов и Клиентов. Просто там миллионы записей в учетных таблицах.

С уважением..

+1

можно просто посмотреть на размер таблицы Customer и Item Ledger Entry.

Это величины 3-4-го и 6-7-го порядков Kb соответственно.

Цитата:

Сообщение от Likefire

Ну пускай прирост не существенен, ну а вопросы оптимизации и эффективизации организации баз данных как тогда? На основании каких данных строить отчеты: откуда брать ну скажем адрес местонахождения какой-нить организации, если она есть и в контактах и клиентах, а отчет скажем вообще какой-нить логистический, по которому нужно определять точки маршрута? Или в момент формирования этого отчета сверяться: а синхронизированы ли данные полностью? соответствует ли адрес клиента и адрес контакта?

Записи можно синхронизировать автоматичекси при вводе информации. Естественно, прописав это руками сначала

[mazzy]

Цитата:

Сообщение от Likefire

То есть получается, другим словами: функционал ERP-систем организован нерационально?

Чтобы ответить на этот вопрос вы должны четко определить критерий рациональности.
С точки зрения базы данных - может быть.
С точки зрения инкапсюляции и облегчения разработки - вряд ли.

И как здесь уже говорил rutadmeen, справочники - мизерная часть от данных.
Львиная доля - это проводки.

[Likefire]

Цитата:

Сообщение от Fordewind

Записи можно синхронизировать автоматичекси при вводе информации. Естественно, прописав это руками сначала

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