CODEWITHSUNDEEP
sqldatabasepostgresql
stonefree
stonefree

Reputation: 45

Primary keys: is it bad practice to use a UUID for some tables and INT for other tables in the same database?

I'm creating a well-normalized database in postgresql and for a couple tables I need the ability to generate the PK from the client side. I'm also interacting with another database so the UUIDs will be helpful in that regard as well. For consistency I was going to use UUIDs in every table, but I'm having second thoughts since it seems like overkill for most of my tables. I thought that maybe I would use integer PKs for those tables and UUID PKs for the 'special' tables, but it feels a bit strange to me. Is this bad practice?

Upvotes: 1

Views: 1664

Answers (1)

Gordon Linoff
Gordon Linoff

Reputation: 1269953

I cannot think of a reason why it would be a bad practice. Unusual yes. But if you have a reason for preferring integers in some cases and UUIDs in others, then it might make sense.

I prefer integer for primary keys. They occupy less space -- which can be a consideration if many other tables are using them. I find that they are easier to type correctly and compare visually when looking at values.

However, they also encode some information, typically the order of insertion into the the table. That is a double-edged sword. It may be a good thing if you want to keep track of insertion order. Or, it may be a bad thing if you don't want people to estimate the size of your table.

When I have UUIDs, I might also have integer primary keys, keeping the UUID in a separate unique column. That allows for efficiencies in foreign key references.

Upvotes: 3

Related Questions