views:

246

answers:

2

Are there any gotchas to using a non-integer column for the id in an ActiveRecord model? We're going to be using replicated databases, with copies of a Rails app writing to those databases in different datacenters. I'm worried that with normal IDs we'll get collisions between newly created rows in different datacenters.

Our DBA has suggested just initializing the identity columns with different starting points for each of the different databases/datacenters, but over time those will eventually overlap and end up colliding (the particular table I'm worried about is going to be very high traffic). I'm sure it would work great for a while, but I don't want to be the one to debug what's wrong when things start to go wonky 2 years down the road.

I'd like to just replace the id columns with GUIDs. The database can generate them transparently, just as the id is normally generated. MS guarantees that they won't collide between our different databases. The downside there is that I have to make sure Rails isn't going to barf on id columns that aren't integers.

Has anyone else tried something like this? How much of the ActiveRecord plumbing did you have to change?

+1  A: 

Just a pointer

create_table :blah, {:id => false} do |t|
  t.string :my_string_id
end
execute "ALTER TABLE blah ADD PRIMARY KEY (my_string_id);"
marcgg
A: 

In case it is a problem to use something else than the default for Rails ID (which I don't know), another possibility would be to just keep the default auto-increment integer ID for general Rails use in your local app, but also have a GUID field that you'd use when you want to do multi-database stuff. So when doing an insert from one DB to the next, you'd specify the GUID and let the other DB generate its own auto-increment.

JRL