Тема: Оптимальная БД

Как добиться оптимальной структуры БД? Ведь в КИС есть несколько составляющих, которые используют как свои данные, так и данные составляющих. Как избавится от избыточности, как добиться наилучшей синхронизации?

Простой пример…
Бухгалтерский учет оперирует информацией о контрагентах, CRM тоже. Пересечений между этими составляющими не особо много. Держать все данные этих составляющих вместе не всегда выгодно, вот и получается избыточность информации о контрагентах и вопрос о синхронизации этих данных. Легко может получится, что либо в бух учете не хватает каких либо данных которые знает CRM или, что данные разняться!

Общая БД панацея?
_______________________________________

Как вариант для решения данной проблемы я пытался реализовать следующее:
Рассматриваем БД как множества… N множеств имеют какие-то пересечения, находим простейшие, не дробимые, и считаем их основой. Из получившегося набора множеств путем объединения получаем любое из больших.

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

И при этом подходе мы не получаем лоскутной системы! Мы получаем гибко настраиваемые рабочие места, более легкое сопровождение. Все эти простейшие БД объединяются и работают как одно целое!

Информационная область - это то, чего мне жутко не хватает... Ничего подобного реализованного я не видел... Поэтому в свое время и стал разрабатывать "Комплес разработки бизнес приложений". Но уперся в то, что затраты и риск огромные...

Почему бы и нет... Правда наработки, которые у меня были сделаны в этом направлении частично утеряны... Прикрепляю файлик в котором частично описано, что я хотел сделать... Образно понять можно хоть там и недоработано... Совместными усилиями можно доработать до ума...

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

К TOT: если что получиться интересное оформим в виде статьи?

Андрей,конешно.

Господа.
Позвольте встрянуть.
Если Вы полагаете объектно-ориентированное решение, то надо понимать, что SQL не подразумевает подобный подход. Делить задачу на маленькие объектные составляющие с методами доступа к таблицам - примитивизация SQL и, по сути, решение которое игнорирует всю мощь SQL. (Хотя конечно можно классы наследовать ) Использовать SQL базы как простой менеджер записей - не очень продуктивно.
Если же вы полагаете строить некую динамическую интерпретационную систему с динамическими таблицами, описателями, встроенными языками и генераторами SQL запросов, то IMHO при более-менее сложной структуре, управление таким механизмом становится задачей чрезвычайно сложной, и все равно все упрется в необходимость писать SQL запросы, отвечающие требованиям данного момента, с учетом всех тонкостей текущей организации информационного поля. Да и медленно все это.

> Ну вроде бы Postgress это позволяет? Или я не прав?
Ну разве наследование структуры таблиц это уже ООП?
> Тут как раз и приходит необходимость 3-х звенной архитектуры.
Я не говорю о забвении принципов ООП в решении задачи. Я говорю, что объектная декомпозиция на уровне создания простых "базных" частей и обертка их объектами и последующее использование полученных оберток в процессе создания более сложных классов уничтожает мощь SQL.

Такое ощущение что мы путаем мягкое с теплым.
Никто никому ничего не противопоставляет. Ну а по существу вопроса я высказывался выше. Я говорил только о высказываниях Flattera о информационном поле и о таблично-объектной декомпозиции задачи. См. мои сообщения выше.

Я говорил немного не о том...
Полная универсальность это абсурд для пользователя, можно работать и в Access очень универсально. Но пользователь без адресного внедрения работать в нем не будет да и затраты для этого адресного внедрения со стороны программера слишком велики.

На самом деле основа любого бизнес приложения это справочники которые и составляют БД. В связи с этим нам нужно просто классифицировать требования прилагаемые бизнес приложениями к БД, и исходя из этого описать объектную модель нашей разработки. А не объектную модель БД!!! Объектная БД это конечно хорошо, но требуется ли она? Нам нужно то всего лишь быстрые выборки и апдейты данных, проработанная структура и контроль ссылочной целостности.

С этим трудно спорить.

В этом направлении и нужно работать

Надо подумать сперва.

Есть еще интересные вопросы касающиеся «информационного поля» с одной стороны это делается для уменьшения избыточности данных, но свести избыточность к 0 значит замедлить систему и сильно завысить требования к железу. Необходимо найти оптимальное соотношение допустимой избыточности данных к производительности системы.

Например:
ИО№1: Данные о контрагентах организаций.
Справочник «Контрагенты»

ИО№2: CMR (работа с клиентами)
Справочник «Контрагенты» (ИО№1)
Справочник «Контактные лица» (подчинен справочнику «Контрагенты»)

Есть несколько путей реализации:
1) минимальная избыточность
В ИО№2: хранятся только уникальные идентификаторы элементов (ИО№1) используемых в ИО№2 т.е. те у которых есть подчиненные. А все выборки для просмотра списков запросами к БД ИО№1
2) Использование всех данных ИО№1 и их синхронизация в определенные моменты в ИО№2
3) Производные от первых 2.

Зависит от конкретной реализации... Зачастую оптимизация по скорости сводится к увеличению избыточности!