2013-05-28 46 views
1

我需要更改三个表中的数据(更新一些现有的行,添加一些新的,删除一些旧的)。我需要它在一瞬间完成。问题是数据需要手动更改,可能需要一些时间才能完成。所以我打算使用beta服务器来进行更改。问题是:如何用另一个数据库的数据更新生产服务器?从另一个数据库更新表

我的解决办法:从公测服务器转储数据和生产恢复。
瑕疵:我将不得不首先删除生产中的所有数据,并且由于外键(我可以先关闭键,但有没有办法避免它)?

我找到了similar question,其中一个答案建议使用dblink命令。我想我可以写更新声明,但这似乎仍然有点矫枉过正。

编辑(补充说明):
有生产服务器(姑且称之为Production),并有开发服务器(姑且称之为Beta)。所以我需要在生产中更改一些数据(3个互连的表,它们也可以从DB中的其他表引用)。准确地说 - 这些表格包含学习计划 - 主题,主题组和子主题。有些引用这些元素的寄存器。但是我需要在一瞬间完成这些更改(意思是:通过SQL脚本)。为了做到这一点,我将使用Beta服务器 - 它包含生产数据库的副本(在某个时刻完成,不需要实时同步)。因此,我将在Beta服务器上的3个表中更新数据,并且需要将这些数据移至生产。

+0

能否请您详细解释问题?例如:你想改变的表的数量。您想要包含的数据存在于同一个表结构中的另一个数据库中吗?请详细说明。 – RGV

+0

我已经更新了我的Q. – Wiktor

+0

这个问题是关于(i)使单元格中的值更改的过程变得容易的工具(例如,一个可以显示逻辑分组中的单元格的上端和下端该表或应用筛选器以找到需要更改的行)'OR'(ii)在对其客户的副本进行更改后同步prod数据库的方法? – Stoleg

回答

1

您的策略取决于您识别独一无二的行的能力。

如果可以创建一个唯一的密钥每一行(不是必要的,你已经创建了一个UNIQUE约束),则:

  1. 所有数据复制到Beta。通过做出的更改标记为受影响的行或创建NEWUPDATEdDELETEd表。
  2. 仅将标记行复制到Production
  3. 应用更改。如果你能发现Production行自你的副本以来已经发生了变化 - 决定处理它。

    插入Pro_Table SELECT * FROM New_Rows_Table

    UPDATE Prod_Table 集Prod_Col_1 = Upd_tbl_c1, Prod_Col_2 = Upd_tbl_c2, ..., Prod_Col_N = Upd_tbl_cN 从Update_Table 其中Prod_Table.RowKey = Update_Table.RowKey

    DELETE FROM Prod_Table FROM Delete_Table 其中Prod_Table.RowKey = Delete_Table。RowKey

这是SQL Server代码风格,但您可以获取相关想法并进行必要的更改。例如,Delete_Table应该只有RowKey列。

如果不能创建一个唯一的密钥。你有一些选择:

号码所有的行通过添加新柱,并用ROW_NUMBER填充它()函数。

OR

锁定你的数据库中的任何改变或不适用他们并单独存放。在您的更改升级到Production后,应用已更改的更改。

OR

捕获所有INSERT, '更新' 和Production数据库使用触发器DELETE语句。您需要插入,因为它们可能会受到稍后的更新和删除的影响。

当对Beta复制行进行更改时,您可以在Beta上手动更改为单独的表格。

完成更改后,请查看Production中的捕获数据,并决定如何将它们应用于已更改并从Beta复制的行。

对于使用外键的avioid问题,请使用不同的名称复制/导入更新的表。重命名原始表格,然后重新命名。放下原始表格。这样您就不会删除任何数据,并且所有外键都会一直执行。

+0

感谢您的回答,但它似乎仍然是一个复杂的解决方案...我正在寻找一些简单的解决方案或信息,没有这样的:) – Wiktor

+0

你会如何定义“简单”?你也可以从Access数据库创建一个远程连接,并直接编辑生产... – Stoleg

+0

“简单”我的意思是解决方案,它的复杂性比按行手动处理要小10倍) – Wiktor

2

当我们保持生产数据库我们通常做的是写一个SQL脚本做更新,删除,国家经贸委。我们用Beta来测试它,它应该是Production的一个不错的副本。

当我们确定它做的是正确的事情时,我们会针对生产运行它。

我们不要将数据从非生产环境转移到生产环境中。生产是数据的主人,并且获取副本,执行更新,然后尝试重新加载它是困难和可怕的(正如您已经想到的那样)。

这种机制允许我们以确保测试脚本运行,这将使已知的更新投入生产。它消除了人为错误,因为当您连接到生产时,所有必须正确设置的都是脚本的名称。

+0

我同意这是一个很好的做事方式,但我认为这里的情况有些不同,导致需要完成的更改必须由客户端完成 - 我不能期望客户端能够编写SQL脚本:) – Wiktor

+0

你应该马上说它是**不是你**,谁会做出改变! – Stoleg

+0

是的,我们的情况通常也是这样 - 在许多客户中,我们无法获得生产。我们根据我们有权访问的测试系统中的数据编写脚本,以及我们了解这些数据与生产数据的关系。然后,我们将脚本提供给客户,并说“运行此”。有时需要关于如何运行脚本的说明,但它可以降低输入错误的风险。 – GregHNZ

相关问题