【问题标题】:Transaction based table edits基于事务的表编辑
【发布时间】:2012-09-12 21:55:18
【问题描述】:

我的任务是编写一个 Java 进程来将一些信息从旧的 as400 系统移动到我们新的 SQL Server 2008 安装。因为信息是在 as400 系统上管理的,所以这需要是一个“按需”解决方案(即有人每天启动一到两次,它应该使用最新版本的数据填充 SQL Server)。这是一组非常频繁使用的数据,所以我认为使用事务来清除表并重建它是一个好主意。该事务应防止任何人通过在我的过程中途请求数据而意外拾取不完整的列表。这是处理这种情况的正确方法吗?

如果需要进一步解释:

我是团队中的新开发人员之一,而资深开发人员之一正试图坚持我们执行“内存中替换”流程。他想更新两个表中存在的每条记录,插入不存在的新记录,然后删除不再存在的旧记录。我不相信这是一个好主意,特别是因为在这个过程中途的任何请求都会返回一个混杂的数据。我只是想知道我应该从技术角度多强烈地反击。

【问题讨论】:

  • 过程中途的任何请求都将返回一个混杂的数据。如果您将加载过程放在事务中,则不会
  • 你能再解释一下吗?
  • 我对 Java 了解不多,但任何数据访问库都允许您在单个事务中发出多个 DML 语句。在事务期间,通常不允许其他请求查看未提交的更改。有关 JDBC 示例,请参阅 Using Transactions

标签: database sql-server-2008


【解决方案1】:

根据填充所需的时间,如果表被锁定并且他们无法访问,从用户的角度来看,您可能无法获得可接受的性能。

考虑试试这个(假设您没有子表)。创建两个具有相同结构的表。 创建从 table1 中选择所有列的视图。让您的进程填充 table2。完成后,将视图更改为引用 table2(应该需要几秒钟或几毫秒)。让所有应用程序代码引用视图而不是基表。当您这样做时,您可以构建一个大表并重建索引,而用户甚至永远不会知道它,因为从他们的角度来看,唯一的延迟将是重新创建视图所需的时间。当重新创建表需要几分钟甚至几小时时,我们已经这样做了几次。当然,下次您反转它并填充表一然后将视图更改回来。

【讨论】:

  • 其实这不是一个坏主意。我得看看这会做多少工作。我不确定我们是否有足够的数据来证明这一点。 (
  • 动态更改视图的定义是否类似于动态创建视图? This was cautioned 反对。说真的,你知道如果交易正在进行并且视图发生变化会发生什么吗?
  • 这适用于在您更改视图时不会有针对它们的事务的表,因为它们仅通过您控制的导入来填充。其他用户不得更改数据集成表。
猜你喜欢
  • 2011-03-05
  • 1970-01-01
  • 2010-12-23
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2013-02-08
  • 2017-08-29
  • 1970-01-01
相关资源
最近更新 更多