两个具有不同名称且具有不同列名称的表之间的复制。是否可以创建这样的复制

发布于 2024-11-01 20:09:39 字数 468 浏览 7 评论 0原文

我有一个要求,在两个具有不同名称且具有不同列名称的表之间创建复制。是否有可能创建这样的复制。

server A                                            server B
----------                                          ----------
Table : Test                                        Table : SUBS
--------------                                      ---------------
columns A,B,C                                       Columns D,E,F,G,H

我想配置复制,以便将 A 列数据复制到 D 列,将 B 列数据复制到 E 列,将 C 列数据复制到 F 列

I have a requirement where i have create replication between two tables with different names and which have different column names. Is it possible to create such replication.

server A                                            server B
----------                                          ----------
Table : Test                                        Table : SUBS
--------------                                      ---------------
columns A,B,C                                       Columns D,E,F,G,H

I want to configure replication so that column A data is replicated to column D, column B data is replicated to column E, column C data is replicated to column F

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

挽你眉间 2024-11-08 20:09:39

显然,答案是:“定义文章时,必须将 @vertical_partition 参数设置为 true,然后使用 sp_articlecolumn 添加所需的列。 ”

不过,我不得不问你为什么要这样做。在我看来,复制并不是在不同数据库之间移动数据的通用工具,而是用于保持两个相同数据库同步的通用工具。

其他集思广益的想法:

  • 您可以创建一个与目标表匹配的新源表,并使用触发器来保持源表同步。
  • 将源表原封不动地推送到目标数据库,并在目标数据库中执行 MERGE。
  • 在这里,复制可能并不是真正正确的解决方案。业务规则和规则是什么?要求这样做的要求是什么?您考虑过使用 SSIS 吗?
  • 如果需要两个表始终精确同步,那么源表的更改渠道是什么——应用程序?听起来您的应用程序需要一个新的抽象级别,一个知道如何同时写入两个源的数据写入层。

尝试在两个不同数据库之间保持数据同步可能是一个问题。可能存在各种微妙的问题,包括竞争条件、缺乏分布式事务(影响一致性和对故障的响应)、为处理没有分布式事务而创建的解决方法的问题等等。您是否可以创建一个链接服务器和一些视图,实际上使一个数据库中的数据可以从另一个数据库中实时访问?

请告诉我们更多有关您的要求以及为什么需要这样做的信息。

更新

如果您要采用手动更新路线,请注意您无法批量应用某个时间段的插入、更新和删除操作。您必须按顺序一次应用它们。如果您使用的是当前状态而不是中间数据操作,那么您可以一次执行所有行。我将向您展示 MERGE 示例,而不是历史回放示例。

BEGIN TRAN;

DELETE D
FROM LinkedServer.dbo.Dest D WITH (TABLOCKX, HOLDLOCK)
WHERE
   NOT EXISTS (
      SELECT *
      FROM Source S
      WHERE D.Key = S.Key
   );

UPDATE D
SET
   D.Col1 = S.Col4,
   D.Col2 = S.Col5,
   D.Col3 = S.Col6,
   D.Col4 = S.Col7,
FROM
   LinkedServer.dbo.Dest D
   INNER JOIN Source S ON D.Key = S.Key
WHERE
   D.Col1 <> S.Col4
   OR EXISTS (
      SELECT D.Col2, D.Col4
      EXCEPT
      SELECT S.Col3, S.Col6
   ); -- or some other way to handle comparison of nullable columns

INSERT LinkedServer.dbo.Dest (Col1, Col2, Col3)
SELECT Col4, Col5, Col6
FROM Source S WITH (TABLOCK, HOLDLOCK)
WHERE
   NOT EXISTS (
      SELECT *
      FROM LinkedServer.dbo.Dest D
      WHERE S.Key = D.Key
   );

COMMIT TRAN;

您可能会发现推送整个表并在目标服务器上执行合并操作会更好。

如果您想要获得一致的时间点快照,我在第一个查询中添加的锁定提示非常重要。如果您不关心这一点,请去掉锁定提示。

如果您发现链接服务器上的更新速度很慢,请将整个表整体推送到远程服务器上的临时临时表,并完全在远程服务器上的脚本中执行 MERGE。

Apparently, the answer is: "When you define the article, you'll have to set the @vertical_partition parameter to true and then add the columns that you want with sp_articlecolumn."

However, I have to ask why you're doing this. Replication in my mind isn't a general tool for moving data around between unlike databases but for keeping two identical databases in sync.

Other brainstorm ideas:

  • You could create a new source table that does match the destination table, and use a trigger to keep the source table synchronized.
  • Push the source table intact to the destination and do the MERGE in the destination database.
  • Replication may not really be the right solution, here. What are the business rules & requirements that are calling for this to be done? Have you considered using SSIS?
  • If there IS a need for the two tables to be in exact synchronization all the time, then what is the channel of changes to the source table--an application? It almost sounds like your application needs a new level of abstraction, a data write layer that knows how to write to two sources at the same time.

Trying to keep data synchronized between two different databases can be a problem. There can be all sorts of subtle problems with race conditions, lack of distributed transactions (affecting consistency and response to failures), problems with the workarounds created to deal with not having distributed transactions, and so on and so forth. Can you instead create a linked server and some views that actually make the data in one database real-time accessed from the other?

Please tell us more about your requirements and why you need to do this.

Update

If you're going the manual update route note that you can't apply a time period's insert, update, and delete operations en masse. You have to apply them one at a time, in order. If you are instead working with current state rather than intermediate data operations, then you can do all rows at once. I will show you the MERGE example, not the history-playback one.

BEGIN TRAN;

DELETE D
FROM LinkedServer.dbo.Dest D WITH (TABLOCKX, HOLDLOCK)
WHERE
   NOT EXISTS (
      SELECT *
      FROM Source S
      WHERE D.Key = S.Key
   );

UPDATE D
SET
   D.Col1 = S.Col4,
   D.Col2 = S.Col5,
   D.Col3 = S.Col6,
   D.Col4 = S.Col7,
FROM
   LinkedServer.dbo.Dest D
   INNER JOIN Source S ON D.Key = S.Key
WHERE
   D.Col1 <> S.Col4
   OR EXISTS (
      SELECT D.Col2, D.Col4
      EXCEPT
      SELECT S.Col3, S.Col6
   ); -- or some other way to handle comparison of nullable columns

INSERT LinkedServer.dbo.Dest (Col1, Col2, Col3)
SELECT Col4, Col5, Col6
FROM Source S WITH (TABLOCK, HOLDLOCK)
WHERE
   NOT EXISTS (
      SELECT *
      FROM LinkedServer.dbo.Dest D
      WHERE S.Key = D.Key
   );

COMMIT TRAN;

You may find it better to push the whole table and do the merge operation on the destination server.

The lock hints I put in on the first query are important if you're going to have a consistent point-in-time snapshot. If you don't care about that, then take the locking hints out.

If you find that updates across the linked server are slow, then push the entire table in one piece to a temporary staging table on the remote server, and do the MERGE in a script entirely on the remote server.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文