0

We have an existing website which is written on one particular framework, we are halfway through a new version of this website and it's written on a different framework.

This means we have table structure which is now totally different. We have written code to migrate the old data to the new so members and content gets moved over no trouble. However we want to have x amount of people on the old site, and y amount of people on the new site.

This way we can test to see if people like the new site, how they use it etc, before we flick it 'live'. The new site will live at a different subdomain. But the real issue is, how can we get the databases working together, so if a user is on the new site, and post on the forum it shows on the old site, and vice versa.

Being different frameworks and tables, which seems like a very big job. We could have to write an interface for each model on both system, to handle updating the data on the other database. One developer threw around using triggers, so when data changes on this table, the trigger will update it on the other.

Both seem very long winded. I am talking about quite a bit of code, members, purchases, orders, blog posts, comments, forum topics + comments, plus a dozen or so other tables (+cms!).

ps, the solution should take weeks not months to do!

Does anyone have any ANY sort of suggestion at all, on how this could somehow be realized.

Cœur
  • 37,241
  • 25
  • 195
  • 267
Wizzard
  • 12,582
  • 22
  • 68
  • 101
  • I would either create a schedule that updates the old databases with data from the users on the new codebase to run at regular intervals, you could cron this easily enough - though the transformations may be nasty, or go with the suggestion of triggers. Have you considered not testing them side-by-side, but doing testing like a beta? IE, the data won't match up until the migration is compelte? By that, a thread started on the new site will not e available, but users on the new site can use all the features. When you are happy, migrate the old data to complete everything. – Fluffeh Aug 27 '12 at 01:25
  • Testing like a beta isn't going to give enough control, so they do want them side by side. That my was counter proposal, sync data from old site to new site every couple of days and people can play as much as they want... – Wizzard Aug 27 '12 at 02:34
  • You could run a cron even every hour (or more often) which might not be *too* bad. The other suggestion I was thinking of was to perhaps migrate a section of the site - say one forum category type of thing? So for *all* users, one particular forum sits on the new code, the rest sits on the old. – Fluffeh Aug 27 '12 at 03:03

1 Answers1

1

I do not think there is a straight-forward solution to what you are trying to accomplish. In a way, what you are doing is data duplication, and not database duplication. If it were database duplication you could have just done database server replication.

While you could write an interface for each model in the system, you will also need to handle situations like someone posted in forum in new site, while you are updating old site, someone else has already got forum updates in old site..so if you use any kind of key field dependencies, they will be different for the old site and new site, etc etc.

Its going to be a long-winded solution if you ask me. Because of the example that I gave above, even if the data can be duplicated using your interfaces, dependencies and relationships might have different key ids in both databases and when you finally decide to merge them together, you will need to take that into account as well..

If I were to do it, I would go the long route and write detailed update interfaces where I can see what data, when and how is getting updated across the databases. Might take more time to write but I think it would be safer and would save a lot of pain and time, were something to get messed up.

raidenace
  • 12,789
  • 1
  • 32
  • 35