![]() |
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Необходимость наличия Primary Key [D6, IB6.x]
Vemer © (2004-10-15 16:43:00)Здравствуйте.
Для отражения связей "многие к многим" использую классическую дополнительную таблицу (Own_ID(PK), ID1(FK), ID2(FK)). С таблицей работаю только через ХП. Есть Constraint на Unique ID1 + ID2.
Возникла мысль о ненадобности в этой структуре своего PK()т.к. уникальность пар и правильность значений обеспечивается Constraint и FK.
Свой PK по идее нужен только для удаления, но по набору ID1 + ID2 замечательно удаляется, просто 1 условие в Where добавляется и все.
Вроде никаких других "подводных камней" не вижу
Можно в такой таблице (< 1000 записей) жить без PK?
Reindeer Moss Eater (2004-10-15 16:59:00) [1]Свой PK по идее нужен только для удаления, но по набору ID1 + ID2 замечательно удаляется, просто 1 условие в Where добавляется и все.
PK нужен не для удаления.
PK нужен не для редактирования.
PK нужен тогда, когда есть необходимость идентифицировать конкретную запись в таблице.
Вот пример таблицы-справочника прав пользователя
create table dic_user_rights(
ur_user_id ....,
ur_function ...
);
То есть код юзера и код привилегии.
Нас интересует набор привилегий юзера и нам по барабану в каких конкретно записях находятся конкретные привилегии.
Первичный ключ здесь нафик не нужен.
Полный перечень привилегий пользователя получается выборкой по его ID.
Удаление привилегии - по коду самой привилегии.
Johnmen (2004-10-15 16:58:00) [2]>Vemer © (15.10.04 16:52) [2]
>Ура.. придумал.
Да ладно... Это тебе RME подсказал...:)
Vemer (2004-10-15 16:52:00) [3]Ура.. придумал. Надо эти 2 поля оставшихся PK объявить и не париться.. уникальность + быстрота поиска обеспечены ))
Reindeer Moss Eater (2004-10-15 16:47:00) [4]Сам по себе PK конечно же необязателен.
Но если у тебя уникальный ключ, то почему бы его не сделать первичным ключем?
Индекс-то все равно будет.