Это лучше всего рассматривать как два отдельных предмета. С одной стороны, вы хотите иметь надежную и непротиворечивую схему базы данных (таблицы, индексы, метки, процедуры, функции, а также значения поиска и любые неизменяемые «статические» данные, необходимые вашей системе), и вам нужен контроль версий над этим. так что вы можете отслеживать, что меняется со временем (и кем), а также можете контролировать, когда изменения будут применены к каким экземплярам базы данных. Предыдущие сообщения на этот вопрос хорошо освещали эту тему.
С другой стороны, вам понадобится база данных, заполненная данными, по которым вы можете протестировать и разработать новый код. Определение и загрузка таких данных - это не то же самое, что определение и загрузка структур, в которых они будут храниться. Хотя управление определениями базы данных через систему контроля версий может быть легко решаемой проблемой, за последние много лет я никогда не слышал о столь же простом (ну, относительно простом) решении для решения проблемы с данными. Аспекты проблемы включают в себя:
Убедитесь, что данных достаточно. Добавление 10-20 строк в таблицу легко, но вы не можете предсказать производительность, если ваши действующие базы данных будут содержать миллионы или более строк.
Быстрое и простое решение состоит в том, чтобы получить копию самой последней производственной базы данных, обновить ее с последними изменениями, и все готово. Это может быть сложно, если в среде разработки нет SAN, на которой можно разместить копию данных Multi-TB производства, которые вы поддерживаете
Аналогичным образом, аудиторы SOX и / или HIPAA могут не захотеть получать дополнительные копии потенциально конфиденциальных данных, которые хранятся на не слишком защищенных серверах разработки (в отличие от не столь защищенных разработчиков - мы ненадежная группа , в конце концов). Возможно, вам придется скремблировать или рандомизировать конфиденциальные данные перед тем, как сделать их доступными для разработчиков ... что подразумевает временный процесс "скремблирования" для очистки данных. (Возможно, еще один SAN для всех этих туберкулезов?)
В некоторых ситуациях было бы идеально, если бы какой-то департамент или другой отдел предоставили вам правильный, согласованный и скоординированный набор данных для разработки, который они составляют, чтобы охватить все вероятные возможные ситуации. и что они могли бы использовать для тестирования на своей стороне (зная, что входит, они знают, что должно выходить, и могут проверить это). Конечно, усилия по созданию такого набора данных существенны, и убедить не-ИТ-группы предоставить такие наборы данных может быть политически невозможно. Но это хороший сон.
И, конечно, данные меняются. После того, как вы отработали копию в процессе разработки в течение недели, месяца, квартала, в конце концов, и неизбежно вы обнаружите, что производственные данные больше не «выглядят» так: модели использования будут изменены, в среднем значимые значения будут дрейфовать, все ваши даты будут старыми и неактуальными ... что угодно, вам нужно будет заново получать свежие данные.
Это ужасная проблема без простого решения, о котором я когда-либо слышал. Одна возможность, которая могла бы помочь: я помню, как читал в прошлом статьи о продуктах, которые можно использовать для «наполнения» базы данных составленными, но статистически значимыми данными. Вы указываете такие вещи, как «10000 строк в этой таблице, этот столбец является первичным ключом идентификатора, этот tinyint колеблется от 1 до 10 с одинаковым распределением, этот varchar составляет от 6 до 30 символов с, возможно, 2% дубликатами» и так далее. Нечто подобное может иметь неоценимое значение, но все зависит от обстоятельств, в которых вы оказались.