Одна база данных для одного клиента или одна для всех

Question

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

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

Что вы, ребята, думаете об этом?

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

Мы считаем, что у нас может быть какая-то репликация базы данных, но как мы можем объединиться с другой схемой без потери данных?

Edit:

Допустим, у меня есть один сервер баз данных (SQL-01), и у меня есть 100 клиентов на этой базе данных. Как я могу сделать одного клиента для SQL-02 после изменения схемы, и после периода бета-тестирования я хочу, чтобы каждый из них был обновлен на SQL-01 с новой схемой и моим клиентом бета-тестирования SQL-01 до следующего бета-теста.

Answer 1

У вас почти всегда будет одна база данных для всех клиентов. Базы данных SQL предназначены для больших объемов данных. Фактически, они более эффективны при больших объемах данных, чем меньшие суммы (потому что при меньших количествах страницы будут частично заполняться).

Единственная причина, чтобы отделить различные клиент, когда проект требует:

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

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

Answer 2

Лучший способом с моей точки зрения является использование одной схемы и одну базы данных для всех клиентов => создать Datawarehouse и особенно схемы Star, если у вас есть много данных ...

Например: Вы может начать с создания таблицы с идентификатором клиента, имя, регион, city..Like это:

Если вы хотите иметь базу данных 100 вы можете использовать «ALTER SCHEMA» (с петлей):

ALTER SCHEMA TargetSchema TRANSFER SourceSchema.TableName; 

Answer 3

Хотя обновление может быть более болезненным, есть ряд требований, которые должны быть рассмотрены, прежде чем разместить все клиенты в один большой БД:

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

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

Резервные копии: вы можете сделать каждую резервную копию базы данных отдельно, если она находится в одной более крупной БД, тогда резервные копии каждого клиента смешиваются вместе. Если один клиент запрашивает откат к данной дате, вам необходимо заранее планировать, как это можно выполнить, не затрагивая других пользователей системы.

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

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

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