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

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

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

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

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

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

Answer 4

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

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

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

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