Гость
Целевая тема:
Создать новую тему:
Автор:
Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / FK between diffrent Servers? / 12 сообщений из 12, страница 1 из 1
24.06.2002, 18:10:13
    #32033681
Irina
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
FK between diffrent Servers?
IS it posible to create a Foreigner Key between 2 Servers...when the so called "PK table" is situated on the one server and the "FK-table" is on the another server?

PS: Sorry for non Russian Texs -have no coding:(
answer is good in every languages!!!:)

(tipo po russki):Vozmogno li sozdat^ FK megzdu dvuh baz dannyh, kogda odna tablica na odnom servake, a vtoraja na drugom? ThanX!
...
Рейтинг: 0 / 0
24.06.2002, 18:39:29
    #32033686
jimmers
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
FK between diffrent Servers?
Вообще-то MS SQL Server 2000 не поддерживает внешние ключи даже между базами одно сервера. Соответствующее сообщение: Cross-database foreign key references are not supported.
Думаю, что для серверов ситуация не лучше.

Удачи
...
Рейтинг: 0 / 0
24.06.2002, 19:19:56
    #32033689
Irina
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
FK between diffrent Servers?
:)
Mlin! A kak mogno oboiti?
Naprimer bylo predlogenije usat^ View...View delaetsa s udalennoi tablicy na nash server i uge na nashem servere soedinjaetsa s zavisimoi tablicei....Ne katit - ne daet sozdat^ FK s VIew:(

Glupo, konechno takie kluchi sozdavat^, no poka dokazat^ eto bossy ne mogu:))
...
Рейтинг: 0 / 0
24.06.2002, 19:57:23
    #32033692
Слон
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
FK between diffrent Servers?
Это не будет называться Foreign Key. Это trigger-based referential integrity. То есть на каждой таблице создается триггер, который проверяет наличие записи в другой при удалении, вставке или update.

-- Слон
...
Рейтинг: 0 / 0
24.06.2002, 21:01:39
    #32033699
Irina
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
FK between diffrent Servers?
OK!
Lets image situation...
For to split one database into several servers, we place separate data for different users on separate servers...Only one problem -what to do with Login/Password data tables? Leave them in one server and every time start the triggers when user change something? Or there is more beautiful decision?
In BOL there is something about Designing Partitions...:) Don’t work in practice:) I only feel that the problem is in a bad design from the beginning:(...
...
Рейтинг: 0 / 0
24.06.2002, 21:32:02
    #32033702
Слон
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
FK between diffrent Servers?
На самом деле я такую проблему решаю таким образом. Конечно это работает только для не сильно транзакционных таблиц - для так называемых словарей.

Создается отдельная база данных, в которой хранится информация о - названии master table, ее местонахождении, и о том, в какие базы данных и на каких серверах распространять данные.

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

Несколько громоздко описано, но в деле работает на ура. Время от времени робот проверяет на предмет того, а не надо ли обновить процедуры повсюду.

Внутри же любой другой базы - подписчика Foreign Key идет на локальную таблицу - зеркало с сохранением Referential Integrity.

Чем-то напоминает репликацию, но конечно не совсем полностью.

--- Слон
...
Рейтинг: 0 / 0
24.06.2002, 21:41:15
    #32033705
Alexander_Chepack
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
FK between diffrent Servers?
А merge репликация отцам российской демократии не поможет? У меня именно так все справочные данные тиражируются - все работает.
...
Рейтинг: 0 / 0
24.06.2002, 22:39:19
    #32033707
Слон
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
FK between diffrent Servers?
Когда речь идет о простой синхронизации - конечно - репликация - прекрасный механизм, тем более, что ничего особенно писать не надо. Но любая репликация - асинхронна. То есть происходит удаление записи в одной базе данных и если в локальной базе на эту запись никто не ссылается, то ошибки не возникает. Ошибка пожалуй возникнет во время синхронизации, но это будет невидно для процесса, который удалял запись.

Вопрос же в топике был поставлен именно о сохранении referential integrity, а не о тиражировании.

Так что наверное отцам российской демократии репликация поможет, а нам, скромным буржуазным труженикам - везде приходится искать нетривиальные пути :)

-- Слон
...
Рейтинг: 0 / 0
24.06.2002, 22:51:21
    #32033708
Alexander_Chepack
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
FK between diffrent Servers?
Ну, откровенно говоря, триггеры в таком случае тоже не помогут - это ж надо на N серверах проверить при удалении нету ли там ссылок на запись - процесс довольно сложный и медленный - по правильному данные на всех серверах блокировать надо на время проверки.
...
Рейтинг: 0 / 0
24.06.2002, 23:03:09
    #32033709
Слон
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
FK between diffrent Servers?
Я же говорил, что это хорошо работает для справочников, которые на интенсивно обновляются. На самом деле, конечно все только кажется таким страшным. Когда процесс создания стандартных триггеров автоматизирован - все просто. Процесс изменения тоже достаточно быстр. Кстати - триггеры включаются только на удаление и вставку - во все остальное время - они молчат.

Конечно, если таблицу модифицируют сотни пользователей 24/7, то эта схема неприемлема.

-- Слон
...
Рейтинг: 0 / 0
26.06.2002, 17:14:16
    #32034018
Irina
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
FK between diffrent Servers?
2 Slon
OK, we created the server, we have 2 kind of data - Master data and Filials data. In practice - it is every time so, that every filial create some COLATIONS with Master tables copy.(ta samaja nemnogo pereimenovanaja tablica kak znachitsa u vas).
Replicatio in this case have crash, cause it is imposible to DELETE or UPDATE anythin in the table, which have dependencies...

From the other side - there is no way to controll the errors of replication inside of transactiojn...or is it?????
...
Рейтинг: 0 / 0
27.06.2002, 00:59:14
    #32034073
Слон
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
FK between diffrent Servers?
Ирина,

Предположим у вас есть схема:

Master SQL Server Name: MASTER_SRV
Filial SQL Server Name: FILIAL_SRV

Оба сервера имеют друг друга зарегистрированными как linked servers с достаточным набором прав на доступ друг к другу.

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
 /* Code to be executed on the MASTER_SRV */ 
USE [MasterDB]
GO
CREATE TABLE [dbo].[CompanyMaster]
(
     [CompanyID] [int] NOT NULL IDENTITY( 1 ,  1 ) PRIMARY KEY CLUSTERED,
     [CompanyName] [varchar] ( 128 ) NOT NULL,
     [Address1] [varchar] ( 50 ) NULL,
.....
) ON [PRIMARY]
GO

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
 /* Code to be executed on the FILIAL_SRV */ 
USE FilialDB
GO
CREATE TABLE [dbo].[CompanyMaster_x]
(
     [CompanyID] [int] NOT NULL PRIMARY KEY CLUSTERED
) ON [PRIMARY]
GO
DENY UPDATE, INSERT, DELETE ON [dbo].[CompanyMaster_x] TO PUBLIC
 /* In fact no one should be able to update this table... Trigger solution may work here as well. It's up to developer to enforce tighter rules. */ 
GO
GRANT INSERT, DELETE ON [dbo].[CompanyMaster_x] TO [MASTER_SRV_USER]
 /* [MASTER_SRV_USER] is the name of the user account under which all requests from [MASTER_SRV] are coming over to the [FILIAL_SRV] */ 
GO
CREATE VIEW [dbo].[CompanyMaster]
AS
     SELECT 
          [CompanyID] +  0  AS [CompanyID],
          [CompanyName],
          [Address1],
          .....
     FROM [MASTER_SRV].[MasterDB].[dbo].[CompanyMaster]
GO
CREATE TRIGGER [trg_BEFORE_INSERT_CompanyMaster] ON [dbo].[CompanyMaster]
INSTEAD OF INSERT
AS
     INSERT [MASTER_SRV].[MasterDB].[dbo].[CompanyMaster]
          ([CompanyName], [Address1], ....)
     SELECT [CompanyName], [Address1], .... FROM INSERTED
GO
CREATE TRIGGER [trg_BEFORE_UPDATE_CompanyMaster] ON [dbo].[CompanyMaster]
INSTEAD OF UPDATE
AS
     UPDATE cm 
     SET 
          cm.[CompanyName] = cmx.[CompanyName],
          cm.[Address1] = cmx.[Address1]
          ......
     FROM [MASTER_SRV].[MasterDB].[dbo].[CompanyMaster] cm
          INNER JOIN INSERTED cmx
               ON cm.[CompanyID] = cmx.[CompanyID]
GO
CREATE TRIGGER [trg_BEFORE_DELETE_CompanyMaster] ON [dbo].[CompanyMaster]
INSTEAD OF DELETE
AS
     DELETE FROM cm 
     FROM [MASTER_SRV].[MasterDB].[dbo].[CompanyMaster] cm
          INNER JOIN DELETED cmx
               ON cm.[CompanyID] = cmx.[CompanyID]
GO

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
 /* Code to be executed on the MASTER_SRV */ 
USE MasterDB
GO
CREATE TRIGGER [trg_INSERT_CompanyMaster] ON [dbo].[CompanyMaster]
FOR INSERT
AS
     INSERT [FILIAL_SRV].[FilialDB].[dbo].[CompanyMaster_x]
          ([CompanID])
     SELECT [CompanyID]
     FROM INSERTED
     IF @@ERROR <>  0 
     BEGIN
          ROLLBACK TRAN
          RETURN
     END

 /* Insert code here to support another replication targets. Use an example above */ 
GO
CREATE TRIGGER [trg_DELETE_CompanyMaster] ON [dbo].[CompanyMaster]
FOR DELETE
AS
     DELETE FROM cm 
     FROM [FILIAL_SRV].[FilialDB].[dbo].[CompanyMaster_x] cm
          INNER JOIN DELETED cmx
               ON cm.[CompanyID] = cmx.[CompanyID]
     IF @@ERROR <>  0 
     BEGIN
          ROLLBACK TRAN
          RETURN
     END
 /* Insert code here to support another replication targets. Use an example above */ 
GO



Что-то вроде такого должно получиться. Если будут ошибки по синтаксису, я не виноват. Набросал пример в рабочее время в перерывах между митингами.

-- Слон
...
Рейтинг: 0 / 0
Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / FK between diffrent Servers? / 12 сообщений из 12, страница 1 из 1
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]