We have a database which we obtained via a crawling, where every row contains a primary key
X, and an unique number
Y obtained from the crawling procedure (the primary key of the original source). For historical reasons, we are using
X to create the URLs of each object (e.g.
This database was in Mysql, and we are migrating the data to Postgres. To that end, we decided to crawl the original source from scratch (for other reasons considered) to the new database. This means that we now have a new primary key
Z associated with the unique numbers
The problem is that if we migrate the database on production, the links become
http://example.com/object/Z, which point to a different object than
X!=Z => different
Naturally we don't want this to happen since 1. search engines will point to the wrong object and 2. old links pointing to object
X1->Y1, start point to object
Z1->Y2 != Y1.
This problem already suggests that we want URLs constructed from
Y. The question now is how to make this migration.
I see two approaches to the problem:
using the old database, create a redirect of the link to a link that only depends on Y
http://example.com/object1/Y, wait 1 month, and then migrate the database along with a change in the URLs to the ones using
create a new column in the new database
old_pk, and perform a migration from the old database to the new database, by inserting the old
Xto the row with equal
Y, and then to
http://example.com/object_/Y(to avoid these problems in the future)
The 1. has the disadvantage that the whole production has to wait for the links to migrate, and will not maintain old URLs for eternity. 2 has the disadvantage it will take time to migrate since the database contains +600.000 entries, and the new database will contain legacy data. I'm more inclined to 2., but I would like a second opinion:
- does this reasoning makes sense?
- are there other approaches that we are not seeing?