Mój pomysł: brak ID w tabeli, Czy rozwiązanie ma jakieś minusy? Opcje

[Zajec]

Potrzebuję stworzyć tabelę, która będzie kojarzyła ze sobą pozycje dwóch innych tabel:

1) Tabela "users" z id użytkownika i jego danymi
2) Tabela "hobby" z id hobby i nazwą hobby

Chcę, aby każdy użytkownik mógł sobie obrać kilka zdefiniowanych przeze mnie hobby. Tworzę więc tabelę z dwoma polami:
1) user_id
2) hobby_id

Teraz pytanie: Czy jest jakiś silny argument, aby dodawać pole id w tabeli łączącej? Zawsze mnie uczono, że id musi być i że ułatwia pracę, ale w tym przypadku szczerze mówiąc nie widzę zastosowania. Gdy user zmienia hobby po prostu kasuję jego dotychczasową listę hobby i tworzę jeszcze raz. Nie mam potrzeby odwoływania się do konkretnego wiersza tabeli łączącej.

Co więcej boję się, że przy częstej zmianie hobby, wartości jej pól "id" drastycznie urosną mimo ogólnie małej ilości wierszy. Dlatego głównie nie chciałbym dodawać pola "id".

Ten post edytował Zajec 6.04.2007, 23:10:03

[Sedziwoj]

Darti co nagle to po diable, co prawda tabela z samymi hobby jak i user są niepotrzebne, bo ważne są id obu.
A wybranie dwóch osób, o takim samych hobby wcale nie jest takie proste. Ja chwilowo widzę tylko taką możliwość, że dla danego użytkownika szukamy innych o tych samych zainteresowaniach. Ponieważ jak widz chcesz pełne pokrycie zbiorów zainteresowań.

Wracając do tematu, id jest w tym przypadku zbędne, i ogólnie jak możemy określić unikalne pole lub ich kombinacji, tu UNIGUE(user_id,hobby_id), ale czasem jak jest albo nie możliwe wybranie unikalnych, lub dla prostoty użytkowania dodaje się id.
Dla prostoty: załóżmy że mamy tabele osób i każda ma PESEL (bo tak wynika z wymagań że jest zawsze podany) i można w ten sposób unikalnie identyfikować daną osobę, ale po pierwsze łączenie po polu pesel jest niewygodne i wytwarza o wiele więcej danych (bo każda powiązana musiała by mieć cały pesel), do tego udostępnia pesel osoby a takie dane są objęte ochroną, po drugie możliwe jest że ktoś wprowadzi błędny, a potem będzie chciał poprawić, jak już będzie w wielu miejscach, chyba każdy wie co by to znaczyło.
Tu mamy wewnętrzną identyfikację i prostą unikalność, do tego do tej tabeli nie podłączmy innych do unikalnego rekordu więc można (ale nie musimy) sobie darować pole id.