Хорошо ли иметь много просмотров базы данных?

Question

Я редко (ежемесячно / ежеквартально) генерирую сотни отчетов Crystal Reports, используя представления базы данных Microsoft SQL Server 2005. Эти представления тратят впустую циклы ЦП и ОЗУ в течение всего времени, когда я не читаю с них? Стоит ли вместо этого использовать хранимые процедуры, временные таблицы или недолговечные обычные таблицы, поскольку я редко читаю из своих представлений?

Я не администратор баз данных, поэтому я не знаю, что происходит за кулисами на сервере базы данных.

Возможно ли иметь слишком много представлений базы данных? Что считается лучшей практикой?

Answer 1

По большей части это не имеет значения. Да, у SQL Server будет больше вариантов, когда он анализирует таблицу SELECT * FROM (ему придется искать в системных каталогах «таблицу»), но он очень оптимизирован для этого и при условии, что у вас достаточно ОЗУ (в настоящее время большинство серверов делают) , вы не заметите разницу между 0 и 1000 просмотров.

Тем не менее, с точки зрения людей, пытающихся управлять и выяснить, что "сотни" из представлений сделать, вероятно, невозможно, поэтому у вас, вероятно, есть много дублированного кода там. Что произойдет, если изменятся некоторые бизнес-правила, встроенные в эти избыточные представления?

Основная точка зрения состоит в том, чтобы инкапсулировать бизнес-логику в псевдотаблица (так что у вас может быть таблица person, но затем представление под названием «active_persons», которое делает что-то волшебное). Создание представления для каждого отчета является глупым, если каждый отчет не настолько изолирован и уникален, что нет возможности его повторного использования.

Answer 2

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

При этом при выборе из представления запрос, определяющий представление, запускается вместе с запросом, который вы выполняете.

Например, если vwCustomersWhoHavePaid:

Select * from customers where paid = 1

и выполняемый вами запрос возвращает клиентов, оплативших после первого августа, следующим образом:

Select * from vwCustomersWhoHavePaid where datepaid > '08/01/08'

Запрос, который вы на самом деле выполняете:

Select * from (Select * from customers where paid = 1) where datepaid > '08/01/08'

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

Answer 3

Представления будут использовать ресурсы процессора / памяти только при их вызове.

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

Кроме того, если вам действительно не нужна транзакционная изоляция, рассмотрите возможность использования подсказки таблицы NOLOCK в своих запросах.

- Кевин Фэйрчайлд

Answer 4

Вы спрашиваете: что происходит за кулисами?

Представление - это набор текста SQL. Когда запрос использует представление, SQL Server помещает этот текст SQL в запрос. Это происходит ДО оптимизации. В результате оптимизатор может рассмотреть комбинированный код вместо двух отдельных частей кода для лучшего плана выполнения.

Вы должны посмотреть на планы выполнения ваших запросов! Там есть чему поучиться.

SQL Server также имеет концепцию кластерного представления . Кластерное представление - это поддерживаемый системой набор результатов (каждая вставка / обновление / удаление в базовых таблицах может привести к вставке / обновлению / удалению данных кластеризованного представления ). Распространенной ошибкой считается, что представления работают так же, как кластерные представления .