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

[rootadmin]

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

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

[Likefire]

Цитата:

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

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

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

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

[Fordewind]

Цитата:

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

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

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

+1

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

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

Цитата:

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

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

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

[Likefire]

Цитата:

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

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

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