SQL 视图何时适用于 ASP.net MVC？

Question

我有一个名为 Protocol 的表，一个名为 Eligibility 的表，以及一个将两者映射在一起的 Protocol_Eligibilty 表（多对多关系）。如果我想在 Protocol 表中创建一个条目的完美副本，并在 Protocol_Eligibility 表中创建所有需要的映射，从性能的角度来看，使用 SQL 视图会有所帮助吗？ Protocol 大约有 1000 行，Eligibility 大约有 200 行，我希望每个 Protocol 映射到大约 10 Eligibility 行，每个 Eligibility 映射到 Protocol 中的 100 多行。

这是我对视图的处理方式：

var pel_original = (from pel in _documentDataModel.Protocol_Eligibility_View
                                where pel.pid == id
                                select pel);

Protocol_Eligibility newEligibility;

foreach (var pel_item in pel_original)
{

    newEligibility = new Protocol_Eligibility();

    newEligibility.Eligibility = (from pel in _documentDataModel.Eligibility
                                              where pel.ID == pel_item.eid
                                              select pel).First();

    newEligibility.Protocol = newProtocol;

    newEligibility.ordering = pel_item.ordering;

    _documentDataModel.AddToProtocol_Eligibility(newEligibility);

}

这是没有视图的：

var pel_original = (from pel in _documentDataModel.Protocol_Eligibility
                                where pel.Protocol.ID == id
                                select pel);

Protocol_Eligibility newEligibility;

foreach (var pel_item in pel_original)
{
    pel_item.EligibilityReference.Load();

    newEligibility = new Protocol_Eligibility();

    newEligibility.Eligibility = pel_item.Eligibility;

    newEligibility.Protocol = newProtocol;

    newEligibility.ordering = pel_item.ordering;

    _documentDataModel.AddToProtocol_Eligibility(newEligibility);

}

Answer 1

视图在 SQL Server 中没有性能影响。从视图中选择或从视图所基于的查询中进行选择，在各个方面相同。事实上，在构建查询计划时，视图已扩展到其定义中。

视图影响性能的唯一情况是存在索引视图，或在Oracle 中调用的实体化视图。但是索引视图的性能提升来自 index，而不是来自视图。事实上，从 any 查询中选择可以利用索引视图的查询将利用它，而不仅仅是从视图中选择。非企业版（标准版、快捷版）不考虑索引视图。

事实上，无论何时讨论 SQL Server 或任何关系数据库的性能，问题从来都不是如何设计查询，而是如何设计 schema。适当的聚集索引和适当的非聚集索引，这将提供性能，而不是视图。

我在响应中没有提到 linq、MVC 和 ASP 的事实仅仅是因为在讨论 SQL 性能时它们是完全不相关的。

Answer 2

由于行数如此之少，性能优化不会对现代台式机或服务器硬件产生任何明显的影响。除非这是一个资源极其有限的嵌入式系统，否则最好将开发时间分配到其他地方。