Когда в ASP.net MVC уместны представления SQL?

Question

У меня есть таблица с именем Protocol, таблица с именем Eligibility и таблица Protocol_Eligibilty, которая отображает их вместе (отношение многие ко многим). Если бы я хотел сделать идеальную копию записи в таблице протокола и создать все необходимые отображения в таблице Protocol_Eligibility, было бы полезным использование представления SQL с точки зрения производительности? Протокол будет иметь около 1000 строк, Eligibility будет иметь около 200, и я ожидаю, что каждый протокол будет отображаться примерно в 10 строк Eligibility, а каждый Eligibility будет отображаться в более 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 , а не из представления. Фактически, выбор из любого запроса, который может использовать индексированное представление, будет использовать его, а не только выбор из представления. Индексированные представления не рассматриваются в выпусках не Enterprise (Standard, Express).

На самом деле, когда речь заходит о производительности в SQL Server или любой реляционной базе данных, вопрос никогда не заключается в том, как разрабатывать запросы, вопрос всегда в том, как проектировать схему . Правильный кластеризованный индекс и правильные некластеризованные индексы - вот что даст производительность, а не просмотры.

Тот факт, что я не упоминаю в ответе linq, MVC или ASP, объясняется просто тем, что совершенно не имеет значения при обсуждении производительности SQL.

Answer 2

При малом количестве строк оптимизация производительности не будет иметь существенного значения на современном настольном или серверном оборудовании. Если это не встроенная система с чрезвычайно ограниченными ресурсами, вам лучше распределить время разработки в другом месте.