Единственная проблема заключается в том, что на самом деле нет удобного способа обеспечить эти отношения. Вы можете использовать множество триггеров или сохранить основную таблицу в каждой базе данных экземпляра и просто представить все из них как метаданные ведущему, возможно, используя представление.
Я думаю, что самый большой недостаток связан с сохранением точности и синхронизации данных, по крайней мере, в трех сценариях, которые находятся на грани моей головы (все это может быть проблемой, даже если вы используете триггеры):
- неправильно скоординированные транзакции между базами данных - например, одна транзакция добавляет новую строку в мастер, передает идентификатор другой транзакции, а затем первая транзакция откатывается.
- восстановление после единственного сбоя базы данных - сбой базы данных, вы должны восстановить ее до момента времени, который мог быть до завершения других успешных транзакций в других базах данных. Это может означать, что если база данных экземпляра должна вернуться к более раннему времени, то в ней отсутствуют строки, ожидаемые мастером; если мастер должен вернуться, возможно, что все базы данных экземпляра будут иметь значения, которые не существуют в мастере.
- целостность резервных копий в целом - если вам необходимо аварийное восстановление, вам будет сложно поддерживать полную и транзакционную целостность всех резервных копий журналов на определенный момент времени. Снимки файловой системы не помогают в этом, и даже группы доступности не гарантируют согласованность транзакций между базами данных для баз данных в одной группе доступности. Если у вас возникла авария и вам необходимо восстановить ваши базы данных в новой системе, нет никакого способа убедиться, что они будут согласованы с точки зрения транзакций.
Несмотря на это, я всегда был и всегда буду сторонником разделения арендаторов на их собственные базы данных, и я признаю, что с центральной базой данных связан риск, но это необходимо.
(Кроме того, вы должны использовать имена для своих баз данных, отличных от master / instance. master
В SQL Server определенно имеет явное значение, и даже чтение моих собственных слов выше может быть неоднозначным. То же самое для instance
. В прошлой жизни я запускал несколько Система арендаторов и мы назвали центральную базу данных Control
и базы данных арендаторов, ну ,. Tenants
)