Это должно хорошо иметь много представлений базы данных?
Вариант ответа Самера [Coffeescript]
getUrlParameter = (sParam) ->
sPageURL = window.location.search.substring(1)
sURLVariables = sPageURL.split('&')
i = 0
while i < sURLVariables.length
sParameterName = sURLVariables[i].split('=')
if sParameterName[0] == sParam
return sParameterName[1]
i++
4 ответа
По большей части это не имеет значения. Да, SQL Server будет иметь больше вариантов, когда он проанализирует ВЫБОР * таблица FROM (это должно будет посмотреть в системных каталогах для 'таблицы'), но он высоко оптимизирован для этого, и если у Вас есть достаточная RAM (большинство серверов в наше время делает), Вы не заметите различия между 0 и 1 000 представлений.
Однако с перспективы людей, пытаясь справиться и выяснить то, что делают "сотни" представлений, вероятно, невозможно, таким образом, у Вас, вероятно, есть много дублированного кода там. Что происходит, если некоторое изменение бизнес-правил, которые встраиваются в эти избыточные представления?
Основной момент представлений должен инкапсулировать бизнес-логику в псевдо таблицу (таким образом, у Вас может быть таблица человека, но затем представление назвало "active_persons", который делает некоторое волшебство). Создание представления для каждого отчета довольно глупо, если каждый отчет так не изолируется и уникален, который нет никакой способности снова использовать.
Представление является запросом, который Вы часто выполняете с предварительно установленными параметрами. Если Вы знаете о рассмотрении тех же данных все время, можно создать представление для простоты использования и для привязки данных.
Однако когда Вы выбираете из представления, запрос определения представления выполняется наряду с запросом, который Вы выполняете.
Например, если 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'
Это - что-то, что необходимо иметь в виду при создании представлений, они - способ хранить данные, на которые Вы смотрите часто. Это - просто способ организовать данные, таким образом, это легче к доступу.
Представления только собираются поднять CPU/ресурсы памяти, когда их называют.
Во всяком случае лучшая практика должна была бы консолидировать то, что может быть консолидировано, удалить то, что может быть удалено, и если она буквально только используется Вашими отчетами, выберите последовательный стандарт именования для представлений, таким образом, они могут легко группироваться при поиске конкретного представления.
Кроме того, если Вы действительно не нуждаетесь в транзакционной изоляции, рассматриваете использование подсказки таблицы NOLOCK в Ваших запросах.
- Kevin Fairchild
Вы спрашиваете: что продолжается негласно?
Представление является набором кода на SQL. Когда запрос использует представление, места SQL Server что код на SQL в запрос. Это происходит ПЕРЕД оптимизацией. Результатом является оптимизатор, может рассмотреть объединенный код вместо двух отдельных частей кода для лучшего плана выполнения.
Необходимо посмотреть на планы выполнения запросов! Существует так для изучения там.
SQL Server также имеет понятие кластеризованного представления. Кластеризованное представление является сохраняемым набором результатов системы (каждый вставляет/обновляет/удаляет на базовых таблицах, может вызвать, вставляют/обновляют/удаляют на данных кластеризованного представления). Это - частая ошибка думать, что представления работают в пути, который кластеризировался, представления работают.