ПРОИЗВОДИТЕЛЬНОСТЬ SQL SERVER: Что быстрее, хранимая процедура или представление?
Если вы используете кеширование для своих вкладок, то это решение, вероятно, лучше подходит, оно показывает загрузку AJAX, только если содержимое еще не на странице.
$(".tabs").tabs({
cache:true,
load: function (e, ui) {
$(ui.panel).find(".tab-loading").remove();
},
select: function (e, ui) {
var $panel = $(ui.panel);
if ($panel.is(":empty")) {
$panel.append("<div class='tab-loading'>Loading...</div>")
}
}
})
6 ответов
Хранимые процедуры (SP) и представления SQL - это разные «звери», о чем неоднократно говорилось в этом сообщении.
Если мы исключим некоторые [обычно незначительные, за исключением второстепенных случаев] соображения производительности, связанные с кэшированием плана запроса, временем, связанным с привязкой к хранимой процедуре и так далее, два подхода в целом эквивалентны с точки зрения производительности. Однако ...
Представление ограничено тем, что может быть выражено в одном операторе SELECT (ну, возможно, с CTE и некоторыми другими уловками), но в целом представление привязано к декларативным формам запросов. . С другой стороны, хранимая процедура может использовать различные конструкции процедурного типа (а также декларативные), и, как результат, с помощью SP, можно вручную разработать способ решения заданного запроса, который может быть более эффективным , чем то, что мог бы сделать оптимизатор запросов SQL-Server (на основе одного декларативного запроса). В этих случаях SP может быть намного быстрее (но будьте осторожны ... оптимизатор довольно умен, и не нужно много времени, чтобы сделать SP намного медленнее, чем эквивалентное представление.)
Помимо этих соображений производительности, SP более универсальны и допускают более широкий диапазон запросов и действий, чем просмотры.
This isn't really an answerable question in that an answer will hold true in all cases. However, as a general answer for an SQL Server specific implementaion...
In general, a Stored Procedure stands a good chance of being faster than a direct SQL statement because the server does all sorts of optimizations when a stored procedure is saves and executed the first time.
A view is essentially a saved SQL statement.
Therefore, I would say that in general, a stored procedure will be likely to be faster than a view IF the SQL statement for each is the same, and IF the SQL statement can benefit from optimizations. Otherwise, in general, they would be similar in performance.
Reference these links documentation supporting my answer.
http://www.sql-server-performance.com/tips/stored_procedures_p1.aspx
http://msdn.microsoft.com/en-us/library/ms998577.aspx
Also, if you're looking for all the ways to optimize performance on SQL Server, the second link above is a good place to start.
I prefer stored procedures due to Allow greater control over data, if you want to build a good, secure modular system then use stored procedures, it can run multiple sql-commands, has control-of-flow statements and accepts parameters. Everything you can do in a view you can do in a stored procedure. But in a stored procedure, you can do with much more flexibility.
Unfortunately, they're not the same type of beast.
A stored procedure is a set of T-SQL statements, and CAN return data. It can perform all kinds of logic, and doesn't necessarily return data in a resultset.
A view is a representation of data. It's mostly used as an abstraction of one or more tables with underlying joins. It's always a resultset of zero, one or many rows.
I suspect your question is more along the lines of:
Which is faster:
SELECTing from a view, or the equivalentSELECTstatement in a stored procedure, given the same base tables performing the joins with the same where clauses?
I believe that another way of thinking would be to use stored procedures to select the views. This will make your architecture a loosely coupled system. If you decide to change the schema in the future, you won't have to worry 'so' much that it will break the front end.
I guess what I'm saying is instead of sp vs views, think sp and views :)
Хранимые процедуры и представления различны и имеют разные цели. Я смотрю на представления как на шаблоны запросов. Я смотрю на хранимые процедуры как на модули кода.
Например, допустим, у вас есть таблица с именем tblEmployees с этими двумя столбцами (среди прочих): DateOfBirth и MaleFemale .
Представление под названием viewEmployeesMale , которое отфильтровывает только сотрудников-мужчин, может быть очень полезным. Представление под названием viewEmployeesFemale также очень полезно. Оба эти представления являются самоописывающимися и очень интуитивно понятными.
Теперь предположим, что вам нужно создать список всех сотрудников-мужчин в возрасте от 25 до 30 лет. Я бы предпочел создать хранимую процедуру для получения этого результата. Хотя его, безусловно, можно было бы построить как вид, на мой взгляд, для этого лучше всего подходит хранимая процедура. Манипуляция датой, особенно если есть значение NULL, может стать очень сложной задачей.