Миграция данных с В спящем режиме

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

У меня есть был чрезвычайно доволен результатами сценария python, набора SQL и некоторых объектов python для преобразования данных.

Hibernate не очень хорошо работает с хранимыми процедурами - это не «естественная посадка». Если ваш ORM уже нанесен на карту, и у вас есть объекты «как есть» и «как будут», используйте обычные методы гибернации для записи данных в новый макет.

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

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

Хотя я не уверен в «лучшем», я бы предпочел использовать Hibernate или подобный ORM, если бы я был на вашем месте. Причина в том, что тогда у вас есть иерархия объектов для использования между двумя базами данных. Если схемы очень похожи, тогда может быть проще простой сценарий SQL. Это действительно зависит от вашей ситуации и ее специфики.

edit: Мне действительно нужен утренний кофеин ...

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

Лично я, вероятно, использовал бы инструмент ETL, такой как SSIS (если вы переходите с или на SQL Server) для этого, перемещение больших объемов данных - это то, что инструменты ETl разработаны и оптимизированы для выполнения .

Я пытался управлять миграцией данных, поскольку менял свой код и представление данных в различных выпусках. Каждый раз мне приходилось писать определенный sql для запроса объектов в старом состоянии и для заполнения новых столбцов. Если есть простой способ управлять миграцией данных, просматривая все как объект, я об этом не думал, и до сих пор новые столбцы всегда имели простые интерпретации, которые я мог вычислить в sql.

Некоторые из них были достаточно простыми, чтобы код оказался на java, а другие изменения были достаточно сложными, чтобы мне понадобилось несколько операторов sql, поэтому я в конечном итоге встраивал их в оболочку и python (оба для переносимости) скрипты. Сценарии здесь и java-код с такими именами методов, как updateDB2008_4 ().