НОУ ІНТУІТ, Лекція, Якісаме дані програми слід зберігати у базі даних
З появою вдосконалених щодо продуктивності та більш гнучких ядер баз даних, як, скажімо, у Microsoft SQL Server 2005, розмивається межа між тими об'єктами, які слід зберігати в базах даних, і тими, які зберігати в них не слід. Раніше бази даних добре підходили для зберігання лише структурованих даних. Однак завдяки недавнім досягненням у сфері технологій механізмів баз даних стає все більш простим та більш здійсненним зберігання в базі даних та неструктурованих даних, таких як документи та зображення. Чи зберігати в базі даних всі або лише деякі з даних зовнішніх програм залежить від того, як ці дані використовуються.
У цій лекції розповідається про те, як зберігати налаштування додатків у базі даних. Крім того, ви дізнаєтеся, як маніпулювати налаштуваннями користувача, що зберігаються в базі даних. Оскільки XML є природним способом зберігання ієрархічних даних, наводяться також докладні відомості про XML-дані. На завершення розглядається зберігання у базі даних великих об'єктів, навіщо зазвичай використовуються окремі файли.
Де зберігати налаштування програм
У програмуванні на платформі .NET для зберігання даних програм зазвичай використовуються XML-документи (зазвичай з розширенням .config). Якщо необхідно, щоб програма демонструвала різну поведінку в різних ситуаціях, виникають складнощі. Необхідно або передбачити це у файлі конфігурації, або розглянути варіант із застосуванням архітектури параметрів, керованих даними, коли для налаштування програми використовуються дані. Якщо ви виберете останнє рішення, база даних буде природним місцем для зберігання даних,які керують налаштуваннями програми.
Незважаючи на недоступність в процесі запуску програми, збереження параметрів програми у базі даних може бути вигідним. У базі даних можна керувати доступом до параметрів за допомогою політики безпеки бази, в тому числі, використовуючи шифрування в SQL Server 2005. Це не дасть користувачам, які, можливо, не цілком уявляють наслідки змін, можливості змінити параметри. Якщо ви використовуєте будь-який варіант рольової моделі безпеки (див. лекції 2-3), можна контролювати, кому надається можливість змінювати окремі параметри програми. Збереження параметрів програми в базі даних буде також дуже корисним у розподілених додатках. Таким чином, ви зможете зберігати різні параметри, як часовий пояс або офісні правила, в одному місці - базі даних. Ці параметри можна налаштувати так, щоб програма зберігала різні версії налаштувань для різних користувачів або груп користувачів, а контролювати параметри зможуть працівники, які мають достатню кваліфікацію. У табл. 1.1 показані переваги, пропоновані кожним із двох варіантів.
| Користувач може легко змінити параметри | ? |
| Додаток не вимагає роботи ядра СУБД | ? |
| Параметри доступні під час завантаження програми | ? |
| У програмі можна реалізувати рольову модель забезпечення безпеки | ? |
| У програмі можна реалізувати централізоване керування параметрами | ? |
| У програмі можна легко обмежити доступ до параметрів | ? |
| У програмі може бути забезпечений гранулярний контроль над параметрами | ? |
Як ви вже зрозуміли із порівняння двох методів у табл. 1.1, слід вибрати той варіант, який краще підходить для вашої програми. Немає однозначної відповіді питання, де зберігати параметри програми - у базі даних чи конфігураційному файлі. Виважено оцініть свої потреби та середовище та використовуйте наведену тут інформацію для прийняття такого рішення, яке найкраще відповідає вимогам вашої програми.
Де зберігати налаштування користувача
Часто програмі необхідно зберігати інформацію про переваги користувачів. У веб-додатках це зазвичай реалізується за допомогою файлів cookie (невеликих текстових файлів, які зберігають інформацію про користувачів), але через збільшені вимоги до безпеки в інтернеті такий підхід може виявитися проблематичним. При використанні деяких видів ідентифікації користувачів налаштування користувача можна зберігати в базі даних. Це дозволить керувати цими параметрами, не звертаючись до клієнтського комп'ютера. У базі даних можна зберігати різні налаштування. Ці налаштування можна зберігати у вигляді XML-даних, які забезпечують максимальну гнучкість (про зберігання XML-даних буде розказано далі у цій лекції). Можна також використовувати стандартні методи роботи з даними для відстеження налаштувань користувача. Якщо для зберігання налаштувань користувача використовується SQL Server, то користувач може переносити їх з одного клієнта на інший.
Реалізація таблиці налаштувань користувача
- Визначте, які параметри потрібно зберігати. Хоча в базі даних програми можна зберігати всі налаштування користувача,важливо вирішити, які параметри необхідні для забезпечення функціонування програми в особливих випадках, а які параметри повинні бути доступними при будь-якому вході користувача в систему, з якого клієнта цей вхід не виконувався.
- Після того, як ви визначите, які параметри слід зберігати, розробіть необхідну для зберігання параметрів таблицю. табл. 1.2 являє собою приблизний проект таблиці для управління налаштуваннями користувача в базі даних.
| Ідентифікатор користувача | Зберігає унікальний ідентифікатор користувача, який може використовуватися для ідентифікації та повернення налаштувань користувача. Тип даних цього стовпця залежатиме від реалізації ідентифікаторів користувачів у додатку. |
| Дата додавання користувача. | У цей стовпець записується дата додавання Перший запис про налаштування користувача зазвичай створюється після додавання користувача. |
| Дата оновлення налаштувань | Допомагає керувати активними користувачами та перевіряти актуальність їх налаштувань. Оновлення даних часто важливіше, ніж їх створення. |
| Останній вхід до системи | Зберігає інформацію про останній вхід користувача до системи. У деяких випадках ця інформація дублює інформацію у стовпці Дата оновлення налаштувань. Залежно від реалізації стовпця дати оновлення, можна відмовитися від даного стовпця та використовувати лише стовпець Дата оновлення. |
| Стовпець або стовпці для зберігання налаштувань користувача | У цей стовпець записуються налаштування користувача, які необхідно зберегти. |
Існує дві поширені реалізації стовпців налаштувань користувача. Перша реалізація – реляційна. Кожне налаштування цієї реалізації зберігається в окремому стовпці таблиці. З цим рішенням пов'язана наступна проблема: щоб додати додаткове налаштування, доведеться розширювати таблицю шляхом додавання стовпця. Другий варіант - всі налаштування користувача зберігаються в одному стовпці. З появою XML можна використовувати документ XML для зберігання потрібних налаштувань або в стовпці TEXT , або в стовпці з типом даних XML; про це йтиметься далі в цій лекції.
Де зберігати XML-документи
Декілька років тому XML-документи були новим віянням, але зараз вони вже стали звичними. Цілком імовірно, що ви вже бачили та застосовували XML-документи для налаштування конфігурації та інших завдань у програмах, з якими працювали. У SQL Server 2005 та Microsoft .NET Framework XML-документи широко використовуються для налаштування параметрів конфігурації та реалізації інших функцій, таких як служби інтеграції SQL Server Integration Services (для яких XML зберігаються у файлах .dtsx ) та служби складання звітів SQL Server Reporting Services (дані XML зберігаються у файлах з розширенням . rdl ). XML має ряд переваг, не останнє з яких - гнучкість при зміні вимог до конфігурації програми. Як було зазначено раніше, файли XML також дозволяють користувачам програми легко змінювати параметри конфігурації.
Підтримка XML у SQL Server 2005
У SQL Server 2005 розробниками Microsoft до механізму бази даних було додано кілька нових специфічних XML-функцій. Ці вдосконалення дозволили полегшити доступ до XML-даних та маніпуляції з ними. Нижче наведено деякі з таких удосконалень: