Как управлять общими или настраиваемыми таблицами

Question

У нас есть много клиентов, использующих наше приложение, и каждый из них имеет свою собственную, идентично структурированную базу данных на нашем MS SQL Server. У нас также есть центральная база данных для информации, которая является инвариантной и поэтому распространена среди всех клиентов, таких как база данных USPS ZIP Code. Каждая клиентская база имеет вид этих таблиц, например:

create view V_ZIPCode as 
select ID, ZIP, City, State 
from SharedDB..ZIPCode 

клиенты не имеют права на изменение данных в SharedDB.

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

Так что мне интересно, как лучше всего реализовать эту ситуацию.

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

Еще одна идея у меня была в том, чтобы создать идентичные таблицы в SharedDB и клиентской БД, а затем создать представление о клиенте БД так:

create view V_MyTable as 
select ID, Description, convert(bit, 0) IsClientData from SharedDB..MyTable 
union 
select ID, Description, 1 from MyTable 

Для того, чтобы предотвратить ID дублирования, я мог засеять личность значение на клиентских таблицах на очень большом количестве, таком как 1,000,000 (путь больше, чем я когда-либо использовал в центральной базе данных, это довольно стабильные значения поиска); Я не уверен, что мне понадобится это поле IsClientData, но это небольшая деталь. Клиент сможет выбирать все, что захочет, используя представление, но они смогут изменять данные в таблице только в своей собственной базе данных.

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

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

Если это имеет значение, бизнес-уровень приложения написан на C# с использованием Linq-to-Sql.

Answer 1

Запрет (как вы сказали), распространяющие данные по всей системе, кажется мне довольно твердым.

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

-- In SharedDB 
CREATE TABLE CentralTable 
(
    Id    int   not null identity(1000000, 1) 
    ,OwningClientDB sysname  null 
    ,YourDataHere varchar(100) not null 
    -- Toss in stuff like who added it, when it was added, etc.) 
) 

Как уже упоминалось, все общие данные добавляется через SET IDENTITY_INSERT CentralTable ON со значениями Id под 1,000,000, и с Обладание ClientDB нулевой. Затем в каждом клиентском БД:

-- In client DB 
CREATE VIEW vCentralTable (Id, OwningClientDB, YourDataHere, etc.) as 
select Id, OwningClientDB, YourDataHere, etc. 
    from SharedDB.dbo.CentralTable 
    where isnull(OwningClientDB, db_name()) = db_name() 

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