YAGNI и сценарии создания базы данных

Question

Прямо сейчас у меня есть код, который создает базу данных (всего несколько запросов CREATE для базы данных SQLite) в моем классе доступа к основной базе данных. Это кажется ненужным, так как я не собираюсь когда-либо использовать код. Я бы просто нуждался в этом, если бы что-то пошло не так, и мне нужно было воссоздать базу данных. Должен ли я ...

1. Оставьте все как есть, даже несмотря на то, что код создания базы данных составляет около четверти моего размера файла.
2. Переместить код создания базы данных в отдельный скрипт. Скорее всего, я буду запускать его вручную, если мне когда-нибудь понадобится запустить его снова, и это исключит его из виду при работе с основным кодом.
3. Удалите код создания базы данных и положитесь на контроль версий, если мне когда-нибудь понадобится его снова.

Answer 1

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

Воссоздание базы данных - абсолютно не исключительный случай.Этот код является частью вашего процесса развертывания в новой / другой системе и представляет структуру БД, с которой ваш код ожидает работать.На самом деле вы должны иметь интеграционные тесты, которые подтверждают это.Работа на неопределенный срок с одним сервером БД, схема которого была создана постепенно с помощью вручную отправленных операторов SQL во время разработки, это , а не , то, на что вы должны полагаться.

Но да, его следует отделить от кода доступа.;так что вариант 2 правильный.Затем отдельный скрипт может использоваться как для тестов, так и для развертывания.

Answer 2

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

Это важно по следующим причинам.

1. Вы, вероятно, будете удивлены тем, какмного раз вам это нужно.Если вам нужно перенести сервер или настроить другую среду (например, TEST или DEMO) и т. Д.
2. Я также обнаружил, что при кодировании я часто обращаюсь к DDL SQL, особенно если я не коснулсясистема на некоторое время.
3. У вас есть справка о принятых вами решениях, таких как созданные вами индексы, уникальные ключи и т. д. и т. д.

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