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".

Oczywiście że id nie musi być. Id jest potrzebne tylko po to aby zidentyfikować wpis (np. gdy chcemy go usunąć) Najlepszym rozwiązaniem będzie chyba zrobienie tej tabeli jako dwóch kolum które dodatkowo są PK, co zapobiegnie zduplikowaniu wpisu...

Zalezy w jakiej bazie - sa takie gdzie mozna zdefiniowac aby para wartosci byla unikalna

Dzięki za odpowiedź. Pominę w takim razie id.

(Baza: MySQL)


PK:
Politechnika Poznańska
KB PK
Biblioteka PK
Polski Katalog
Panorama Kultur

Tyle zasugerowało Google. A co Ty miałeś na myśli? ;-)

primary key....

Nie wiem czy dobrze rozumuje, ale...

Jeśli chodzi ci o to aby każdy użytkownik miał w bazie więcej niż jedno hobby to niezbędna ci będzie tabela składająca relacje - jest to klasyczny przypadek encji wiele - do wielu, która nie ma prawa istnieć zgodnie z teorią relacyjnych baz danych. Możesz tak:

USERS

UserID | Name | Cośtam

HOBBYS

HobID | Hobby Name


HobbysOfUsers

AutoID | UID (to klucz UserID z tabeli USERS) | HID (analogiczny z HOBBYS)


pozdr.

Zajac: nie musisz robic IDka.



Patrz nizej: nie jest potrzebny

a szukasz rekordu jednoczesnie po user_id i hobby_id i masz jednoznacznie okreslony rekord

A ciekawi mnie przypadek, kiedy chcesz wybrać dwóch użytkowników z takimi samymi hobby (np żeby stworzyć 'wspólne koło zainteresowań). Jak wyglądałoby zapytanie w projekcie od @Zajec

Tylko dwoch?

[SQL] pobierz, plaintext 
SELECT h.name, u.name FROM hobbies h JOIN hobbies_users hu ON hu.hobby_id = h.id JOIN users u ON hu.user_ud = u.id LIMIT 2
[SQL] pobierz, plaintext 

@dr_bonzo coś Twoja metoda nie działa, zmontowałem na szybko takie dwie tabelki:

[SQL] pobierz, plaintext 
CREATE TABLE `hobbies` (
  `user_id` int(5) NOT NULL DEFAULT '0',
  `hobby_id` int(5) NOT NULL DEFAULT '0'
) ENGINE=MyISAM DEFAULT CHARSET=latin1;
 
INSERT INTO `hobbies` VALUES (5, 8);
INSERT INTO `hobbies` VALUES (1, 1);
INSERT INTO `hobbies` VALUES (1, 2);
INSERT INTO `hobbies` VALUES (1, 3);
INSERT INTO `hobbies` VALUES (2, 1);
INSERT INTO `hobbies` VALUES (2, 2);
INSERT INTO `hobbies` VALUES (2, 3);
INSERT INTO `hobbies` VALUES (3, 3);
INSERT INTO `hobbies` VALUES (4, 9);
 
CREATE TABLE `users` (
  `user_id` int(5) NOT NULL DEFAULT '0',
  `name` varchar(20) NOT NULL DEFAULT ''
) ENGINE=MyISAM DEFAULT CHARSET=latin1;
 
INSERT INTO `users` VALUES (5, 'piaty');
INSERT INTO `users` VALUES (1, 'pierwszy');
INSERT INTO `users` VALUES (2, 'drugi');
INSERT INTO `users` VALUES (3, 'trzeci');
INSERT INTO `users` VALUES (4, 'czwarty');
[SQL] pobierz, plaintext 

i wmontowałem Twoje (podobne) zapytanie (pomińmy że miało być dwóch) :

[SQL] pobierz, plaintext 
SELECT hu.name, u.name FROM hobbies h JOIN users hu ON h.hobby_id = hu.user_id JOIN users u ON h.user_id = u.user_id
[SQL] pobierz, plaintext 

Powinien wyświetlić tylko userów: pierwszy, drugi (bo mają zainteresowania 1,2,3) a wmieszał się tam jeszcze trzeci dziwnym trafem (bo ma tylko i wyłącznie zainteresowanie 3, ale się wkręcił na imprezkę i nie ma o czym gadać z pierwszym i drugim bo zeszli na tematy 1 lub 2 i trzeciemu grozi picie browara i rwanie lasek koło baru a chciał pogadać ).

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.

Tzn z mojego punktu widzenia ważna jest jedynie tabela 'hobbies', nie interesuje mnie to, jak nazywa się dany user (wystarczy mi ID).
Borykam się z tym problemem (braku unikalnej kolumny - nie mogę zmienić struktury tabel) od dosyć dawna.
Kombinowałem poprzez złączenie dwukrotnie jednej, tej samej tabeli (np pierwsza.hobby_id=druga.hobby_id) ale dawało mi w efekcie elementy 'niepełne' (tutaj niepełne zainteresowania trzeciej osoby).
Temat jest dla mnie niezwykle intrygujący ... po prostu nie lubię wiedzieć że czegoś nie wiem A nie wiem jak unikatowo wybrać z takiej tabeli (hobbies) osoby o takich samych zainteresowaniach.
Pomóżcie proszę zapytaniem SQL ....

Darti problem nie jest jak mi się wydaje banalny, bo jeśli chcesz wybrać osoby o danym hobby lub nawet kilku to nie jest problem.
Jednak gdy chcesz wybrać osoby o takich samych zainteresowaniach to pamiętaj że każdy może mieć inną długość listy hobby więc dla każdej osoby wybierasz takie które mają taką samą, takich osób może być kilka.
Więc wybierasz osobę i jej zainteresowania np.:
user_id|hobby_id
1|1
1|2
1|3
potem szukasz osoby która ma te zainteresowania, ale tu tracę pomysł jak...
albo mam błędne założenia od początku. Ale wynikiem końcowym będzie tablica o dwóch polach user_id gdzie obaj użytkownicy mają te same hobby (przy czym będzie coś w stylu 1|2 i 2|1 z powodu że to jest relacja dwu kierunkowa)

Mam małe doświadczenie w tworzeniu zapytań i jeszcze nie czytałem żadnej porządnej książki o tym :|

Coś wykombinowałem, działa, ale optymalności to pewnie ani ciut, ciut nie ma:

[SQL] pobierz, plaintext 
SELECT `nalezy`.`u_id`,`zawiera`.`u_id` FROM (SELECT `max`.`u_id`,`sum`.`t_u` FROM (SELECT `u2`.`u_id`,count(*) AS `x` FROM `ush` AS `u2` GROUP BY `u2`.`u_id`) AS `max` 
JOIN (SELECT `ush`.`u_id` AS `f_u`,`u`.`u_id` AS `t_u`, COUNT(`u`.`h_id`) AS `ile` FROM `ush` LEFT JOIN `ush` AS `u` ON `u`.`h_id`=`ush`.`h_id` GROUP BY `ush`.`u_id`,`u`.`u_id`) AS `sum` 
ON (`max`.`x`=`sum`.`ile` AND `max`.`u_id`=`sum`.`f_u`)) AS `nalezy` 
LEFT JOIN (SELECT `max`.`u_id`,`sum`.`t_u` FROM (SELECT `u2`.`u_id`,count(*) AS `x` FROM `ush` AS `u2` GROUP BY `u2`.`u_id`) AS `max` 
JOIN (SELECT `ush`.`u_id` AS `f_u`,`u`.`u_id` AS `t_u`, COUNT(`u`.`h_id`) AS `ile` FROM `ush` LEFT JOIN `ush` AS `u` ON `u`.`h_id`=`ush`.`h_id` GROUP BY `ush`.`u_id`,`u`.`u_id`) AS `sum` 
ON (`max`.`x`=`sum`.`ile` AND `max`.`u_id`=`sum`.`f_u`)) AS `zawiera` 
ON (`nalezy`.`t_u`=`zawiera`.`u_id` AND `nalezy`.`u_id`=`zawiera`.`t_u`) 
WHERE `nalezy`.`u_id`<`zawiera`.`u_id`
[SQL] pobierz, plaintext 

proste nieprawdaż?

i i tabelka taka:

[SQL] pobierz, plaintext 
CREATE TABLE `ush` (
  `u_id` int(11) NOT NULL,
  `h_id` int(11) NOT NULL,
  PRIMARY KEY  (`u_id`,`h_id`)
)
[SQL] pobierz, plaintext 

jak macie lepsze pomysły piszcie.

EDIT próba aby trochę połamało zapytanie

@Sedziwoj jesteś geniuszem w tym temacie
działa doskonale, Dzięki wielkie

1. Darti: sorry za blad; zle zrozumialem twoja prosbe (mialem wszystkich wypisac userow z jednym, ustalonym hobby -- zapomnialem o WHERE

2. Sedziwoj: WOW, jak ty sie w tym nie pogubiles


3. [chyba zaraz dopisze]
edit: albo i nie bedzie, nie mam teraz czasu

Tylko czy nie można lepiej tego zrobić, to jedynie mnie martwi...

A co do optymalizacji to po prostu stworzenie tymczasowej tabeli, bo w sumie łączem dwie takie same (LEFT JOIN) więc po co dwa razy używać skomplikowanego zapytania.

I nadal czekam na konstruktywną krytykę, bo może da się coś poprawić, albo ma metoda od założenia była błędna...