Постепенный переход на новую схему базы данных. ¿Предложения? - PullRequest
6 голосов
/ 07 августа 2010

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

Я работаю в компании, которая предоставляет информацию о телевизионных программах для гидов, газет и веб-сайтов.

У меня есть старая система, которая имеет несколько ограничений и заменяется новой.

Различные клиенты принимают данные в разных форматах (xml, sql, txt, даже готовый к печати PDF) и разными способами (push, pull, частичные дампы, простой экспорт, экспорт с помощью человека - как в PDF-версии - и т. Д.),Некоторые экспортные операции создаются один раз в месяц, другие - чаще, чем раз в день.

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

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

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

Мы собираемся начать разработку новой системы с использованием Symfony сДоктрина, и я решил, что мы могли бы разработать набор прокси-классов ORM, которые должны иметь то жеИнтерфейс, чем простой набор классов Doctrine ORM, но поддерживает синхронизацию между двумя другими наборами классов (теми, которые взаимодействуют с новой системой, и теми, которые взаимодействуют со старым).В конце концов старую БД следует отбросить вместе с прокси-классами, и классы Doctrine ORM, которые подключаются напрямую к новой БД, должны занять это место, как если бы старая система никогда не существовала.

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

1 Ответ

1 голос
/ 07 августа 2010

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

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

...