Делая TDD и добавляя функции постепенно, я планирую базу данных заранее или добавляю таблицы и столбцы во время кодирования?

Question

Одна из наиболее важных возможностей, которую TDD дает нам, с моей точки зрения, - это постепенное развитие проектов, добавление функций по одной, что означает, что в идеале у нас есть работающая система в любой момент времени.
Кто яСпрашивается, когда проект включает в себя работу с базой данных, можем ли мы использовать этот инкрементальный подход для создания структуры базы данных или мы должны проработать структуру до начала написания кода? Я знаю, что трудно предсказать, какова структурабаза данных будет примерно через 1 год, но в целом, какова ее лучшая практика?

Answer 1

Преимущество TDD и YAGNI заключается в том, что оно явно решает проблему, которую мы, как разработчики, не можем предсказать будущие требования. Это так же верно для проектирования реляционных баз данных, как и для объектно-ориентированного кода.

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

Answer 2

Для меня это вопрос с «теоретическим» ответом и «реальным миром».

Теоретически вы добавляете столбец по мере необходимости и реорганизуете свою базу данных по мере продвижения, потому что это гибко.

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

Как отметил Скаффман в комментарии: обслуживание базы данных обычно обходится дороже, чем обслуживание кода. Это вдвойне верно для развертывания: вы можете без проблем выкатить целое новое приложение, но попробуйте планировать обновление базы данных в реальном времени, не нарушая ваши данные.

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

Роль архитектора (или технического руководителя, или главного администратора баз данных, или любого другого вкуса) состоит в том, чтобы смотреть в будущее в течение этих нескольких месяцев и планировать то, что, как вы уверены, будет на 90%, и часть этого будет определять данные, которые вам понадобятся, и где они будут жить.

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

Answer 3

можем ли мы использовать этот инкрементальный подход для создания структуры базы данных или мы должны проработать структуру до начала написания кода?

Да, вы можете (посмотрите на Эволюционный дизайн базы данных Фаулера ). И нет, вы не должны работать над структурой заранее (это BDUF). Скотт Эмблер также много писал об этом и о методах, которые позволяют применять его в реальной жизни. Проверьте Agile Database Techniques , Рефакторинг баз данных: эволюционный дизайн баз данных и Процесс рефакторинга базы данных: стратегии повышения качества базы данных например

И, как я сказал в комментарии, если ваш администратор баз данных не любит (если он работает с моделью и данными, как Голлум с драгоценностями), приобретите другого администратора баз данных, который понимает работу Фаулера и Амблера. Период.

Answer 4

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

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

Единственная причина, по которой вам нужно было бы «рефакторизовать» схему СУБД, заключается в том, что первоначальный дизайн был prima facie неприемлемым для любого компетентного глаза. Теперь некоторые табличные пространства или индексацию, возможно, придется настроить, но это не имеет никакого отношения к дизайну.

Answer 5

Ответ здесь довольно очевиден, насколько я понимаю.

Вы проектируете структуру базы данных. В некоторой степени TDD - это не тестирование логики (логики в голове), а тестирование реализации и обеспечение ее согласованности.

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

Итак, прежде чем писать какой-либо код, вам нужно иметь эту «вещь», чтобы знать, что будет делать ваш код. Таким образом, тривиально следует, что вы сначала создаете БД, а затем пишете код для ее проверки.

Возможно, при тестировании будет показано, что вы что-то забыли. Хорошо, это хорошая подходящая; поэтому вернитесь и добавьте его, а затем продолжите тестирование.

Answer 6

Для уменьшения сложности рефакторинга базы данных в соответствии с кодом, который генерирует TDD, можно использовать несколько подходов. Рассмотрите возможность создания базы данных из классов, которые вы создаете как часть процесса TDD.

Другой возможностью является создание базы данных, тестовых данных и, возможно, даже базового кода хранилища из концептуальной модели базы данных с использованием инструмента, подобного NORMA . «ORM» здесь - это Object-Role Modeling («другое» ORM), а NORMA - это надстройка Visual Studio, которая может генерировать DDL и код из концептуальной модели.

Приятно то, что даже если концептуальная модель существенно меняется (например, отношение становится многим ко многим), то и код, и DDL изменятся, чтобы отразить это.