Каковы преимущества использования единой базы данных для EACH клиента?

Предположим, что нет никакого штрафа за масштабирование для хранения всех клиентов в одной базе данных; для большинства людей и хорошо настроенных databases/queries, это будет справедливо в наши дни. Если вы не один из этих людей, что ж, тогда польза от Единой базы данных очевидна.

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

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

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

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

Я думаю, что смогу придумать еще несколько дюжин. Но в целом ключевым понятием является "simplicity". Продукт управляет одним клиентом и, следовательно, одной базой данных. В вопросе "But the database also contains other clients" никогда нет никакой сложности. Это соответствует ментальной модели пользователя, где они существуют в одиночку. Такие преимущества, как возможность легко создавать отчеты по всем клиентам сразу, минимальны - как часто вы хотите получить отчет по всему миру, а не только по одному клиенту?

Вот один подход, который я видел раньше:

• Каждый клиент имеет уникальную строку подключения, хранящуюся в главной базе данных клиентов.
• База данных спроектирована таким образом, что все сегментируется по CustomerID, даже если в базе данных есть один клиент.
• Сценарии создаются для переноса всех данных клиента в новую базу данных, если это необходимо, а затем только строка подключения клиента должна быть обновлена, чтобы указать на новое местоположение.

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

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

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

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

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

Что касается боли от обновления сразу 1000 серверов баз данных, то об этом должна позаботиться довольно простая автоматизация. Пока каждая база данных поддерживает идентичную схему, это не будет действительно проблемой. Мы также используем базу данных для каждого клиента, и это хорошо работает для нас.

Вот статья на эту тему (да, это MSDN, но это технологически независимая статья): http://msdn.microsoft.com/en-us/library/aa479086.aspx .

Еще одно обсуждение мульти-аренды, как это относится к вашей модели данных здесь: http://www.ayende.com/Blog/archive/2008/08/07/Multi-Tenancy--The-Physical-Data-Model.aspx

Масштабируемость. Безопасность. Наша компания также использует 1 DB на каждого клиента. Это также делает код немного проще в обслуживании.

Я просто добавляю этот ответ, чтобы включить сюда слово мультитенант. Я искал это, используя "multitenant" в качестве запроса, и этот не появился.

Спасибо за Ваш вклад-все отличные и очень правильные моменты. Я полагаю, что я больше смотрю на гибкость обновления. Если вам нужно изменить схему, чтобы добавить новую функцию (скажем, для веб-приложения) или улучшить существующие функции, это просто сделать в одной базе данных. Если вы должны были реплицировать это изменение через 1000 отдельных баз данных, вероятность ошибки возрастает. Что делать, если операция не удалась? Сколько времени требуется для обновления каждого клиента?

Если хранятся правильные резервные копии (или если ваша база данных была структурирована так, что данные никогда не перезаписывались), восстановление данных для конкретного клиента является тривиальным.

Простота кода, хотя и важна, на самом деле не становится чрезвычайно сложной. В зависимости от используемого языка и методологий можно легко создавать объекты, представляющие только тот конкретный клиент (который хранит конкретный клиент ID), а rest проекта должен быть закодирован только для одного объекта (вроде как для одного клиента).

Масштабируемость-это то, что нужно учитывать - Вы правы, что легко взять одну изолированную базу данных и переместить ее на другой физический сервер; однако становится все проще объединять серверы в кластеры - и даже без кластеризации, кажется, что было бы небольшим изменением указать каждому клиенту базу данных SERVER, на которой размещена универсальная база данных (так что вы могли бы иметь два или три сервера баз данных, на которых размещена только одна база данных). При таком подходе процесс обновления ограничивается только тремя базами данных.

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

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

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

Мне было бы интересно услышать немного больше контекста от вас по этому поводу, потому что кластеризация-это не простая тема и дорого обходится в мире RDBMS. Существует много разговоров/бравада о кластеризации в нереляционных мире Google с BigTable и т. д. но они решают другой набор проблем и теряют некоторые полезные функции от RDBMS.

Есть несколько значений "database"

• аппаратная коробка
• запуск программного обеспечения (например, "oracle")
• конкретный набор файлов данных
• конкретный логин или схема

Скорее всего, Джоэл имеет в виду один из нижних слоев. В данном случае это просто вопрос управления конфигурацией программного обеспечения... например, вам не нужно исправлять 1000 программных серверов, чтобы исправить ошибку безопасности.

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