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

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

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


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

Заказчик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

Заказчик1Абалденный аргумент за многобазовую структуру...
"Постгре не тянет больше 1000 подключений"
Осталось убиться об стену.

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

Правда это беглое гугление :)

Тут лучше найти кто реально работал с большими БД на постгри :)

Другое дело, что если железо упрётся в свой потолок, то разные базы можно разнести по разным физическим серверам.
Хотя в случае единой - обратить внимание на кластерные решения.

Заказчик1,

Вообще хотел бы обратить внимание еще на один аспект.
Раз вы обратились к данному исполнителю, значит есть определённая степень доверия. Исполнитель сейчас видит полную картину и считает правильным решением иметь несколько баз. Четко опишите все что требуется от программы в ТЗ. И не парьтесь. Правильное решение или нет покажет время, но есть одно но. Если вы убедите сделать все в одной базе, а исполнитель завалит проект (даже если это изначально правильное решение, но он выберет не тот подход, или скажется недостаток квалификации, или магнитные бури). - то исполнитель свалит все беды лично на вас, скажет, что он белый и пушистый сопротивлялся как мог, а вы задавили своим положением заказчика, который "всегда прав".

Я не знаю какое вы положение занимаете в конторе, но можете оказаться стрелочником.

Заказчик1Честно гуглил минут 20... не нашел примеров с подключением свыше 1000 (( везде пишут что мол 100 в конфиге, если надо убирайте. И еще один параметр вроде подправить надо
Я тоже. Второй параметр потребует в конечном итоге много памяти.
Самое надежно смоделировать ситуацию: тестовая база - тестовая софтина запущенная 3000 и долбящая какие-то запросы. Это конечно не будет реальными условиями, но тем не менее может дать информацию к размышлению

Заказчик1На XP свыше 150 подключений поднять не удалось.... СУБД отваливается насмерть. Для сравнения FB "крякнул" на 3890 подключений :)
Те самые параметры крутили? Памяти достаточно?
К тому же XP может быть и не показатель. Мне кажется для такой задачи стоит использовать серверную ОС. При чем лучше Linux или BSD.

Так для информации к размышлению. Была база 17Гигов. (Firebird). Каждую ночь выполнялся бэкап/разбэкап/копирование. Под управлением Windows Server 2008 все только только успевало завершитсья к началу следующего рабочего дня. Та же самая машина под управлением Linux. На сколько я помню часа 3.

Так же заметно сократилось время некоторых достаточно объемных по количеству запросов операций.

Заказчик1Под opensuse 1700 подключений получилось. так что звездят товарищи...
Правда, подключения пассивные (сделали insert и оставили висеть). Через некоторое время перепишу, засунув каждое подключение в отдельный поток с запросом каждые 30 сек и посмотрю, через сколько отваливаться начнут.

Тут, думаю, особо усердствовать смысла нет. Если только по замыслу системы это не будет 3000 роботов. Если все же 3000 живых людей в роли клиентов, то ситуация когда одновременно 3000 клиентов начнут добить запросы не кажется маловероятной. Хотя если выдержит запросы сразу от всех подключений - это будет гуд.