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

Ответ 1

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

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

Ответ 2

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

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

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

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

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

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

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

Ответ 3

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

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

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

Ответ 4

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

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

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

Ответ 5

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

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

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

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

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

Ответ 6

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

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

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