If you use random UUID's (as opposed to sequential UUID's) for your primary key your database will spend an extra hunk of time on reordering your PK index on disk on insert. This bit us at Stackoverflow. So remember: just because you can do something doesn't mean you should.
(Keeping in mind that both can be started at N on different shards, or prefixed.)
create_table(:users, id: :uuid) do |t|
t.string 'name'
end
And to make sure the extension is enabled, (in your migrations) do: enable_extension 'uuid-ossp'
For now, make sure to use SQL schema dumping. I don't think Ruby schema files will work (as I haven't written a test for it yet).EDIT: I forgot to mention, you can enable hstore by using "enable_extension('hstore')"
What is the value of this? Why can't unique identification be done using just regular increments on an ID column? Or even a composite key?
The cost? The keys are larger, and (unless using a sequential algorithm) are poor candidates for clustered keys (because they force page splits). The impact can be rather large (this lead to terrible performance in early versions of Sharepoint).
The downside of this is that it can leak information about the machine that generated the UUID, but if you require deterministic uniqueness, there you go.
t.primary_key :id, :type => :uuid $ rails g migration add_uuid_to_postgresql
class AddUuidToPostgresql < ActiveRecord::Migration
execute("CREATE EXTENSION uuid-ossp;")
end
$ rake db:migrate && rake db:test:prepare
Then create a table as shown in the article, and it should work.Does anyone consider this an issue? I have been using non-superuser roles within my Rails apps, and using an outside superuser role to add extensions with an external tool (like pgAdmin).
enable_extension 'uuid-ossp'Also, if it's not sequential, you may miss records while iterating through a collection.