Я читаю біблію SQL Server 2008 і висвітлюю розділ подань. Але автор справді не пояснює мету поглядів. Що корисно використовувати для переглядів? Чи слід використовувати їх на своєму веб-сайті та які переваги від них?
Відповіді:
Іншим використанням, про яке, схоже, не згадувала жодна з попередніх відповідей, є простіший розгортання змін структури таблиці.
Скажімо, ви хочете вилучити таблицю ( T_OLD), що містить дані для активних користувачів, і замість цього використовувати нову таблицю з подібними даними (з іменем T_NEW), але таку, яка містить дані як для активних, так і для неактивних користувачів, з одним додатковим стовпцем active.
Якщо у вашій системі є мільйони запитів, які мають SELECT whatever FROM T_OLD WHERE whatever, у вас є два варіанти розгортання:
1) Холодна Туреччина - Змініть БД і одночасно змініть, протестуйте та випустіть численні фрагменти коду, що містять зазначений запит. ДУЖЕ важко зробити (або навіть скоординувати), дуже ризиковано. Погано
2) Поступовий - змініть БД, створивши T_NEWтаблицю, опустивши T_OLDтаблицю і замість цього створивши виклик VIEW,T_OLD що імітує T_OLDтаблицю на 100% (наприклад, запит на подання є SELECT all_fields_except_active FROM T_NEW WHERE active=1).
Це дозволить вам уникнути випускати будь-який код , який в даний час вибирає з T_OLD, і зробити зміни мігрувати код з T_OLDдо T_NEWна дозвіллі.
Це простий приклад, інші набагато більше задіяні.
PS З іншого боку, ви, мабуть, мали мати API збережених процедур замість прямих запитів з T_OLD, але це не завжди так.
(Скопійовано з першого навчального посібника, який з’явився під час пошуку в Google (посилання вже мертве), але він має всі переваги, які я би ввів сам.)
Перегляди мають такі переваги:
- Безпека - подання можуть бути доступними для користувачів, тоді як базові таблиці безпосередньо не доступні. Це дозволяє DBA надавати користувачам лише ті дані, які їм потрібні, одночасно захищаючи інші дані в тій самій таблиці.
- Простота - подання можна використовувати для приховування та повторного використання складних запитів.
- Спрощення або уточнення імені стовпця - подання можуть використовуватися для надання псевдонімів імен стовпців, щоб зробити їх більш запам'ятовуються та / або змістовними.
- Сходинка - подання можуть забезпечити сходинку в "багаторівневому" запиті. Наприклад, ви можете створити представлення запиту, що враховує кількість продажів, здійснених кожним продавцем. Потім ви можете здійснити запит у цьому поданні, щоб згрупувати продавців за кількістю продажів, які вони здійснили.
Деякі причини з Вікіпедії :
Перегляди можуть надати переваги перед таблицями:
ПЕРЕГЛЯДИ можуть бути використані як багаторазові розділи SELECT / CODE, які можуть бути включені в інші вибірки / запити, до яких потрібно приєднатись, та використовувати різні різні фільтри, без необхідності відтворювати весь SELECT кожного разу.
Це також розміщує логіку в одному місці, так що вам не доведеться її змінювати по всій основі коду.
Погляньте
Вибір між збереженими процедурами, функціями, поданнями, тригерами, вбудованим SQL
Головна краса подання полягає в тому, що його можна використовувати як таблицю в більшості ситуацій, але на відміну від таблиці, він може інкапсулювати дуже складні обчислення та загальновживані об’єднання. Він також може використовувати майже будь-який об'єкт у базі даних, за винятком збережених процедур. Перегляди найбільш корисні, коли вам завжди потрібно приєднати один і той же набір таблиць, скажімо Замовлення з деталлю замовлення, щоб отримати поля підсумкового розрахунку тощо.
Представлення - це рівень абстракції, і він робить те, що робить будь-який хороший рівень абстракції, включаючи інкапсуляцію схеми бази даних та захист від наслідків зміни внутрішніх деталей реалізації.
Це інтерфейс.
Ось одне дуже поширене використання використання подань для обмеження сутності за деякими критеріями.
Таблиця: USERS містить усіх користувачів
Перегляд: ACTIVE_USERS містить усіх користувачів, крім тих, кого призупинено, заборонено, чекає активації та не відповідає жодним критеріям, які ви можете визначити в майбутньому як частину активних вимог. Це робить непотрібним видалення будь-яких рядків з таблиці USERS, якщо ви вирішите не робити, оскільки ACTIVE_USERS завжди може приховати небажані рядки.
Таким чином, ви можете використовувати таблицю на своїх сторінках керування користувачами, але решта програми може використовувати ACTIVE_USERS, оскільки вони можуть бути єдиними користувачами, які повинні мати можливість виконувати процеси та отримувати доступ / змінювати дані.
Представлення даних дозволяють комбінувати дані з декількох різних таблиць та форматувати їх (об’єднувати поля, вводити більш значущі назви полів тощо), щоб кінцевим користувачам було простіше. Вони є абстракцією моделі бази даних. Вони також можуть використовуватися для надання користувачам доступу до даних у таблиці, не надаючи їм безпосереднього доступу до самої таблиці.
Ось деякі з багатьох причин використання подання, а не таблиці безпосередньо
Погляди - це зло! Уникайте їх, якщо це можливо, і використовуйте лише з причини, зазначеної DVK - тимчасова міграція даних.
Ви повинні розуміти, що в базі даних із 100 таблицями важко запам’ятати призначення кожної таблиці. Тепер, якщо ви додасте сюди ще 300 переглядів, це стане повною халепою. Потім "любителі перегляду", як правило, використовують вкладені подання, а потім використовують вкладені подання у збережених процедурах. Зараз я особисто працюю з базою даних, де є подання, вкладені в глибину 4 рази! Отже, щоб зрозуміти найпростішу логіку збереженої процедури, я маю пройти спочатку всі подання.