29 декабря 2010 г.



Несколько мыслей о проектировании работы приложений с данными

Совсем недавно писал о решении довольно непростой задачи, связанной с некорректной работой слоя данных. Изменения затронули самое «сердце», фундамент приложения. В связи с этим решил запомнить для себя парочку важных прикладных мыслей относительно работы с хранилищами данных. Ведь, пожалуй, любой IT-проект таковое имеет - поэтому не хочется сталкиваться с подобными проблемами в будущем.

1) Модель данных должна быть предельно простой и лаконичной. Это важно в виду многих причин. Простую модель проще понять и, соответственно, разработчикам проще с ней работать и строить на ее основе необходимую бизнес-логику. С технической точки зрения простая модель проста и в своей реализации. Не нужно рекурсий и сверхглубоких вложений объектов друг в друга. Не нужно обилия связей, особенно это касается связей типа «многий ко многим». Понятно, что не всегда возможно этого избежать. Где-то прикладная область диктует свои правила и создает дополнительные ограничения. Но во всех остальных случаях простота модели вполне достижима.

Почему важна простота реализации? А потому, что в большинстве проектов обязательно используются одни и те же связки уже готовых компонентов для представления слоя данных. Это СУБД плюс какое-нибудь ORM решение, если говорить о разработке с помощью объектно-ориентированной технологии программирования. Иногда эти готовые решения хорошо справляются со сложными взаимоотношениями объектов, но иногда, как показал наш случай, не очень. Когда случится это «не очень» никто не знает. Но с уверенностью можно сказать, что проблемы в этом случае вам обеспечены. Как минимум придется провести N-ое количество часов в попытках понять работу этого черного ящика под названием ORM+СУБД. Или надеяться на помощь со стороны поставщика готового решения. В любом случае все это ставит успешное завершения проекта в срок под угрозу.


Поэтому разработке дизайна основной модели данных нужно уделить достаточное время. Лучше запланировать это как отдельную задачу в начале проекта и подвергать постоянному обзору и рефакторингу впоследствии. Методология Feature Driven Development даже выделяет для этого отдельный этап.

2) Подумайте о масштабах заранее. Продолжая тему разработки основной модели данных, надо не забывать о планируемых масштабах катастрофы вашего проекта. Что будет если вот таких объектов будет тысяча? или десятки тысяч? Оптимальна ли разработанная модель в этом случае? Получится ли ввести кластеризацию, если она будет необходима? Справятся ли с нагрузкой выбранные вами компоненты?

Нужно обязательно задать себе эти и другие, зависящие от конкретной ситуации, вопросы. Задать их заранее. Иначе велика вероятность, что со временем ваше приложение придется окружать строительными лесами и всевозможными подпорками. Или со временем станет очевидно, что выбранные технологии не справляются с нагрузкой. Тогда, выбрав новую подходящую технологию, вас скорее всего ждет веселье миграции данных. Думаю, кто сталкивался - понимает, что эта задача не так тривиальна как может показаться на первый взгляд.

3) Данные должны быть в безопасности. Как правило, хранилище данных - основа всего приложения. Без них оно не имеет для пользователей никакой ценности. Понятно, что нужно обеспечить резервное копирование и хранение. Но в первую очередь нужно обеспечить их целостность. Если ваши данные представляю собой кашу, то сколько резервных копий не имей - толку от них мало.

Как правило, целостность данных обеспечивается на уровне СУБД, иногда на уровне ORM и может обеспечиваться на уровне приложения. Обычно, мы не можем влиять на первые два уровня, если, конечно, вы не разработчик этих самых СУБД или ORM решений. Зато мы можем полностью повлиять на сохранение целостности на уровне своего приложения. Не нужно этим пренебрегать и надеяться на механизмы сохранения целостности хранилища данных. Проверяйте наиболее критичные данные самостоятельно на уровне приложения и бейте тревогу как только появились подозрения.

Никакая СУБД не знает прикладной стороны вашего приложения. Проверяйте, что ваши данные связаны не только механически, но по смыслу. Вы ведь владеете прикладной областью, правда?

4) Не стоит использовать разные СУБД в рамках одного приложения. Понятно, что иногда без этого не обойтись. Но если этого можно избежать - приложите усилия. Я на этом обжегся.

Мы используем на проекте две СУБД: MySQL и Apache Derby. В результате мы создали себе много дополнительной работы, которую могли бы не делать: миграции данных, импорт/экспорт  данных с помощью универсального формата DDL, поддержка и ветвление на уровне кода из-за различий в реализациях стандартов. Кроме того, Apache Derby то и дело подкидывала (и время от времени продолжает это делать) свои собственные проблемы, решить которые было не так-то просто ввиду на порядок более слабой поддержки и сообществу.

Если такой вопрос поднимается у вас на проекте, примите решение максимально осознанно. Соотнесите эффект от решаемых таким образом задач и затрат времени на поддержку. И да, выбирайте максимально надежных поставщиков СУБД :)

5) Модель данных должна быть предельно простой и лаконичной! Пожалуй, это главная мысль, которую вынес для себя я. Она во многом влияет на другие приведенные здесь аспекты разработки слоя работы с данными. Повторяю эту мысль здесь:
- во-первых, исключительно для себя, не обращайте внимания
- во-вторых, пять пунктов всегда смотрятся лучше чем четыре :-)

Всем удачных разработок в новом году!

-



Понравилось сообщение - подпишитесь на блог Подписка на блогFollow grodnosoft on Twitter




Читайте также:


Комментов: 0

Отправить комментарий