我有一个数据库表,它会定期用新数据完全重新填充。然后需要将此数据推送到相应的实时数据库表中,覆盖之前的实时数据。
随着表大小的增加,将数据推送到活动表中所需的时间也会增加,并且应用程序看起来就像丢失的数据。
一种解决方案是将新数据推送到 live_temp 表中,然后在该表上运行 SQL RENAME 命令以将其重命名为实时表。重命名通常在亚秒时间内运行。这是解决这个问题的“正确”方法吗?
是否有其他策略或工具来解决这个问题?谢谢。
我有一个数据库表,它会定期用新数据完全重新填充。然后需要将此数据推送到相应的实时数据库表中,覆盖之前的实时数据。
随着表大小的增加,将数据推送到活动表中所需的时间也会增加,并且应用程序看起来就像丢失的数据。
一种解决方案是将新数据推送到 live_temp 表中,然后在该表上运行 SQL RENAME 命令以将其重命名为实时表。重命名通常在亚秒时间内运行。这是解决这个问题的“正确”方法吗?
是否有其他策略或工具来解决这个问题?谢谢。
创建一个重复的表 - 精确的副本。
创建一个新表,它只跟踪“最新”表。MostCurrent (table) id (column) - 保存保存“最新”数据的表的名称。
重新填充时,填充旧表并更新 MostCurrent.id 以反映此表。
现在,在您将数据绑定到页面的应用程序中,绑定最新的表。
我不喜欢以这种方式弄乱模式对象——它会使查询优化器感到困惑,而且我不知道执行重命名时正在进行的任何事务会发生什么。
我更喜欢在表中添加一个版本列,并有一个单独的表来保存当前版本。
这样,客户端代码就变成了
select *
from myTable t,
myTable_currentVersion tcv
where t.versionID = tcv.CurrentVersion
这也保留了历史——这可能有用也可能没用;如果在设置 CurrentVersion 列后没有删除旧记录。
只将更改推送到实时数据库表是否合适?对于我使用过的大多数应用程序,变化很小。您应该能够在单个事务中应用所有更改。提交事务将使它们可见,而不会在表上中断。
如果数据确实完全改变了,那么您可以配置数据库,以便您可以在单个事务中替换所有数据。