Обновление базы данных

Question

Как часто вы обновляете свою базу данных разработки из производственной базы данных? Поскольку существует много типов проектов (нацеленных на разные домены), я хотел бы знать, как это делается и с какими интервалами (днями / месяцами / годами) это происходит. делается?

спасибо

Answer 1

Ключевые моменты при обновлении вашей базы данных разработки:

(1) Автоматизируйте обновление с помощью скрипта.

(2) Запутайте данные в своей базе данных разработки, поскольку вы не хотите, чтобы ваши разработчики видели реальные данные, или вы могли бы сделать выборку из вашей производственной базы данных.

(3) Определите частоту обновления - я обычно делаю это раз в неделю.

Answer 2

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

Answer 3

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

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

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

Если у вас есть данные с какими-либо проблемами безопасности, вам следует прекратить использовать производственные данные - т.е. никогда не обновлять с производства - и получить хороший генератор данных образца. Писать хороший генератор образцов данных сложно, поэтому сторонние продукты - это путь. На ум приходит MS Data Dude, и я рекомендую генератор данных Sql RedGate.

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

Answer 4

Совсем нет, базы данных dev (по одной на разработчика) настраиваются с помощью сценария или аналогичных программ пару раз в день, возможно, пару сотен раз при локальном запуске db-тестов. Это включает в себя пару записей для игры вокруг

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

Answer 5

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

Answer 6

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

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

Answer 7

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

Наша производственная база данных составляет около 1 ГБ, поэтому копировать ее не так просто. Кроме того, для нас, как правило, нет необходимости загружать текущие данные из производства в системы разработки.

«Как» - это просто «резервное копирование» и «восстановление» MySQL