Relacje 1:m pomiędzy obiektami najlepiej jest zrobić za pomocą tzw. "pivot tables", ale jest też inne podejście.
W przypadku relacji 1:1 takową można spokojnie zrobić za pomocą istniejących tabel, w przypadku relacji 1:m, m:m są dwa podejścia:
1. wykorzystanie "pivot tables" i kluczy obcych
2. w przypadku naprawdę obciążonych serwisów często normalizację się olewa i stosuje np. pole, w którym jest przetrzymywana zserializowana tablica.
Jak mniemam, dla Ciebie lepsze będzie wyjście pierwsze, inaczej byś o to nie pytał.
A więc. Po pierwsze, kilka rad:
1. przyjmij nazewnictwo anglieskie - uwierz mi same plusy - np. przy mapowaniu na obiekty z użyciem jakiegoś ORMa, np. Doctrine, napotkasz wiele problemów z generowaniem kodu. Poza tym, świat IT mówi po angielsku.
2. Jedna konwencja nazewnictwa. Taką konwencję? OK. Ale wówczas, tabele nazywaj tak samo, nie stosuj żadnych durnych skrótów typu gwar.
Przykład. Masz dwa obiekty: User oraz Picture. Jeden user może mieć wiele zdjęć, ale jedno zdjęcie może należeć do kilku userów. Mówiąc o zdjęciu mam na myśli obiekt z bazy danych, nie fizyczną fotkę. Z więc masz tabele:
Kod:
User:
ID INT AI PK
Username VARCHAR(100) UQ
Picture:
ID INT PK
Filename VARCHAR(20)
tworzysz sobie dodatkowo następującą tablicę:
Kod:
UserPictures: // pamiętaj, żeby obiekt nadrzędny był pierwszy w nazwie - oczywiście ma to znaczenie tylko z punktu widzenia projektu
ID INT AI PK
UserID INT
PictureID INT
dla zapewnienia integralności bazy ustaw sobie klucze obce w nowo utworzonej tabeli:
Kod:
UserID => ID z User
PictureID => ID z Picture
Voila!