在我的工作场所,我们有单独的 Teradata 数据库来管理表和 View 。 “tables”数据库包含包含数据的表,而“views”数据库仅包含 View 。对两个数据库的访问是按角色管理的:“开发人员”有权限在“表”中创建表,在“ View ”中创建 View ; “消费者”对“ View ”数据库只有“读”访问权限。
随着时间的推移,一些 View 变得“糟糕”,因为它们引用的基表不再存在。这通常是由于开发人员在某些分析结束时删除了表而忘记删除相应的 View 而导致的。
问题:是否有一种“简单”的方法来识别不再与有效表关联的 View ?
我正在考虑编写一个测试脚本来对“views”数据库中的每个 View 执行select count(*)
;如果测试失败,我就会知道 View 有问题。我知道如何做到这一点(并且它会起作用),但我想我应该问是否有更好的方法。
最佳答案
我编写了一种可用于查找损坏 View 的方法 here 。通过使用存储过程、几个游标和 PREPARE
语句,您可以快速测试整个数据仓库中 View 的有效性。
最大的技巧是确定错误处理程序来记录错误。虽然我没有在我的网站上详细介绍错误处理程序,但如果您遇到困难,我可以向您发送一些伪代码以找到正确的路径。
关于teradata - 如何识别 "bad" View ?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/16545346/