首先是一个小背景：
我会说我有很好的SQL服务器经验，但我是开发人员，而不是DBA。我目前的任务是改进数据库的性能，数据库是在非常依赖视图的情况下构建的。该应用程序充满了内联sql，使用Tuning Advisor只会建议一些缺失的索引，这看起来很合理。
我认为重新设计数据库设计，以便这些特定视图（大量CASE WHENS）创建的数据会被保留，因为硬数据在预算和时间尺度方面的工作量太大。完全重写这些巨大的观点以及依赖于它们的所有代码似乎都是不可能的。
我建议的解决方案：
测试表明，如果我使用视图数据执行SELECT INTO以将其保留在永久表中，然后使用此表替换对视图的引用，查询时间将降低到使用视图时的44％
由于数据在一夜之间被蜘蛛进程刷新，我想我可以每天删除并重新创建此表，然后对查询进行微小修改以使用此视图。
具有良好DBA经验的人能否就这是否是一个好的/ *＆amp; !!给我一个意见！可怕的想法。如果是后者，是否有更好的方法来解决这个问题？
感谢。
答案 0 :(得分：2)
你说：“...重新设计数据库设计，以便这些特定视图创建的数据被保留，因为硬数据太多，因为预算和时间尺度都在这里。”然而这正是你提出要做的事情。只是你自己使用视图而不是将代码作为函数或存储过程。
无论如何，我的意见是，如果你投入一点精力来使这个强大（即你确保如果蜘蛛运行，持久化的数据总是得到刷新，你永远不会在结束之前运行select-into spidering）你的解决方案没问题。
我担心的是，这是一个黑客 - 无论多么精彩 - 所以无论谁继承你的解决方案，都会发现很难理解为什么以及如何。看看你是否可以通过评论或单独的文件提供一个好的解释。