1

I have a users table with an auto-increment id and also a unique alphanumeric pid. Only pid is publicly exposed, since I dont want hackers gaming the system by running a for loop over id and extracting all users data.

Question is, do I even need to store auto-increment id in the first place? I need to choose a foreign key for other user related tables like user_details, user_orders etc. Should I use pid or numeric id as fk?

Some concerns:

  • Joins - Will joins using id be more efficient than pid?
  • Indexes - Will indexing id be faster than indexing pid?
  • Transactions - Are transactions, involving multiple atomic inserts, feasible when pid is used as foreign_key?
jerrymouse
  • 16,964
  • 16
  • 76
  • 97
  • 1
    This may be of interest : http://stackoverflow.com/questions/332300/is-there-a-real-performance-difference-between-int-and-varchar-primary-keys – PaulF Aug 18 '15 at 11:14

1 Answers1

1

Basically, the answers are "yes", "yes", and "yes".

Presumably, an alphanumeric key would be many bytes and an integer would be just 4 bytes (or 8 for a bigint). Foreign key values are stored in any index where they are defined, so short values are good. Also, having a key that is always the same length is good.

You don't mention where your pid would come from. For instance, a UUID (which is just a bit string) is 16 bytes versus 4 bytes for a string. This would occupy more space in any indexes, although it could be used.

More importantly, your concern here is security. I think having one id facing users and another inside the database provides an additional layer of security. You could, for instance, have a high level of security around the conversion from the PID to the ID (an encrypted, logged, secure interface).

The PID would never be in the actual data, so getting full copies of many tables might still not identify users, assuming that you follow good practices on the contents of the tables.

Gordon Linoff
  • 1,242,037
  • 58
  • 646
  • 786