|
|
|
Связь один к одному. Использовать суррогатный ключ?
|
|||
|---|---|---|---|
|
#18+
Есть таблица пользователей. Там первичный ключ естественный - табельный номер. Есть связанная таблица. Связь один к одному. Записей во второй много меньше, чем в первой. Вопрос: во второй таблице первичнвым (он же внешний?) ключом оставить табельный номер, или ввести ID в качестве первичного ключа, а на табельный номер поставить уникальность? Интересует, что будет правильней в моей ситуации и в ситуации, когда большая по количеству полей таблица искуственно разделена на две, т.е. кол-во записей в них одинаковое ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.07.2004, 15:36 |
|
||
|
Связь один к одному. Использовать суррогатный ключ?
|
|||
|---|---|---|---|
|
#18+
Оставить табельный номер. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.07.2004, 16:38 |
|
||
|
Связь один к одному. Использовать суррогатный ключ?
|
|||
|---|---|---|---|
|
#18+
Я бы тоже больше бы думал о табельном номере. Если нужна инфа только из второй таблы и табельный номер, то не нужно соединение. Меньше полей, индексов. Суррогатный ключ мало о чем говорит пользователю, идентифицирует в пределах таблицы. Основным сильным доводом в пользу суррогатного ключа является, то что, считается, что нет причин его менять. Если бы во второй таблице было много, записей, относящихся к одному пользователю, то это бы усилило значение этого довода. Ну, и например, в Оракле триггер на каскадное обновление не надо писать. В Access поддерживается декларативное каскадное обновление. Ну еще, если в БД уже много суррогатных ключей, то как бы использование в других случаях естественных - нарушение однообразия подхода. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.07.2004, 18:55 |
|
||
|
|

start [/forum/topic.php?fid=32&tid=1546361]: |
0ms |
get settings: |
10ms |
get forum list: |
11ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
182ms |
get topic data: |
6ms |
get forum data: |
2ms |
get page messages: |
21ms |
get tp. blocked users: |
1ms |
| others: | 240ms |
| total: | 477ms |

| 0 / 0 |
