Коли і чому хтось вирішує, що їм потрібно створити представлення даних у своїй базі даних? Чому б просто не запустити звичайну збережену процедуру або вибрати?
Відповіді:
Перегляд надає кілька переваг.
1. Погляди можуть приховувати складність
Якщо у вас є запит, який вимагає об'єднання декількох таблиць, або має складну логіку чи обчислення, ви можете кодувати всю цю логіку у поданні, а потім виберіть з подання так само, як у таблиці.
2. Погляди можна використовувати як механізм захисту
Перегляд може вибрати певні стовпці та / або рядки з таблиці (або таблиць) та дозволів, встановлених у поданні замість базових таблиць. Це дозволяє наближатись лише до даних, які повинен бачити користувач.
3. Перегляди можуть спростити підтримку застарілого коду
Якщо вам потрібно перефактурувати таблицю, яка б порушила багато коду, можна замінити таблицю однойменним видом. У поданні подано таку саму схему, що і в оригінальній таблиці, а фактична схема змінилася. Це зберігає застарілий код, який посилається на таблицю, не порушується, і дозволяє вам змінити застарілий код у вільний час.
Це лише деякі з багатьох прикладів того, як погляди можуть бути корисними.
Крім усього іншого, його можна використовувати для безпеки. Якщо у вас є таблиця "клієнт", ви можете надати всім продавцям доступ до полів імені, адреси, поштового індексу тощо, але не кредитну карту. Ви можете створити подання, яке включає лише стовпці, до яких їм потрібен доступ, а потім надати їм доступ у поданні.
Select name, address, zipcode from customerне послужив б меті замість creating a view?
select * from customerщо дає їм доступ до всього. Якщо ви надаєте їм доступ до перегляду, а не до таблиці, вони не можуть отримати доступ до полів, які не переглядаються.
Вид - це інкапсуляція запиту. Запити, перетворені на перегляди, як правило, є складними, і тому збереження їх як перегляду для повторного використання може бути вигідним.
Зазвичай я створюю представлення для денормалізації та / або агрегації даних, які часто використовуються для цілей звітності.
EDIT
Під час уточнення, якби я мав базу даних, в якій деякі суб'єкти були особою, компанією, роллю, типом власника, порядком, деталями замовлення, адресою та телефоном, де таблиця особи зберігала як співробітників, так і контакти та адресу та телефонні столи зберігали номери телефонів як для осіб, так і для компаній, а команді розробників було доручено формувати звіти (або робити дані звітів доступними для не розробників), такі як продажі за працівником або продажі замовника або продажі за регіонами, продажі за місяцем , клієнтів за станом і т. д. Я створив би набір поглядів, які денормалізували відносини між сутностями бази даних, щоб був доступний більш інтегрований вигляд (не призначений для каламбуру) реальних сутностей. Деякі з переваг можуть включати:
Кілька причин: Якщо у вас складні приєднання, іноді найкраще мати перегляд, щоб будь-який доступ завжди був правильним, а розробники не повинні пам'ятати всі таблиці, які можуть знадобитися. Як правило, це може бути для фінансової програми, коли було б надзвичайно важливо, щоб усі фінансові звіти базувалися на одному і тому ж наборі даних.
Якщо у вас є користувачі, які хочете обмежити записи, які вони коли-небудь можуть бачити, ви можете використовувати представлення даних, надавати їм доступ лише до перегляду, а не до базових таблиць, а потім запитувати подання
Звіти Crystal, здається, вважають за краще використовувати представлення даних для збережених програм, тому люди, які роблять багато написання звітів, як правило, використовують багато переглядів
Перегляди також дуже корисні при рефакторингу баз даних. Ви часто можете приховати зміну, щоб старий код не бачив її, створюючи представлення. Читайте на базі даних рефакторингу, щоб побачити, як це працює, оскільки це дуже потужний спосіб рефактори.
Основна перевага представлення даних над збереженою процедурою полягає в тому, що ви можете використовувати подання так само, як ви використовуєте таблицю. А саме, на перегляд можна посилатися безпосередньо в FROMпункті запиту. Наприклад, SELECT * FROM dbo.name_of_view.
Приблизно у будь-який інший спосіб зберігаються процедури є більш потужними. Ви можете передати параметри, в тому числі outпараметрів , які дозволяють ефективно повертати кілька значень одночасно, ви можете зробити SELECT, INSERT, UPDATEі DELETEоперації, і т.д. і т.п.
Якщо ви хочете, щоб Перегляд міг запитувати з цього FROMпункту, але ви також хочете мати можливість передавати параметри, є також спосіб зробити це. Це називається функцією на основі таблиці.
Ось досить корисна стаття на цю тему:
EDIT: До речі, подібний вид викликає питання, яку перевагу має погляд у порівнянні з табличною функцією? Я не маю дуже гарної відповіді на це, але зауважу, що синтаксис T-SQL для створення представлення простіший, ніж для функції, що оцінюється за таблицею, і користувачі вашої бази даних можуть бути більш знайомі з переглядами.
Він може функціонувати як хороший "середній чоловік" між вашим ORM і вашими столами.
Приклад:
У нас була таблиця Person, що нам потрібно змінити структуру на ній, так що стовпець SomeColumn буде переміщений до іншої таблиці і матиме відношення один до багатьох.
Однак більшість системи, що стосується Особи, все ще використовували SomeColumn як єдину річ, а не багато речей. Ми використовували подання, щоб зібрати всі Деякі стовпці разом і поставити їх у вигляд, який вийшов чудово.
Це спрацювало тому, що рівень даних змінився, але вимога бізнесу принципово не змінилася, тому бізнес-об’єкти не потребували змін. Якби бізнес-об’єкти мали змінити, я не думаю, що це було б життєздатним рішенням, але погляди безумовно функціонують як хороша середина.
Зосередження уваги на конкретних переглядах даних дозволяє користувачам зосередитися на конкретних даних, які їх цікавлять, та на конкретних завданнях, за які вони відповідають. Непотрібні дані можна залишати поза полем перегляду. Це також підвищує безпеку даних, оскільки користувачі можуть бачити лише ті дані, які визначені у представленні даних, а не дані у нижній таблиці. Для отримання додаткової інформації про використання представлень з метою безпеки див. Розділ Використання представлень як механізмів безпеки.
Для спрощення маніпуляції даними представлення даних може спростити, як користувачі маніпулюють даними. Ви можете визначити часто використовувані об'єднання, проекції, запити UNION та SELECT як запити, щоб користувачі не мали вказувати всі умови та кваліфікації щоразу, коли на цих даних виконується додаткова операція. Наприклад, складний запит, який використовується для цілей звітності та виконує підзапити, зовнішні об'єднання та агрегацію для отримання даних із групи таблиць, може бути створений як перегляд. Перегляд спрощує доступ до даних, оскільки базовий запит не потрібно писати або подавати щоразу, коли звіт створюється; перегляд запитується замість цього. Для отримання додаткової інформації про маніпулювання даними.
Ви також можете створити вбудовані визначені користувачем функції, які логічно функціонують як параметризовані подання або представлення, які мають параметри в умовах пошуку WHERE-пункту. Для отримання додаткової інформації див. Вбудовані призначені користувачем функції.
Налаштувати перегляд даних дозволяє різним користувачам переглядати дані по-різному, навіть коли вони одночасно використовують одні й ті самі дані. Це особливо вигідно, коли користувачі з багатьма різними інтересами та рівнями кваліфікації діляться однією і тією ж базою даних. Наприклад, можна створити представлення, яке отримує лише ті дані для клієнтів, з якими працює менеджер облікових записів. У представленні даних можна визначити, які дані слід отримати, виходячи з ідентифікатора входу адміністратора акаунта, який використовує представлення даних.
Для експорту та імпорту даних представлення даних можна використовувати для експорту даних до інших програм. Наприклад, ви можете використовувати магазини та таблиці продажів у базі пабів для аналізу даних про продажі за допомогою Microsoft® Excel. Для цього можна створити подання на основі магазинів та таблиць продажів. Потім можна скористатися утилітою bcp для експорту даних, визначених представленням даних. Дані також можна імпортувати у певні представлення з файлів даних за допомогою утиліти bcp або BULK INSERT, за умови, що рядки можна вставити у представлення за допомогою оператора INSERT. Щоб отримати докладнішу інформацію про обмеження на копіювання даних у представлення даних, див. INSERT. Щоб отримати додаткові відомості про використання утиліти bcp та оператора BULK INSERT для копіювання даних до та з представлення, див. Копіювання до та з виду.
Для комбінування розділених даних Оператор набору Transact-SQL UNION може використовуватися в межах подання для об'єднання результатів двох або більше запитів з окремих таблиць в єдиний набір результатів. Це відображається користувачеві у вигляді однієї таблиці, що називається переглядом з розділеннями. Наприклад, якщо одна таблиця містить дані про продажі для Вашингтона, а інша таблиця містить дані про продажі в Каліфорнії, вигляд може бути створений із Спілки цих таблиць. Представлення представляє дані про продажі для обох регіонів. Для використання розділених представлень ви створюєте кілька однакових таблиць, задаючи обмеження для визначення діапазону даних, який можна додати до кожної таблиці. Потім вигляд створюється за допомогою цих базових таблиць. Коли запит запитується, SQL Server автоматично визначає, на які таблиці впливає запит, і посилається лише на ці таблиці. Наприклад, якщо в запиті вказано, що потрібні лише дані про продажі для штату Вашингтон, SQL Server зчитує лише таблицю, що містить дані продажів у Вашингтоні; до інших таблиць немає доступу.
Перегляди з розділеними можливостями можуть ґрунтуватися на даних з декількох неоднорідних джерел, таких як віддалені сервери, а не лише таблиці в одній базі даних. Наприклад, щоб об’єднати дані з різних віддалених серверів, кожен з яких зберігає дані для іншого регіону вашої організації, ви можете створити розподілені запити, які отримують дані з кожного джерела даних, а потім створити представлення на основі цих розподілених запитів. Будь-які запити читають лише дані з таблиць на віддалених серверах, які містять дані, запитувані запитом; інші сервери, на які посилаються розподілені запити у представленні, не мають доступу.
Коли ви розділяєте дані на кілька таблиць або на декілька серверів, запити, що отримують доступ лише до частини даних, можуть працювати швидше, оскільки для сканування менше даних. Якщо таблиці розташовані на різних серверах або на комп'ютері з декількома процесорами, кожну таблицю, яка бере участь у запиті, також можна сканувати паралельно, тим самим покращуючи продуктивність запитів. Крім того, завдання технічного обслуговування, такі як відновлення індексів чи резервне копіювання таблиці, можуть виконуватись швидше. Використовуючи розділений вигляд, дані все ще відображаються у вигляді однієї таблиці та можуть бути запитані як такі без необхідності посилатися на правильну базову таблицю вручну.
Розділені представлення оновлюються, якщо виконується будь-яке з цих умов: тригер INSTEAD OF визначається у поданні з логікою для підтримки операторів INSERT, UPDATE та DELETE.
І представлення перегляду, і вкладиші INSERT, UPDATE та DELETE відповідають правилам, визначеним для оновлення розділених представлень з розділеннями. Для отримання додаткової інформації див. Створення розділеного подання.
https://technet.microsoft.com/en-us/library/aa214282(v=sql.80).aspx#sql:join
Ось дві поширені причини:
Ви можете використовувати його для безпеки. Не надайте дозволів на головній таблиці та створіть представлення даних, що обмежує доступ у стовпцях чи рядках та надайте користувачам права перегляду.
Ви можете використовувати його для зручності. Об’єднайте разом кілька таблиць, які ви весь час використовуєте разом у режимі перегляду. Це може зробити запити послідовними та простішими.
Для цього є більше ніж одна причина. Іноді загальні запити приєднання спрощуються, оскільки можна просто запитувати ім'я таблиці, а не робити всі об'єднання.
Ще одна причина - обмеження даних різними користувачами. Так, наприклад:
Таблиця1: Колони - USER_ID; USERNAME; SSN
Користувачі адміністраторів можуть мати приватні особи на фактичній таблиці, але користувачі, яким ви не хочете мати доступ, наприклад, SSN, ви створюєте представлення як
СТВОРИТИ ВИДІЛЕННЯ USERNAMES ЯК ВИБРАТИ user_id, ім'я користувача З таблиці1;
Потім дайте їм приватні особи для доступу до перегляду, а не до столу.
Перегляди можуть бути знахідкою, коли ви робите звіти про застарілі бази даних. Зокрема, ви можете використовувати чутливі назви таблиць замість криптовалютних імен із 5 літер (де 2 з них є загальним префіксом!) Або назви стовпців, повних скорочень, які, напевно, мали сенс на той час.
Як правило, я переглядаю погляди, щоб полегшити життя, отримати розширені деталі від якоїсь сутності, яка зберігається в декількох таблицях (усунути безліч приєднань до коду для підвищення читабельності), а іноді й обмінюватися даними через кілька баз даних або навіть для полегшення читання вставок.
Ось як використовувати View разом з дозволами для обмеження стовпців, які користувач може оновлювати в таблиці.
/* This creates the view, limiting user to only 2 columns from MyTestTable */
CREATE VIEW dbo.myTESTview
WITH SCHEMABINDING AS
SELECT ID, Quantity FROM dbo.MyTestTable;
/* This uses the view to execute an update on the table MyTestTable */
UPDATE dbo.myTESTview
SET Quantity = 7
WHERE ID = 1Коли я хочу переглянути знімок таблиці (ів) та / або перегляду (лише для читання)
Мені подобається використовувати представлення даних про збережені процедури, коли я виконую лише запит. Перегляди також можуть спростити безпеку, їх можна використовувати для полегшення вставок / оновлень до декількох таблиць, а також можна робити знімки / матеріалізувати дані (запускати тривалий запит і зберігати кешовані результати).
Я використовував матеріалізовані представлення для запуску запитів, що не потребують точності в режимі реального часу.
Це не відповідає точно на ваше запитання, але я вважав, що варто згадати Матеріалізовані погляди . Мій досвід здебільшого з Oracle, але нібито SQL-сервер досить схожий.
Ми використовували щось подібне в нашій архітектурі для вирішення проблем із продуктивністю XML. Наші системи розроблені з великою кількістю даних, що зберігаються у вигляді XML у рядку, і програмам може знадобитися запитувати конкретні значення в ній. Обробка багатьох XMLTypes та запуску XPaths у великій кількості рядків має великий вплив на продуктивність, тому ми використовуємо форму матеріалізованих представлень для витягування потрібних XML-вузлів у реляційну таблицю в будь-який час, коли базова таблиця змінюється. Це ефективно забезпечує фізичний знімок запиту в певний момент часу, на відміну від стандартних представлень, які б виконували їх запит на вимогу.
Я бачу збережену процедуру більше як метод, який я можу викликати проти своїх даних, тоді як для мене подання забезпечує механізм створення синтетичної версії базових даних, проти якої можна створити запити або збережені процедури. Я створять представлення, коли спрощення або агрегація має сенс. Я напишу збережену процедуру, коли хочу надати дуже конкретну послугу.
Цікавим у переглядах є те, що Microsoft Access розглядає їх як таблиці: коли ви додаєте передній панель Microsoft Access до бази даних SQL за допомогою ODBC, ви бачите таблиці та представлення у списку доступних таблиць. Отже, якщо ви готуєте складні звіти в MS Access, ви можете дозволити серверу SQL робити об’єднання та запити та значно спростити ваше життя. Дітто для підготовки запиту в MS Excel.
У моїх виробничих базах даних є лише 10 або більше переглядів. Я використовую кілька для стовпців, якими я користуюся весь час. Один набір, який я використовую, походить із 7 таблиць, деякі із зовнішніми приєднаннями, а не переписувати, що постійно мені потрібно лише викликати цей вид у вибраному режимі та зробити одне або 2 об’єднання. Для мене це просто економія часу.
Я створюю xxx, який відображає всі взаємозв'язки між основною таблицею (наприклад, таблицею продуктів) та довідковою таблицею (наприклад, ProductType або ProductDescriptionByLanguage). Це створить представлення, яке дозволить мені отримати товар і всі його деталі, перекладені з його зовнішніх ключів до його опису. Тоді я можу використовувати ORM для створення об’єктів, щоб легко будувати сітки, комбіновані поля тощо.
Я думаю, що спочатку. Щоб приховати складність запиту. Це дуже підходить для переглядів. Як, коли ми нормалізуємо таблиці баз даних, збільшується. Зараз отримати дані дуже важко, коли кількість таблиць збільшується. Отже, найкращим способом обробки є слідування виду. Якщо я помиляюся, виправте мене.
Ми створюємо представлення, щоб обмежувати чи обмежувати доступ до всіх рядків / стовпців у таблиці. Якщо власник хоче, щоб лише загальні або обмежені рядки / стовпці мали спільний доступ, тоді він створить представлення з цим стовпцем.
Для безпеки: надає кожному користувачеві дозвіл на доступ до бази даних лише через невеликий набір переглядів, що містять конкретні дані, яким користувач або група користувачів має право бачити, обмежуючи доступ користувача до інших даних.
Простота запитів та структури : Перегляд може витягувати дані з декількох таблиць та представляти одну таблицю, спрощуючи інформацію та перетворюючи запити з декількох таблиць у запити для однієї таблиці для подання, і це надає користувачам конкретний вигляд структури бази даних, представляючи база даних як набір віртуальних таблиць, специфічних для конкретних користувачів або груп користувачів.
Для створення послідовної структури бази даних : Перегляди представляють послідовне, незмінне зображення структури бази даних, навіть якщо основні таблиці джерел змінені.