Реляційне відображення об'єктів(Object Relational Mapping)

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

2. Необхідно розглянути можливість використання середовища( frame- work), яке підтримує об'єктне/реляційне відображення між сутностями сфери застосування і базою даних.

3. При роботі з невеликими застосуваннями може використовуватися ша- блон доступу до даних Сховище(Repository).

4. При роботі з Web - застосуваннями або службами необхідно підтриму- вати можливість завантаження тільки необхідних даних - ледаче заван- таження(lazy loading).

Запити

Запити є основним механізмом оперування даними на рівні даних. Запити є механізмом перетворення команд застосування в дії з виконання CRUD опе- рацій у базі даних.

1. Переважне використання що параметризуються запросоы SQL і пара- метрів, що типізуються, щоб уникнути атак SQL injection. Слід уникати злиття рядків при побудові динамічних запитів з призначених для кори- стувача вхідних даних.

2. Бажане застосування об'єктів для побудови запитів.

3. При побудові динамічних SQL запитів необхідно уникати змішення бі- знес-логіки і логіки, використовуваною для побудови запиту.

Процедури, що зберігаються

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

• Необхідно уникати створення тимчасових таблиць при обробці даних. Якщо це необхідно переважно створення тимчасової таблиці в пам'яті а не на диску.

• Слід проектувати обробку помилок і повертати значення, які можуть бути оброблені кодом застосування.

Транзакції

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

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

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

При проектуванні транзакцій треба керуватися наступними рекомендаціями:

• Використайте транзакції тільки у разі потреби. Ретельно продумайте межі транзакції, щоб забезпечити можливість повторних спроб і компози- ції. Можливо, для простих запитів явна транзакція не потрібна, але ви по- винні переконатися, що не порушуєте стандартної поведінки завершення і ізоляції транзакції для бази даних. За умовчанням база даних Microsoft SQL Server® виконує кожне SQL- вираження як окрему транзак- цію(режим автоматичного завершення транзакції).

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

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

• При використанні класів простору імен System.Transactions рекоменду- ється застосовувати модель неявних транзакцій, що забезпечується об'єк- том TransactionScope(Зона дії транзакції) простору імен System.Transactions. Неявні транзакції виконуються не так швидко, як транзакції, створені вручну, або явні, але їх простіше реалізовувати, і вони забезпечують гнучкі і прості в обслуговуванні рішення проміжного шару. Створювані вручну транзакції краще реалізовувати в процедурі, що збері- гається.

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

• Якщо вимагається виконувати безліч запитів до бази даних, розглянете можливість застосування безлічі активних результуючих наборів(multiple active result sets, MARS), що забезпечить підтримку безлічі результуючих наборів тільки для пересилки і тільки для читання і дозволить виконувати безліч запитів з використанням одного підключення. MARS можуть бути корисні в застосуваннях з паралельною обробкою безлічі транзакцій.