nie wiem jak zapewnić unikalność w rekordzie w tabeli, w której trzymam kilka kluczy obcych(tych samych), chcem aby baza danych zachowala spójność, a nie wadlizować poprawność wpisu przez php. Potrzebuje, aby rekord zawierał unikalne klucze obce. Zastanawiałem się czy może transakcja będzie mogła to wykonać, bo trigger raczej odpada,

Co sądzicie na ten temat??

Nic nie kumam z tego opisu...

A nie mozesz uzyc UNIQUE ?

unique da mi unikalność na poziomie kolumny a nie na poziomie wiersza,

podam przykład zastosowania:
tabela pierwsza ma pracowników
tabela druga projekty, każdy projekt ma kilku pracowników, ale pracownicy w projekcie nie mogą sie powtarzać,

jakim sposobem można zapewnić takie warunki w bazie by była spójna

nie wiem czy wiesz, ale UNIQUE mozna ustawic na kilka kolumn, czyli defacto zrobic to co chcesz.

Nie wiem gdzie to wyczytałeś, ale ja znalazłem że index unique odpowiada za unikalność na poziomie kolumny a nie wiersza i sprawdziłem że faktycznie tak jest.

wiesz, wyczytalem w manualu i spowodzeniem stosuje to w moim aplikacjach uzyskujac wlasnie to co chcesz osiągnąć. Ale skoro nie to nie... twoj problem, a ja ide oglądac film

@totoo:
Polecam zapoznanie się z http://dev.mysql.com/doc/refman/5.0/en/create-index.html. Następnym razem może nie wymądrzaj się jeżeli pomocy udziela ci ktoś, kto ma troszke większą wiedzę od twojej. Gdybyś miał problem ze zlokalizowaniem konkretnego miejsca w dokumentacji:

konkretnie chodzi o te kropeczki.

Poprostu daj unique do wszystkich kolumn... i masz unikalny wiersz ....

Koledzy, z tego co wyczytalem

To kolega ma relacje wiele do wielu, przy czym nie uzywa 3ciej tabeli - i wszystko trzyma w jednym polu rekordu projekt (porazka!).

Totoo: dorob 3cia tabele: pracownik_w_projekcie: ( projekt_id, pracownik_id, ....) i klucz unique (projekt_id, pracownik_id). That's all.

Ja osobiscie zrozumialem ze tak wlasnie zrobil, tylko nie dal tych nieszczesnych UNIQUE

Rozumiem że cchesz zrobić to tak :
w tabeli 2 lub 3 kolumny są tym samym kluczem obcym ale chesz zpewnic zeby nie powtarzały sie w danym rekordzie?

jeśli tak to tylko trigger i sprawdzenie warunków

no chyba nie do końca: analizując przykład z pracownikami i projektami:

tabela powiazań mialaby ma strukture:
projekt ( FK z tablicy projektow ) | pracownik 1 (FK z tablicy pracownicy ) | pracownik 2 (FK z tablicy pracownicy )
i chcesz zapewnic ze jeden pracownik nie moze w pojedynke zajmowac sie projektem na 'dwa etetay' ale moze figurować w kilku proejtach róznych . Powyższe rozumowanie ( UNIQUE na kazdej z kolumn doprowadziloby do sytuacji ze do kazdego z projektow musiałby byc osobny zestaw pracowników. przykład :

projekt | prac1 | prac2
-----------------------------
0001 | p22 | p11
0002 | p33 | p15
0003 | p22 | p34 <- ten wpis jest poprawny ale nie mozemy go wpisać bo jest ustawione unique na klumnie prac1!

a chodziło chyba o to żeby nie mozna bylo wstawić

0004 | p09 | p09

w dodatku unique na projekt blokuje nam mozliwosc pzypisanie np 4 odob do jednego projektu - ale to moze nie jest konieczne, niewiem.
takze - relacje + triggery IMHO jedyne opcja.

@azr ta tabela to cos nie teges. A jak bedziesz chcial 3 pracownikow? Dodasz kolejne pole? A jak czterech? znowu dodasz? A jak 100?....

To co napisal dr_bonzo to najlepsze rozwiązanie + UNIQUE na oba POLA. Dawanie tutaj triggerow to lekkie nieporozumienie

tabela z dwoma pracownikami to tylko przykład.
zawsze mozna zrezygnować z unique na projekt i mieć tyle par ile sie chce ze wspolnym projetkm, chociaz to faktycznie pokrecone ale mowie to tylko przyklad gdyby chciać miec ograniczona licze pracowikow.


jeśli założy sie UNIQUE na oba pola wspólnie to faktycznie bedzie to spełaniało swoje zadanie (jeśli index na obydwu polach razem będzie działał jak sklejenie).


wcześnie zrozumiałem ze unique ma być założone _osobno_ na każdą z kolumn.



EDIT :
to chyba wyczerpuje temat i przy okazji totoo masz tez dodatkowe informacje o potencjalnym problemie.