我正在处理数据库中的记录传输问题。我有一个TableA
,其中包含原始数据(最接近唯一标识符的是时间戳和我之前创建的IDENTITY (1,1)
)和TableB
,它是相同的数据但是使用存储过程处理,在某些情况下会根据存储过程的性质复制记录。我们正在处理的数据(因此拆分记录的ID相同,等等)。
用户希望每次“批量”将新数据从更新的文件插入TableA
后运行存储过程,因此该过程将类似于:
... > USER INSERTS INTO TableA > USER RUNS STORED PROCEDURE > PROCEDURES INSERTS INTO TableB > REPEAT
我的问题是,当运行存储过程时,它将在TableA
上运行x次,并且显然一遍又一遍地添加相同的数据并增加ID值,我正在考虑使用WHERE NOT EXISTS
但是再次运行后我没有唯一的ID程序。由于DB的大小,清洁TableB
和重新填充是不可靠的,同样我需要避免触发器。
什么是最干净和务实的方法?
这绝对不是一个完美的解决方案,但它是关于如何处理TableA
中datetimes
的数据的问题的答案,这个数据大于TableB
中的最新值。
通常在这里应用的模式将是用这样的方式构造处理TableA
数据的存储过程。
SET ISOLATION LEVEL REPEATABLE READ;
DECLARE @LastTimestamp DATETIME;
BEGIN TRY
BEGIN TRANSACTION
SELECT
@LastTimestamp = MAX(TimestampColumn)
FROM
TableB;
INSERT #StagingTable
<ColumnList>
SELECT
<ColumnList>
FROM
TableA
WHERE
TimestampColumn > @LastTimestamp;
<Stored procedure magic, performed on #StagingTable....>
INSERT TableB
<ColumnList>
SELECT
<ColumnList>
FROM
#StagingTable;
COMMIT TRANSACTION;
END TRY
BEGIN CATCH
ROLLBACK TRANSACTION;
<Other Error Handling>
END CATCH;
你可以做的任何事情,以确保INSERT
s进入TableA
有明确的交易宣布将有所帮助,但通过使用REPEATABLE READ
Isolation Level,你会得到一些保护,以免INSERT
s发生在一起。
您也可能值得花时间研究Change Tracking和Change Data Capture,看看其中一个是否可能为您提供一些帮助。