Для чого корисні перегляди?

Я просто намагаюся отримати загальне уявлення про те, для чого використовуються подання в СУБД. Тобто я знаю, що таке погляд і як його скласти. Я також знаю, для чого я їх використовував у минулому.

Але я хочу переконатися, що я глибоко розумію, для чого корисний погляд, а для чого не повинен бути корисним подання. Більш конкретно:

1. Для чого корисний вигляд?
   • Чи бувають ситуації, коли спокусливо використовувати подання, коли ви не повинні ним користуватися?
   • Чому ви використовуєте подання замість чогось на зразок функції, що має значення таблиці, або навпаки?
   • Чи існують якісь обставини, якими може бути корисним подання, які не видно на перший погляд?

(І для запису, деякі з цих питань навмисно наївні. Це частково перевірка концепції.)

1) Для чого корисний вигляд?

IOPO лише в одному місці

• Якщо ви враховуєте самі дані або запити, що посилаються на об’єднані таблиці, використання подання дозволяє уникнути зайвої надмірності.

• Види також забезпечують абстрагуючий рівень, що перешкоджає прямому доступу до таблиць (і результуючі кайданки, що посилаються на фізичні залежності). Насправді, я вважаю, що це хороша практика ¹ пропонувати лише абстрактний доступ до базових даних (з використанням переглядів та функцій, що оцінюють таблиці), включаючи перегляди, такі як ^1. Я, напевно, визнаю, що є чимала фраза "Робіть, як я кажу; не як я робити "у цій пораді;)

CREATE VIEW AS
      SELECT * FROM tblData

2) Чи існують ситуації, коли спокусливо використовувати подання, коли ви не повинні ним користуватися?

Раніше продуктивність з точки зору об’єднань викликала занепокоєння (наприклад, SQL 2000). Я не фахівець, але давно про це не хвилювався. (Також я не можу думати, де я зараз використовую об’єднання подань.)

Інша ситуація, коли подання може бути надмірним, полягає в тому, що на подання посилається лише з одного місця виклику, а замість нього може використовуватися похідна таблиця. Так само, як анонімний тип кращий перед класом у .NET, якщо анонімний тип використовується / посилається лише один раз.

    • Див. Похідний опис таблиці на веб-сайті http://msdn.microsoft.com/en-us/library/ms177634.aspx

3) Чому б ви використовували подання замість чогось на зразок табличної функції чи навпаки?

(Окрім причин ефективності) Функція, що має значення таблиці, функціонально еквівалентна параметризованому поданню. Насправді, загальним простим випадком використання функції, що має значення таблиці, є просто додавання фільтру речень WHERE до вже існуючого подання в одному об'єкті.

4) Чи існують якісь обставини, які можуть бути корисними для подання, які не очевидні на перший погляд?

Я не пригадую жодного невидимого використання маківки. (Гадаю, якби я міг, це зробило б їх очевидними;)

Певним чином, вигляд схожий на інтерфейс. Ви можете змінювати базову структуру таблиці все, що завгодно, але подання дає можливість коду не змінюватись.

Погляди - це приємний спосіб надати щось просте для написання звітів. Якщо користувачі вашого бізнесу хочуть отримати доступ до даних із чогось на зразок Crystal Reports, ви можете надати їм кілька подань у своєму обліковому записі, які спрощують дані - можливо, навіть денормалізують їх для них.

Представлення можна використовувати для забезпечення безпеки (тобто: користувачі можуть мати доступ до подань, які отримують доступ лише до певних стовпців таблиці), подання можуть забезпечувати додатковий захист для оновлень, вставок тощо. Представлення також забезпечують спосіб імен псевдонімів (як це робить sp)), але подання є більше ізоляцією від фактичної таблиці.

У певному сенсі погляди денормалізують. Денормалізація іноді необхідна для надання даних більш значущим чином. Це те, що так чи інакше роблять багато додатків за допомогою моделювання доменів у своїх об’єктах. Вони допомагають представити дані таким чином, щоб вони більш відповідали перспективам бізнесу.

На додаток до сказаного іншими, подання також можуть бути корисними для видалення більш завершених запитів SQL із програми.

Як приклад, замість того, щоб у програмі робити:

sql = "вибрати a, b із таблиці1 об'єднання вибрати a, b із таблиці2";

Ви можете абстрагувати це до подання:

створити подання union_table1_table2_v як
вибрати a, b з таблиці1
union
вибрати a, b з table2

а в коді програми просто маєте:

sql = "вибрати a, b із union_table1_table2_v";

Крім того, якщо структури даних коли-небудь змінюються, вам не доведеться міняти код програми, перекомпілювати та передислокувати. ви б просто змінили подання в базі даних.

Представлення приховують складність бази даних. Вони чудові з багатьох причин і корисні в багатьох ситуаціях, але якщо у вас є користувачі, яким дозволено писати власні запити та звіти, ви можете використовувати їх як захист, щоб переконатися, що вони не подають погано розроблені запити з неприємними декартовими об'єднаннями, які виводять ваш сервер баз даних.

ОП запитав, чи були ситуації, коли спокусливо використовувати подання, але це недоречно.

Те, для чого ви не хочете використовувати подання, замінює складні об'єднання. Тобто, нехай ваша звичка процедурного програмування розбивати проблему на дрібніші частини не веде вас до використання декількох подань, об’єднаних замість одного більшого об’єднання. Це призведе до зниження ефективності механізму баз даних, оскільки він, по суті, робить кілька окремих запитів, а не один більший.

Наприклад, скажімо, вам потрібно об’єднати таблиці A, B, C та D разом. Можливо, у вас виникне спокуса створити вигляд із таблиць A & B та вигляд з C & D, а потім об’єднати два перегляди разом. Набагато краще просто приєднати A, B, C та D в одному запиті.

Представлення даних можуть централізувати або консолідувати дані. Там, де я перебуваю, ми маємо низку різних баз даних на декількох різних пов'язаних серверах. Кожна база даних містить дані для іншого додатка. Кілька таких баз даних містять інформацію, яка стосується ряду різних додатків. Що ми зробимо за таких обставин, це створити представлення даних у базі даних програми, яке просто витягує дані з бази даних, де дані дійсно зберігаються, так що запити, які ми пишемо, не мають вигляду, що вони переходять через різні бази даних.

Наразі відповіді правильні - погляди корисні для забезпечення безпеки, денормалізації (хоча, якщо неправильно зроблено), більша частина цього шляху, абстрагування моделі даних тощо.

Крім того, представлення даних зазвичай використовуються для реалізації ділової логіки (втрачений користувач - це користувач, який не входив в систему за останні 40 днів, подібні речі).

Представлення зберігають багато повторюваних складних операторів JOIN у ваших сценаріях SQL. Ви можете просто інкапсулювати якийсь складний JOIN у якомусь поданні та викликати його у своєму операторі SELECT, коли це потрібно. Це іноді було б зручно, прямо вперед і простіше, ніж виписувати оператори об’єднання у кожному запиті.

Представлення - це просто збережений, названий оператор SELECT. Думайте про подання, як про функції бібліотеки.

Я хотів наголосити на використанні поглядів для звітування. Часто виникає конфлікт між нормалізацією таблиць бази даних для прискорення продуктивності, особливо для редагування та вставки даних (використання OLTP), та денормалізацією, щоб зменшити кількість об’єднань таблиць для запитів для звітування та аналізу (використання OLAP). За необхідності, зазвичай перемагає OLTP, оскільки введення даних повинно мати оптимальну продуктивність. Тоді створення переглядів для оптимальної роботи звітів може допомогти задовольнити обидва класи користувачів (введення даних та переглядачі звітів).

Я пам’ятаю дуже довгий SELECT, який включав кілька СОЮЗІВ. Кожен СОЮЗ включав приєднання до таблиці цін, яка була створена на льоту за допомогою SELECT, який сам по собі був досить довгим і важким для розуміння. Я думаю, було б непоганою ідеєю мати погляд, який би створив таблицю цін. Це скоротило б загальний SELECT приблизно наполовину.

Я не знаю, чи буде БД оцінювати подання один раз, або раз кожен раз, коли було викликано. Хтось знає? Якщо перше, використання подання покращило б продуктивність.

Будь-коли вам знадобиться [my_interface]! = [User_interface].

Приклад:

ТАБЛИЦЯ А:

• ідентифікатор
• інформація

ПЕРЕГЛЯД ТАБЛИЦІ А:

• Інформація споживача

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

У поданні буде використовуватися базовий індекс для ідентифікатора первинного ключа, тому ви не побачите втрати продуктивності, а просто кращу абстракцію запиту вибору.