2010-09-03 3 views
3

Существуют ли какие-либо негативные последствия при создании представлений, в частности больших (50+ столбцов) в базе данных?SQL View Question

ответ

1

С точки зрения производительности я бы сказал, что на самом деле не существует отрицательного эффекта. Если базовый запрос неэффективен и может вызвать нежелательную блокировку, представление наследует эти проблемы, хотя и несколько смягчается тем фактом, что он скорее всего будет кэшироваться, чем произвольный оператор. Я бы сказал, где возникает риск негативных эффектов, так это то, что, создавая представление и абстрагируя сложность запроса, вы рискуете использовать его без четкого понимания того, каковы характеристики базового запроса. Затем на позитивных боковых представлениях также открываются некоторые различные возможности оптимизации (индексированные представления и т. Д.), И бывают случаи, когда возможность де-нормализации набора данных может значительно уменьшить потребность в записи избыточных запросов.

Таким образом, как и большинство инструментов, помогают ли они или вред в руках исполнителя.

1

Зависит, если это 1 столбец из 50 внутренних столов или 50 столбцов из 1 таблицы.
Если честно, то все в порядке, если вы не используете в них множество скалярных функций.

Подумайте об этом, это очень субъективный вопрос. Вставьте некоторый код;)

+0

Ну я havn't создал Посмотреть еще, но в основном у меня есть таблица со столбцом XML, и я буду разбор из многих этих данных в поле зрения в 50+ колонке – mint

0

По моему опыту представление дает вам точно такую ​​же производительность, как если бы вы напрямую запрашивали физические таблицы.

0

Если это индексированный вид, это займет больше места в вашем db и замедлит обновление записей в базовых таблицах.

1

A SELECT на вид (не индексируется) делает что-то вроде:

SELECT Xyz FROM 
(
    SELECT Abc FROM yourbigtable 
) 

Так проверить производительность запросов, которые вы хотите достичь первых, я бы сказал.

Попробуйте сначала решить проблему без представлений, а затем упростите ее.

Майк