欢迎任何轶事或建议。
我们的应用程序通过视图使用 3rd 方供应商数据。业务部门要求我们绑定到先前版本视图的应用程序应该能够继续使用它们，而不必与每个更新的供应商版本的视图同步。应用程序“A”应该能够使用 v.1.1 的视图，而应用程序“B”使用 v.1.2 的视图，两者都与全局模式/命名空间中的相同表交互。
人们建议使用版本号命名视图，但这对于与视图的更新版本保持同步的应用程序来说似乎很麻烦。这个问题有更好的解决方案吗？也许将每个受支持的视图版本保留在它自己的架构中，并让视图从定义表和数据所在的全局架构中提取？
【问题讨论】：
标签： sql database oracle views versioning
如果您要维护一个视图层，您通常会通过将 v1.2 更改限制为向现有视图添加额外的列或添加额外的视图来保持版本之间的兼容性。不想升级的应用程序将继续使用现有视图的现有列，而想要升级的应用程序可以使用新视图。 Oracle 数据字典视图就是这种方法的一个很好的例子。在每个新版本中，都有数十个新视图为需要它的应用程序公开新功能。但是针对 Oracle 7 中的数据字典视图编写的脚本将很高兴针对 11.2 数据库运行（效率可能较低）。
这实际上与维护任何其他类型的 API 没有什么不同。当您发布 1.2 版本时，您通常不会取消现有的 API 调用或强制用户向 API 传递额外的参数。相反，您将旧 API 调用祖传到新版本中。当然，有时您可能不得不弃用 API 的某些部分并强制现有应用程序进行小幅升级。但这些比较少见，只需要应用程序更改代码以进行那个已弃用的调用——应用程序不需要完全升级到新的 v1.2 API。
【讨论】：
如果您使用的是 11gR2，则应该查看基于版本的重新定义。它几乎可以满足您的需求，除此之外还有很多其他功能。 Find out more.
【讨论】：
您可以选择使用视图的同义词从供应商那里抽象出视图的代码名称，这样您的应用就会使用特定的名称，而实际视图中的数据是从更改中提取的。 如果您想避免使用同义词，请从供应商的适当视图中选择创建您自己的视图，效果相同但没有同义词。
【讨论】：
您基本上列出了两个可行的选项：使用特定于版本的名称命名视图或使用特定于版本的架构。无论哪种方式，您都需要复制视图定义并为特定于版本的应用程序重新创建它。
假设您真的对维护视图的完整副本感兴趣，这应该不会太令人头疼。
【讨论】：