[nycphp-talk] talk Digest, Vol 41, Issue 5
Gary Mort
garyamort at gmail.com
Tue Mar 9 13:47:51 EST 2010
On Tue, Mar 9, 2010 at 11:50 AM, Mitch Pirtle <mitch.pirtle at gmail.com> wr
>
> Seriously though: Take whatever popular PHP CMS you might have laying
> around, and consider what it would take to migrate content from one
> existing website to another website that also already has its own
> content... I'm willing to bet all that data is "unique" to a bunch of
> incrementally selected, absolutely meaningless integers.
>
Content doesn't worry me. What gives me fits are configurations.
Content is easy to migrate, add 100 or 1000 to all the id fields of the
source data, set a new auto-increment number on the target database to be
higher than the highest number. Export, import, call it a day.
But when you have a bunch of keyword lookup fields and have tied all THAT
together by id numbers...that can get...interesting.
Especially when your mapping one set of string data to another and half of
them don't directly correlate.
Now there I can see a good argument to forgetting the id mapping to the
keyword table. Instead, you build the a keyword table with just the
keywords themselves.
It means a little more work when you have to change a keyword because
company A changed their name to Z... so every record with an A in it has to
be updated[or maybe you cheat and include a second column in your keyword
table, "formerly known as" - and whenever a record is retrieved that does
not have a match in the parent table, you go out and grab the parent...
That works well for speedier migration/changing. It runs into problems
when you have 2 keywords that where reworded a number of times and at
different points in time they both shared the same label.
It also means a lot more work in documenting your database.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nyphp.org/pipermail/talk/attachments/20100309/08344bbd/attachment.html>
More information about the talk
mailing list