И много у вас таких разных компаний? Обязательно хранить их в одной БД?
Я к тому, что сливать в одну кучу легко и быстро, рассортировывать по кучкам - гораздо более трудоемкий процесс.

MasterZiv это неправда. Все ровно наоборот. Аргументы в студию, пожалуйста.
Вводные данные - поскольку ТС не привел, возьмем с потолка - десятки компаний.
Вопрос - стоит ли сводить их в одну базу или одна компания одна база.
за одну базу
- проще администрировать, проще поддерживать общие данные (справочники, код)
- проще обломать хотелки ретивых представителей отдельных компаний заказчика - "все или никто"
за разные базы
- выше требования к дисциплине администрирования - все действия должны быть скриптами, все действия должны вести свой лог и т.д.
- масштабируемость - надо базе номер два больше ресурсов - пожалуйста - хоть отдельный сервер.
- надежность - сломалась база номер три - остальные работают.
- безопасность - вероятность пользователей увидеть чужие данные гораздо меньше.
- проще снять компанию с поддержки - просто грохнуть базу
- хотелки представителей отдельных компаний - когда нельзя, но очень хочется - в этом случае тоже проще реализуется, хотя это и чревато.

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

MasterZiv вот что за бред ты тут пишешь? Напиши не бред.
Давай исходные данные, аргументы за и против.

Я ж просил - приводи исходные данные.

Однозначно верного ответа НЕТ. В зависимости от конфигурации одни доводы могут быть надуманными , другие критичные, а третьи "а вот про это мы не подумали". Все что мы можем сделать для очередного топикстартера это выложить ВСЕ замеченные грабли.

Теперь по пунктам
MasterZiv 10 компаний повышают объём БД примерно на порядок (в 10 раз).Настраивать отдельные базы проще, чем одну большую, когда все одновременно что-то пытаются сделать.

MasterZiv Ты сравниваешь надёжность работы всего холдинка в случае одной БД с надёжностью работы одной компанииЯ сравниваю время простоя в случае сбоев. И мне не нравится ситуация когда семеро ждут одного.

MasterZiv но тут есть и плюсы -- вместо 10 серверов можно покупать только 2В наше виртуальное время никогда нельзя сказать 10 там серверов 2 или вообще один, а уж сколько это будет по деньгам "ведает только аллах"

MasterZiv делать HSB.Расшифруй аббревиатуру

MasterZiv Детский лепет. Rowwise access делается очень просто. Многие СУБД его даже поддерживают уже в ядре.Самое слабое место в любой системе это человек. В случае разных баз - конфигурация будет в двух местах - в строке подключения и в базе, если админ накосячил, пользователь получит ошибку, в случае одной базы это делается в одном месте (в базе) и тут уже все зависит от приложения.

MasterZiv Данные удалять, естественно, не надо -- нам нужно знать свою историю.И нахрена нам эта история в OLTP базе. Которая занимает место в бакапах, клонируется в тестовую среду, занимает место в бакапах там. Место этой истории в хранилище данных

MasterZiv В чем проблема реализовать их в одной БД?
РАссказать другим компаниям о новшистве -- и все будут пользоваться. Если хотелки не противоречат друг другу.

MasterZiv Ребята, вы тут все понаписали много разной фигни. Я всё это понимаю, все ваши доводы. Всё это -- от неопытности, вы всего боитесь.
Поверьте, всё не так страшно, всё гораздо проще.
У тебя есть хрустальный шар? И ты можешь "говорить за всю Одесу"?

MasterZiv И с данными потом --- просто песня, всё в одной структуре, всё в одной базе -- руководители холдинга вам спасибо скажут сразу. Зачем руководителям холдинга делать сводный отчет по OLTP базе.
Ennor Tiegael А слить все потом в один варехаус - вообще отдельная задача, к раз(об)ъединенности OLTP имеющая довольно никакое отношение.Именно.

Еще раз повторю - однозначного ответа быть не может. По любому будет выбор меньшего из зол , поэтому в первом приближении я всегда стараюсь отделить "котлеты отдельно, мухи отдельно" и только потом делать котлеты из мух. Злой мачехе потребовались три секунды чтобы смешать крупу, чтобы Золушка всю ночь ее разгребала.