База даних як Фортеця

Ден Чак

У базі даних зберігається вся інформація – як вводиться співробітниками, так і отримана від клієнтів Користувача інтерфейси, бізнес-логіка і прикладна логіка (і навіть співробітники) приходять і йдуть, а дані залишаються Важко висловити словами те, наскільки важливо в перші ж дні роботи над проектом побудувати надійну модель даних

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

У той час як бізнес-логіка й користувальницькі інтерфейси еволюціонують досить швидко, структурам даних і їх відносинам це зазвичай не властиво Отже, дуже важливо з самого початку чітко визначити модель даних як на структурному, так і на аналітичному рівнях Міграція даних з однієї схеми в іншу «на місці» в кращому випадку складна, завжди займає багато часу і часто чревата помилками Якщо з помилками рівня програми ще можна якийсь час миритися, помилки в базі даних можуть привести до катастрофічних наслідків Навіть якщо ви знайшли і виправили помилку проектування на рівні даних, це не відновить пошкоджену інформацію

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

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

Щоб витягти з реляційної бази даних максимальну користь, тобто зробити її повноцінною частиною програми, а не просто сховищем даних програми, необхідно з самого початку добре розуміти, що ж ви створюєте У міру розвитку вашого продукту буде вдосконалюватися і рівень даних, але в кожній фазі розвитку він повинен зберігати свій статус Фортеці І тоді ви зможете довіритися йому і з упевненістю покласти на нього відповідальність за перехоплення помилок з інших рівнів додатки – і він вас не розчарує

Ден Чак (Dan Chak) – директор з розробки ПЗ в CourseAdvisor Inc, Компанії Washington Post Є автором книги «Enterprise Rails» (О * Reilly)

Джерело: Форд Н, Найгард М, де Ора Б, 97 етюдів для архітекторів програмних систем – Пер з англ – СПб: Сим-вол-Плюс, 2010 – 224 с, Мул

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


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

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

Ваш отзыв

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

*

*