这不是您可能想像的异乎寻常的要求，但是解决方法根本不是一个好主意。

通过"交换"表，使依赖于数据库中表的每个对象无效

这是视图，过程，函数，任何SQL语句，内部联接转换表-一切。

除了将数据存储在两个表中（而不是在两个表中）所需的额外内存之外，所有这些都需要。 之一。 更不用说重命名表需要的完全阻止锁。
考虑一下：如果您的ODATA表交换程序无法获得此表的排他锁，那是怎么回事，例如，其中一个读取客户端/服务仍具有打开的游标？
你做什么工作？ 打电话给DBA？ 对于诸如"隐藏"数据之类的简单的尚不应该看到的数据？

一种更好的方法是使用在加载所有数据以允许访问后知道您知道的事实 到新加载的记录。

例如 您可以包含一种不断增加的" load-request-id"，并为您的用户提供对特定负载请求的访问权限。 那是例如 SAP BW数据加载和访问的工作方式。

因此，不，交换表的主意不应该成为一种选择。 在这一点上应该显而易见的是，解决方案设计（或体系结构，如果您如此倾向于）错过了处理数据可见性的要求。 交换表的这种思想后思想提出了关于农场动物和化妆品的谚语...

增加的内存需求来自于包含两个列表。 将价值字典加倍以跟踪唯一值。 如果仅添加另一条记录并且值已经在此之前发生，则额外的内存基本上只是指向该列字典的指针。 那就是列存储的基础知识。

一个很好的选择，不要低估锁带来的问题的规模。

关于"优雅"的解决方案...很高兴为此而工作 与您和您的团队一起-这样的事情就是我的谋生之计;-)

最后的谚语...确切的说法是" 将口红涂在猪上"。

干杯

Lars