Главная » Microsoft SQL Server, Базы данных » Простота или сложность

0

Недостаточное внимание к основным принципам архитектуры информации и остальным правилам хранения данных — это методология проектирования, которую я в шутку называю векселем. Если для программистов компании неудачный проект может в худшем случае закончиться увольнением или понижением зарплаты, то для независимого консультанта последствия более чувствительные — по векселю придется платить.

Как консультанту в области баз данных мне нравится участвовать в особо рискованных проектах — тех, которые клиент уже рассматривает как катастрофу (в случае, если он обжегся на услугах других консультационных компаний). В данном случае клиент просит меня завершить оставшиеся 10% проекта или оптимизировать его, если тот не в полной мере соответствует изначальным требованиям. И, как правило, причину катастрофы я нахожу в изначально обреченном на провал проекте.

Первый урок, который я вынес из доброго десятка провалившихся проектов баз данных, следующий: главной причиной неудач являются вовсе не малокомпетентные программисты, а излишне сложный проект. А все потому, что проектировщики базы данных не смогли (или просто не захотели) придумать более простое, элегантное решение задачи. Также несколько уроков я вынес из собственного опыта, когда мне приходилось платить по своим “векселям”.

Так называемый “антивексельный” принцип проектирования я могу сформулировать следующим образом.

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

Сложность

Одна сложность порождает другую сложность, что в конце концов вызывает проблемы. Наиболее распространенным результатом излишней сложности является полный провал проекта. Даже когда сложность кажется оправданной, она редко удовлетворяет конечной цели проекта. Сложность проекта также усложняет работу программистов в части понимания и реализации, что оттягивает сроки сдачи проекта.

Если проект уже реализован, сложность плохо сказывается на остальных шести правилах хранения данных (полезность, целостность данных, производительность, доступность, масштабируемость и защищенность). Сложная модель усложняет извлечение и обновление корректных данных, что влияет на их полезность и интеграцию. Дополнительные компоненты порождают излишнюю работу (чтение, объединение и обновления), взаимозависимые переменные, а также дополнительные сложности в настройке. Все это является причиной низкой производительности решений.

Сложная модель потенциально создает дополнительные точки сбоя. Когда такой сбой возникает, излишняя сложность маскирует источник проблемы, что, разумеется, усложняет и ее решение. Это приводит к удорожанию эксплуатации сложной системы. По сравнению с простой моделью сложную чрезвычайно тяжело адаптировать к изменяющимся условиям. И наконец, сложный набор компонентов уменьшает шансы надежной защиты данных.

Кстати, в тезаурусе синонимом слова “сложный” является слово “трудный”.

Простота

Простое решение элегантно и кажется очевидным, однако сказать, что поиск такого решения прост, все равно что, смотря в телевизор, думать, что медалисты олимпийских игр с легкостью устанавливают свои рекорды. В связи с этим хотелось бы процитировать Эйнштейна: “Вещи нужно делать как можно более простыми — но не проще этого”.

Фразу “как можно проще” нельзя рассматривать как односложный ответ на вопрос. Простейшее решение должно быть самым простым среди тех, которые полностью удовлетворяют требованиям поставленной задачи, — оно обречено на определенный уровень сложности. Простота измеряется количеством компонентов, техническими составляющими, внутренним интерфейсом и технологиями, вовлеченными в решение.

Разработка простого решения в какой бы то ни было области — очень сложная задача, которая требует следующих составляющих:

?               полное понимание требований задачи;

?               широкий выбор моделей и решений;

?               полное понимание технических правил и нюансов предметной области;

?               творческий подход и профессионализм;

?               полное знание физических средств и материалов, используемых в проекте, а также среды, в которой решение должно функционировать;

?               достаточный уровень доверия в команде разработчиков, позволяющий идеям развиваться и видоизменяться только на основе их ценности, а не на основе личных амбиций и заслуг их создателей;

?               соглашение о том, что разработка будет продолжаться, пока не будет найдено самое элегантное решение;

?               разумная боязнь сложности.

При разработке проекта за несколько часов или дней совещаний можно выработать идею, которая позволит избежать массы проблем, ранее казавшихся непреодолимыми. Любое оправданное уменьшение сложности значительно сократит усилия на реализацию проекта и повысит шансы получить действительно работоспособный продукт. Каждый лишний рубль, вложенный в процесс проектирования, окупится сторицей в процессе реализации и, тем более, эксплуатации продукта.

Простота именования объектов является одной из составляющих общей простоты модели базы данных. Из собственного опыта знаю, что если команда разработчиков уловит эту простоту, то существует большой шанс успеха всего проекта. Если команда не ценит простоту, я не хотел бы работать в ней.

Источник: Нильсен, Пол. Microsoft SQL Server 2005. Библия пользователя. : Пер. с англ. — М. : ООО “И.Д. Вильямс”, 2008. — 1232 с. : ил. — Парал. тит. англ.

По теме:

  • Комментарии