Как представления уменьшают дублирование кода?

Question

Я читал что-то вроде этого о db views:

Представления невероятно мощные и полезно по одной причине, которая выделяется выше всех других очень веских причин. Они уменьшают дублирование кода. То есть, в большинстве случаев, суть. Если запрос будет использоваться в трех или более места, то вид будет резко упростить ваши изменения, если схема или параметры запроса меняются. Однажды мне пришлось изменить 22 хранимых процедур для изменения некоторая логика запроса. Если оригинал архитектура использовала взгляды, то У меня было бы только три изменения.

Может кто-нибудь объяснить мне, как это работает, и, может быть, привести несколько примеров?

С наилучшими пожеланиями!

Answer 1

Представление позволяет изменять структуру базовой таблицы, не влияя на то, как ваше приложение видит данные. Поскольку представление часто представляет концепцию домена более высокого уровня в одной или нескольких таблицах (например, представление «Доступные рейсы» при построении из таблиц «Авиабилеты», «Тарифы» и «Авиакомпании»), они могут представлять сложные идеи в единой способ.

Поскольку логика преобразования необработанных таблиц базы данных в представления фиксируется в базе данных, сложность их построения с меньшей вероятностью достигнет вашего приложения. Это означает, что если вы используете Available Flights во многих местах, а затем что-то меняется в таблице Flights, то нужно будет изменить только части, явно зависящие от Flights, а не что-либо о Available Flights.

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

Answer 2

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

Возьмите следующие три похожих запроса.

SELECT
    *
FROM
    Table1
INNER JOIN
    Table2 ON Table2.Id = Table1.Id
INNER JOIN
    Table3 ON Table3.Id = Table2.Id
INNER JOIN
    TableX ON TableX.Id = Table3.Id

SELECT
    *
FROM
    Table1
INNER JOIN
    Table2 ON Table2.Id = Table1.Id
INNER JOIN
    Table3 ON Table3.Id = Table2.Id
INNER JOIN
    TableY ON TableY.Id = Table3.Id

SELECT
    *
FROM
    Table1
INNER JOIN
    Table2 ON Table2.Id = Table1.Id
INNER JOIN
    Table3 ON Table3.Id = Table2.Id
INNER JOIN
    TableZ ON TableZ.Id = Table3.Id

Теперь, если бы мы создали ВИД, такой как

CREATE VIEW View123 AS
SELECT
    *
FROM
    Table1
INNER JOIN
    Table2 ON Table2.Id = Table1.Id
INNER JOIN
    Table3 ON Table3.Id = Table2.Id

Три запроса теперь можно записать как

SELECT
    *
FROM
    View123
INNER JOIN
    TableX ON TableX.Id = View123.Id

SELECT
    *
FROM
    View123
INNER JOIN
    TableY ON TableY.Id = View123.Id

SELECT
    *
FROM
    View123
INNER JOIN
    TableZ ON TableZ.Id = View123.Id

Answer 3

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

Предположим, у вас есть таблица T с колонками C1 и C2. Затем в вашем приложении есть несколько мест, где вы запрашиваете T как таковой: SELECT C1 FROM T WHERE C2 = 'cow'. Однажды вы понимаете, что cow больше не является значением, необходимым для этого запроса, и вы хотите изменить значение на goat. Чтобы выполнить это изменение, вам нужно найти каждый из операторов SELECT и заменить cow на goat.

Если бы вы использовали View V, привязанный к SELECT C1 FROM T WHERE C2 = 'cow', ваши утверждения выглядели бы как SELECT * FROM V - тогда вы могли бы изменить V вместо изменения отдельных утверждений и, таким образом, сделать одно изменение вместо нескольких .

Справочник MySQL содержит несколько хороших примеров использования представлений.

Answer 4

Представление похоже на предварительно определенный запрос. Вы просто пишете запрос SELECT, который возвращает нужные столбцы / данные из таблиц вашей базы данных - любой запрос, возвращающий записи, может использоваться в качестве основы для представления. Затем вы создаете представление, давая SQL-запрос, который вы написали в качестве определения представления.

Когда вы делаете SELECT из представления, ядро ​​базы данных выполняет ваш запрос и возвращает результаты, как если бы вы сделали SELECT column1, column2 FROM table.

Самое лучшее в представлениях - это то, что вы не ограничены одной таблицей. Итак, представьте, что у вас есть три таблицы в отношениях «многие ко многим» - user <-> user_to_role <-> role.

Вы можете написать запрос, чтобы получить пользователей и связанные с ними роли:

ВЫБРАТЬ u.user_name, r.role_name ОТ пользователь ты ВНУТРЕННЕЕ ПРИСОЕДИНЕНИЕ user_to_role ur ON ur.user_id = u.id ВНУТРЕННЯЯ РЕШЕНИЕ роль r ON r.id = ur.role_id;

Теперь создайте представление, используя приведенное выше определение SQL (называемое user_role_view), и затем вы можете выполнить:

SELECT * FROM user_role_view в вашем приложении и получите набор результатов, содержащий столбцы user_name и role_name, все связаны правильно: -)

При правильном использовании представления могут быть очень мощными и очень полезными для снижения сложности ваших запросов SQL на уровне приложений.

Answer 5

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

Например, представьте представление OrderDetailsEx:

 CREATE VIEW OrderDetailsEx 
    (OrderID, OrderDate, ProductID, Description, 
     UnitPrice, Quantity, ExtendedPrice, Tax, TotalPrice) AS
 SELECT O.OrderID, O.OrderDate, D.ProductID, P.Description, 
     D.UnitPrice, D.Quantity, (D.Quantity * D.UnitPrice),
     C.TaxRate, (C.TaxRate * D.Quantity * D.UnitPrice)
 FROM Orders O 
     INNER JOIN OrderDetails D ON O.OrderID = D.OrderID
     INNER JOIN Products P ON P.ProductID = D.ProductID
     INNER JOIN Customers C ON C.CustID = O.CustID

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

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

Answer 6

Представление - это макрос.Ни больше, ни меньше.

Если вы начнете объединять представления в представлениях, они могут быть развернуты / развернуты в запросах на уничтожение сервера.

Они могут использоваться, например, для скрытия изменений схемы таблиц и виндексированные / материализованные представления, но они не являются серебряной пулей.Соблазнительно «инкапсулировать» ваш код, но использовать его разумно

Является ли написание запроса с использованием Views хорошей стратегией?

Тони Роджерсон: VIEWS - они предлагаютнет преимуществ оптимизации;они просто встроенные макросы - используйте экономно

Answer 7

http://msdn.microsoft.com/en-us/library/aa258253%28SQL.80%29.aspx

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