SQL Server: отдельные схемы или отдельные базы данных - PullRequest
3 голосов
/ 20 июня 2011

У нас есть два продукта, которые внедряются на сайтах клиентов, один из которых требует присутствия другого. Я реализовал отдельную схему в той же базе данных, что и основной продукт для объектов базы данных, необходимых для дополнения. Поскольку дополнение может теоретически стать дополнением к будущим продуктам (хотя ни один из них в настоящее время не планируется), я пересматриваю это решение. В настоящее время мы используем 2005 год, но планируем перейти на 2008 R2 или Denali через год или около того.

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

Есть ли причины избегать разделения двух схем на отдельные базы данных, если они всегда будут в одном экземпляре SQL Server?

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

Ответы [ 4 ]

3 голосов
/ 20 июня 2011

Вы не получите согласованность транзакций, если они находятся в двух отдельных базах данных. В зависимости от вашего механизма HA / DR базы данных могут быть не синхронизированы. Например, при использовании зеркального отображения базы данных одна база данных может значительно опережать другую с точки зрения применяемых журналов транзакций. Одна база данных может быть текущей до 10 утра на зеркале, но другая база данных может быть текущей только до 9:55 утра. В случае сбоя, бум, ваши две базы данных не синхронизируются.

1 голос
/ 21 июня 2011

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

0 голосов
/ 20 июня 2011

Вы должны (строго!) Проверить производительность приложения для своего приложения по обеим моделям (отдельной схеме и отдельной базе данных). Если одно окажется неприемлемым, переходите к другому. С очевидным сказанным, единственная действительно убедительная причина использовать одну форму поверх другой, связана с описанными вами «дополнительными» функциями. Если это может быть «надстройка» для нескольких разных систем, если вы хотите, чтобы один установленный надстройка использовался всеми установленными и поддерживаемыми «базовыми» приложениями, то вам бы очень хотелось, чтобы эта функциональность была инкапсулирована в его собственный экземпляр базы данных, так что он может быть доступен для всех / всех таких экземпляров.

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

0 голосов
/ 20 июня 2011

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

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

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

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

...