Скачать: CL | DM;

Необходимость наличия Primary Key   Найти похожие ветки 

← →
Vemer ©   (2004-10-15 16:43) [0]

Здравствуйте.
Для отражения связей "многие к многим" использую классическую дополнительную таблицу (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:47) [1]

Сам по себе PK конечно же необязателен.
Но если у тебя уникальный ключ, то почему бы его не сделать первичным ключем?
Индекс-то все равно будет.

---

← →
Vemer ©   (2004-10-15 16:52) [2]

Ура.. придумал. Надо эти 2 поля оставшихся PK объявить и не париться.. уникальность + быстрота поиска обеспечены ))

---

← →
Johnmen ©   (2004-10-15 16:58) [3]

>Vemer ©   (15.10.04 16:52) [2]
>Ура.. придумал.

Да ладно... Это тебе RME подсказал...:)

---

← →
Reindeer Moss Eater ©   (2004-10-15 16:59) [4]

Свой PK по идее нужен только для удаления, но по набору ID1 + ID2 замечательно удаляется, просто 1 условие в Where добавляется и все.

PK нужен не для удаления.
PK нужен не для редактирования.

PK нужен тогда, когда есть необходимость идентифицировать конкретную запись в таблице.

Вот пример таблицы-справочника прав пользователя
create table dic_user_rights(
ur_user_id  ....,
ur_function ...
);

То есть код юзера и код привилегии.
Нас интересует набор привилегий юзера и нам по барабану в каких конкретно записях находятся конкретные привилегии.
Первичный ключ здесь нафик не нужен.
Полный перечень привилегий пользователя получается выборкой по его ID.
Удаление привилегии - по коду самой привилегии.

---

Страницы: 1 вся ветка

Скачать: CL | DM;



Память: 0.46 MB
Время: 0.04 c