2014-11-22 5 views
0

Я смущен относительно того, как назначать первичные ключи.Должен ли столбец автоматического приращения быть первичным ключом?

Например, предположим, что у меня есть эти две таблицы:

пользователей таблица, где user_id уникален:

+---------+----------+--------------+ 
| user_id | username | password | 
+---------+----------+--------------+ 
|  1 | hello | somepassword | 
|  2 | world | another  | 
|  3 | stack | overflow  | 
+---------+----------+--------------+ 

сообщений таблица, где post_id уникален:

+---------+---------+--------------+ 
| post_id | user_id | content | 
+---------+---------+--------------+ 
|  1 |  1 | Hello World! | 
|  2 |  1 | Another.  | 
|  3 |  3 | Number 3. | 
|  4 |  2 | Stack.  | 
|  5 |  1 | Overflow. | 
+---------+---------+--------------+ 

Очевидно, что для пользователей таблица первичного ключа должна быть user_id, но какой должен быть первичный ключ в сообщениях стол? post_id или user_id? Пожалуйста, объясни.

Спасибо!

+0

это ваше желание .. но так как user_id не может быть первичным, так что вы не имеют иначе, чем post_id как первичный –

ответ

0

Первичный ключ для таблицы Posts также должен быть значением auto increment, post_id, потому что это единственное, что однозначно идентифицирует каждое сообщение, потому что каждый пост имеет id в отличие от любого другого. User_id не всегда будет уникальным, потому что один и тот же пользователь может иметь несколько сообщений (насколько я знаю), чтобы он не мог однозначно идентифицировать сообщения. Если вам нужно связать информацию между таблицами, вы всегда можете сделать присоединение к user_id из обеих таблиц, однако для определения вещей с помощью первичного ключа post_id будет вашим лучшим выбором.

+0

Хорошо, и примерно в этом случае, давайте попробуем для простоты сказать, что 'user_id' в ** сообщениях ** t способный был также уникален, но не увеличивался автоматически. Каким должен быть первичный ключ? –

+0

Теоретически вы можете использовать либо, если они всегда будут уникальными, но соглашение, вероятно, все еще должно использовать post_id. Но на самом деле один пользователь должен иметь возможность делать несколько сообщений, вероятно, поэтому user_id скорее всего не будет уникальным. – golgothan3

-1

Конечно, это должно быть user_id, потому что, когда вы используете ORM, то он будет отображать таблицы автоматически из правильного именования ключей Вы можете обратиться ОРМ здесь: Good PHP ORM Library?

0

Конечно, у вас есть эта sceneraio:

  • Пользователь может публиковать несколько сообщений.
  • Сообщение может быть опубликовано логически одним пользователем.

Таким образом, вы имеете дело с моделью One-To-Many.

Как только вам все это ясно, вы можете предположить, что первичный ключ users должен отображаться как внешний ключ в posts. Это то, что вы, очевидно, уже сделали.

Теперь, wether post_id достаточно, так как первичный ключ posts зависит от всей модели отношения сущности, которую у вас есть (сколько у вас других сторон и каковы их отношения друг к другу).

Однако для этого конкретного сценария не потребуется комбинировать внешний ключ user_id как часть первичного ключа posts.

Примечание: когда вы реализуете ваши таблицы, добавьте ограничения auto_increment и not null к user_id и post_id.

Давайте summerize все это безобразие в SQL:

Таблица users:

mysql> create table users (user_id int(2) unique auto_increment not null, username varchar(15) not null, password varchar(20) not null, primary key(user_id));Query OK, 0 rows affected (0.33 sec) 

Таблица posts:

mysql> create table posts(post_id int(2) unique auto_increment not null, user_id int(2) not null, content varchar(50) not null, foreign key(user_id) references users(user_id), primary key(post_id)); 
Query OK, 0 rows affected (0.26 sec) 
Смежные вопросы