Think carefully before using an automatically-generated unique ID as a primary key in a SQL table. Using such automatically-generated IDs introduces extra implementation detail. This is a pain to manage, especially if they are used as primary keys or worse, foreign keys in tables.
The best use for them is in a non-primary key field, with a uniqueness constraint on them. This allows quick and easy reference to a particular row. For example, you could retrieve rows with a complex query, keep the UIDs, and then use the UIDs to delete or update the rows. Note that such fields are generated automatically by some databases, e.g. Oracle’s ROWID pseudocolumn.
Using them as foreign keys means it is very likely they will leak out of the database layer into the business layer. This complicates the business logic with no benefit.