which one is better composite pk or using natural keys in blacklist design

Question

i am going to design my blacklist and favorite in php list which user can blacklist and favorite other persons and now i just want to know is it better to design like this

+-----+------+------------+
| uid(pk) | name | family |
+-----+------+------------+

and another table like this which is composite primary key

+-----+------+------------------------+
| uid(pk) | blacklisted_person_id(pk) |
+-----+------+------------------------+

or desgin with primary key and foreign key in it, which i dont know how to design in this case that user cant blacklist himself or blacklist some person 2 times.if someonce can describe it a little ill be grateful. thanks in advance

Answer 1

Your solution is good, but I'd recommend just calling your PK in your user table just id not uid and then in your mapping blacklist table refer to it as user_id (if user is the name of the user table) and blacklisted_user_id . That way there is no ambiguity to what table these individual columns are foreign keys to.

The reason it's a good solution is that it will prevent duplicates from being entered without having to create an additional unique composite key.

Answer 2

I think your use of the terminology in the title is confusing and it doesn't correspond to what you are describing later in the question.

1. Always use artificial keys and try to avoid using natural keys. It's a good practice as you can almost never know what piece of data will have to be changed later which may affect your natural key.

| uid(pk) | name | family |

The above design is a good start.

1. Place as little restrictions on the data model as possible without sacrificing the data consistency.

In which case the composite key of UID, black_listed_ID can be a little too restrictive and the reason for that is that later on you may decide to keep the log of who black listed whom at different times, then your composite key design breaks.

Just use simple one to many relationship for now, describing the preferences of one user on multiple-records.

For example, the data model for user actions that can include blacklisting, whitelisting, and more can be like so:

UID, AFFECTED_USER_ID, ACTION_ID, ACTION_DT

where ACTION_ID is FK to an "ACTION lookup table" describing black-listing, white_listing, grey listing, etc, etc.

You can also have the table describing the current state of affairs, but that current state can also be calculated or retrieved from the above data.