Навіщо використовувати уявлення

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

Власне, основним завданням уявлень і є відображення даних у зручному форматі

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

Я рекомендую використовувати уявлення навіть для разових запитів і звітів Із запуском запитів подання справляються краще, ніж збережені процедури

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

Деякі розробники використовують уявлення як ключовий компонент архітектури доступу до даних і ізолюють фізичну схему від динамічного SQL Я продовжую використовувати збережені процедури на певному рівні абстракції, оскільки вони вирішують проблеми обробки помилок, дозволяють краще керувати транзакціями і пропонують більше параметрів для програмування (докладніше про це – в главі 25)

Однак і подання відмінно справляються з цим завданням Я віддаю перевагу використовувати уявлення для прямого доступу до даних, а не використовувати для цього код SQL Якщо ваш додаток NET містить багато впровадженого коду SQL, то використання подань для рівня абстракції бази даних може виявитися більш простим, ніж переробка програми для виклику збережених процедур

Грунтуючись на своїй впевненості, що уявлення краще використовувати для підтримки разових запитів, а не як центральну частину програми, дозвольте висловити кілька думок щодо створення уявлень разових запитів

■ Використовуйте вистави для спрощення складних обєднань та приховування містичних ключів, використовуваних для звязування даних у схемі бази даних Добре створене подання буде відмінною підмогою в доступі користувачів до необхідних їм даним

■ Зберігайте складні запити консолідації даних як подання Так як

у підсумковій функції чи реченні GROUP BY повинні брати участь всі стовпці, багато запити включають в себе підзапити для представлення неконсолідіруемих стовпців Кінцеві користувачі будуть вдячні за включення цих складних запитів в уявлення

■ Привласнюйте стовпцях з труднопроїзносимимі назвами зрозумілі псевдоніми Як інструкція SELECT може використовувати псевдоніми та іменовані діапазони для імен таблиць і стовпців, так і уявлення можуть використовувати цю можливість для представлення набору даних кінцевому користувачеві Наприклад, стовпець au_lname в базі даних Microsoft Pubs мало що скаже кінцевому користувачеві, якщо не привласнити йому зрозумілий псевдонім LastName (прізвище):

SELECT au_lname AS LastName FROM PubsdboAuthor

Тепер уявлення, створене на основі зазначеного вище запиту, буде перераховувати прізвища авторів в стовпці LastName, а не au_lname, як раніше

■ Включайте в уявлення тільки ті стовпці, які цікавлять користувача, – це полегшить йому завдання перегляду результатів запиту Стовпці, що включаються в уявлення, називають проецируемую У цьому терміні мається на увазі, що уявлення проектують на екран з таблиць тільки обрані стовпці

■ Ретельно плануйте вистави для їх довгострокового використання

Уявлення, створені тільки для однієї мети, швидко застарівають і тільки засмічують базу даних Створюйте уявлення, припускаючи, що вони будуть використовуватися з пропозицією WHERE для вибірки підмножини даних в іншому випадку подання має повертати все безліч даних Наприклад, уявлення vEventList повертає всі події щоб вибрати з них тільки конкретні, користувач повинен супроводити його пропозицією WHERE

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

Створення додатка переслідує дві мети: полегшити доступ користувачів до потрібних їм даних і захистити дані від користувачів Створюючи вистави, извлекающие коректні дані, ви захищаєте решту інформацію від помилкового чи не коректного використання

Розподілені подання або федеративні бази даних ділять великі таблиці на кілька маленьких, які іноді навіть розміщуються на різних серверах Це дозволяє поліпшити продуктивність систем Розподілені уявлення потім збирають цю інформацію з різних місць, використовуючи декілька дискових підсистем

Індексовані подання, що поставляються з редакцією SQL Server 2005 Enterprise, являють собою потужний засіб, що створює індекс на денормалізованном множині даних, визначених поданням Ці індекси згодом можуть використовуватися при створенні запитів, які обєднують безлічі даних Дані уявлення використовуються в запитах, так що сам термін звучить трохи дивно

Обидва цих просунутих подання корисні тільки для вирішення питань продуктивності в особливо великих базах даних, розмір яких перевищує терабайт Про них ми поговоримо в розділі 53

Джерело: Нільсен, Пол Microsoft SQL Server 2005 Біблія користувача : Пер з англ – М: ООО ІД Вільямс , 2008 – 1232 с : Ил – Парал тит англ

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*