Не все тут так безусловно.

Если БД организаций всегда будут крутиться на одном сервере. Если эти организации -являются подразделениями более крупной единой организации. Если эти организации не могут существовать по отдельности. Если требуется некая обобщенная отчетность. То лучше единая база.

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


В общем тут надо точно знать почему несколько организаций будут хранить свои данные на одном сервере, степень их родства и самостоятельности.

Заказчик11) Как отговорить от такого кривого решения (разделение баз по организационному признаку)?

Поставьте задачи:
1 о необходимости мгновенном отражения всех изменений касающихся определённого документа во всех базах
2 объединенные отчеты со всех баз

Заказчик1А ссылки на юридические документы можно?
А при чем тут юридические документы?
С точки зрения закона лишь бы не были доступны персональные данные получаемые от работников/клиентов одной конторой в другой конторе. Но это совсем тут не при чем. Будут в одной физической базе храниться - вопрс разграничения прав доступа; будут в разных, но на одном сервере - опять же вопрос разграничения прав. Просто средства разграничения этих самых прав.

Все остальное с юридической точки зрения дело самих фирм и их договорных отношений. Так, что ни каких ссылок вам ни кто не даст. Разве, что закон о персональных данных можете почитать.

Заказчик1А есть теоретические изыскания на тему разделения баз?
Не очень понимаю, что вы хотите. По этому выскажу несколько мыслей по этому поводу.

Заказчик1Быстрее работает. Если делать 10 запросов к 10-ти базам, в каждой из которых 100 записей и 10% ресурса сервера, то это быстрее, чем делать 10 запросов к одной базе, в которой 1000 записей и 100% ресурса сервера».

Достаточно спорное заявление. Скажу честно на деле не проверял, но. Сомневаюсь, что
Заказчик1Быстрее работает. Если делать 10 запросов к 10-ти базам, в каждой из которых 100 записей и 10% ресурса сервера, то это быстрее, чем делать 10 запросов к одной базе, в которой 1000 записей и 100% ресурса сервера
Скорее всего разница если и будет то ничтожно мала. Тут будут крутиться несколько операционок в виртуальных машинах. (надеюсь это хотя бы аппаратная виртуализация)
Про 10% и 100% ресурсов сервера совершенно не понял. С какого потолка взяты эти цифры? По большому счету разница только к одному файлу мы обращаемся или к нескольким. Ну а порядок цифр данных для примера (10, 100, 1000) это вообще мелочевка.

Кроме того как у них получается 10 баз по 100 записей против 1 в 1000 если по условиям задачи документы дублируются в остальные базы. Кроме того это вообще не вопрос 100 записей или 1000 если грамотные запросы и грамотные индексы.


Правда во всем этом есть одно очень большое и значимое "но". Я так понимаю вы заказчик и не являетесь специалистом в данной области (я правильно понял?) возможно есть какие-то видимые разработчику причины по которым все же следует разделить базы. Но он по каким то причинам не может до вас донести данные причины.


Вообще странное решение. С одной стороны базы разводят на разные объясняя запросами и количеством записей. Что указывает, что объем БД значителен. С другой стороны выбран запуск серверов в виртуальных машинах на одном физичесоком сервере, что на мой взгляд не совсем стыкуется с большими объемами данных.

Заказчик1Порядок цифр - 100 000, миллион и несколько миллионов. Реальное количество организаций (и баз данных) будет под 50, в перспективе - под 500.

Есть ли хоть малейший шанс выхода хоть одной фирмы из вашего "конгломерата"?
На вскидку, каков процент общих документов в объёме конкретной организации?
Есть ли необходимость отслеживать все изменения по конкретному документу во всех организациях?
У каждого сервера (виртуального) подразумевается свой админ от каждой организации?
Есть ли необходимость сводных отчетов по всем организациям сразу?

50-500 виртуальных машин это жесть :)

Заказчик1А когда мне начали городить что мол "работать будет быстрее" я уже задумался над здравым смыслом.
Речь идёт о стандартном документообороте (кто-то родил документ, а далее документ живет своей жизнью - футболиться по боссам для утверждения/редактирования, бегает по лестницам исполнителей, обрастает статусами и сроками)?

Заказчик1Если так приспичило, что мешает сделать репликацию?

По моему опыту репликация только в крайнем случае - если уж совсем приспичило :)

Заказчик1Зачем именно организационно разделять?
Если организации все же разные. И их общий документооборот не большой в общей массе внутреннего документооборота. Если они не объеденены общей вышестоящей организацией. То вопрос надо ставить: "А зачем объединять?"

Т.е. надо понимать, что в принципе к внутреннему документообороту одной фирмы могут получить доступ лица из другой фирмы - все зависит от админа и организации хранения данных софтиной. Опять же если одна организация захочет сама отвечать и следить за своей БД на своем персональном сервере (например программа будет медленно работать, а все не захотят вкладывать деньги в апгрейд свервера, а одни скажут "не, ребята, нам скорость важнее у нас будет база на своём железе"). Опять же минус общей базы для разных организаций: не дай Бог, что-то случиться с данными (и не важно по какой и по чьей причине): начнётся бездоказательный спор, ругательства и обиды: "это ваш админ, это ваш работник, это ваш...."....


То, что при нескольких базах вместо одной увеличится сложность обслуживания. Я бы не сказал. Я сам обслуживаю пару десятков баз (разделение исторически сложившийся факт ибо даже города разные и родилось все еще в доинтернетные времена - сейчас постепенно движется к объединению. но у меня по сути подразделения одной рганизации). Обновление легко - написал утилиту которая прогоняет скрипты обновлений по списку баз. И все. Если же 3*тьфу произойдет катаклизм с одной из баз, и все бэкапы сдохнут :).... То маленькую базу легче по крупицам восстановить. Чем общую. Кроме того не знаю как в постгрии, а в firebird появилась возможность делать общие запросы к нескольким БД (они могут быть на разных серверах).

Заказчик1Вот по поводу последнего... А если в одной из 500 баз (для условности в 499-й) обновление не накатилось (условно, конфликт данных), а обновлять нужно все 500 одновременно т.к. они работать друг с другом не смогут (хотя бы общие справочники) то что тогда? 498 баз откатывать? или делать все на копиях? бр......
Ну если БД имеют совершенно идентичную структуру. То такие случаи редки. Хотя все зависит от степени нерадивасти админа (например не уследил, что место исчерпалось на диске), ну и грамотного построения архитектуры, чтоб там косяков не было явных.

А так реализовать можно то разными способами. И все зависит от конкретного случая. В ином не сложно откатить. В другом руками 499 базу подтянуть. В третьем предусмотреть механизм временного кеширования изменений с последующим (после восстановления нормальной ситуации) состыковыванием. От этого ни куда не денешься в случае в случае выбора решения с несколькими БД.

Может и на копиях. Но я не настолько хорошо знаком с постгрии и не знаю можно ли там оперативно иметь свежую копию. Прямым копированием нескольких терабайт - не слишком быстрое занятие. Если есть возможность в разумное время иметь свежую копию - почему бы и нет.

Вообще. Исходя из ваших ответов я бы сделал единую базу. Но остается шанс, что за кадром осталось нечто важное. ;) А так же я не работал с базами в несколько террабайт. На моем уровне опыта я бы решал вопрос с производительностью железным способом (естественно при этом внимательно прорабатывая каждый запрос в самой софтине).



Заказчик1А жарптица то рулит. Но боюсь не потянет она базы в десятки терабайт.
Врать не буду не знаю. Вот разве, что статейка: http://www.ibase.ru/devinfo/fb1tb.htm