Witajcie!
Idea jest prosta, mam tabelę grup wyglądającą tak:


Jak pewnie każdy się domyśla pole isDef gdy jest równe 1 mówi skryptowi, że dana kategoria jest domyślną. Problem jest taki, że użytkownicy to kombinatorzy i nawet jak zabezpieczam to od kodu ktoś może grzebać w sqlu (lub któryś plugin).
Chciałbym od strony sqla zabezpieczyć to tak, aby "1" nie mogło wystąpić więcej niż raz. Zwykłe unique tu nie zadziała bo zera przecież mogą się powtarzać.

Co ?!?
Jeśli ktoś może coś zmienić bez uprawnień lub cokolwiek robić co nie zostało zaplanowane w aplikacji to jest to potężna! luka w zabezpieczeniach !
Nawet nie pisz takich rzeczy

Nie ma zabezpieczeń nie do przejścia. Jeśli zakładasz, że użytkownicy będą grzebać w skryptach lub SQLu, to każde zabezpieczenie które założysz na SQLa (np. uniq o którym pisałeś - jeśli by działało; lub triggery), może zostać przez "osobę grzebiącą" ściągnięte (ominięte).

Luk staram sie aby nie było
Generalnie z tym sqlem chodziło mi raczej o jakiegoś grzebule od phpmyadmina albo zwyczajnego buta w kodzie

Wpadł mi ciekawy pomysł do głowy który pilnować nie będzie ale zniesione skutki: przy edycji dowolnej kategorii robię dodatkowo select po isDef z limit 1, zapamietuje od grupy, robię update isDef na 0 i następnie kolejny update tyle ze ustawiam isDef na 1 tylko zapamietanemu idkowi.
Metoda może trochę na około ale nie znalazłem żadnego mechanizmu w mysqlu służącego do tego celu

1. triggery(ale o szczegóły mnie nie pytaj )
2. w php dajesz podstawowe zapytanie

[SQL] pobierz, plaintext 
SELECT * FROM tabela WHERE isDef='1'
[SQL] pobierz, plaintext 

Potem tylko sprawdzasz przez zwykły if, czy zapytanie zwróciło wyniki i reagujesz na sytuację

Obecnie isDef używam tylko do dodawania napisu "Domyslna" ale chce dopisać zabezpieczenia typu nieusuwalnosc domyslnej czy przenoszenie userow ze skasowanej do domyslnej wiec fajnie żeby była unikalną
Twój sposób nie zadziała bo ja potrzebuje mieć porządek w sql a nie tylko w tym co dostanie user. A o triggerach pogooglam (domyślam sie ze chodzi tu o ustawienie watchdoga który pilnuje danych)

Normalnie użyłbyś CHECK(), ale MySQL tego nie obsługuje. Dosyć łatwo możesz to osiągnąć poprzez kombinację ENUMa i NULLa, tj:

[SQL] pobierz, plaintext 
is_def ENUM('yes') DEFAULT NULL,
UNIQUE KEY(is_def)
[SQL] pobierz, plaintext 

NULLe traktujesz jako "nie", YES traktujesz jako "tak". Takie coś umożliwia nieistnienie żadnej domyślnej grupy, ale gwarantuje tylko jedną domyślną.

PS. W MySQL (właściwie to ogólnie w SQL) stosuje się konwencję "underscore", czyli is_def, nie isDef.

Hmm sprytne, dopilnowanie tego aby zawsze była domyślna tu już nie taki duży problem

Co do notacji - wszystkie underscory przeprawiłem na notację somethingNice bo w każdym kodzie tak pisze więc po co w bazie danych kombinować

1. Nie cytuj całych wypowiedzi, a już w szczególności, gdy odpowiadasz na ostatni post.
2. Bo właśnie to Ty kombinujesz. Kod pisze się zawsze z uwzględnieniem konwencji dla danego języka i tak w takim PHP czy Javie zmienne nazywasz stosując konwencję camel case (nazwaZmiennej), a w takim C czy SQLu zmienne / kolumny nazywasz stosując konwencję underscore (nazwa_zmiennej). Inaczej prędzej czy później doprowadzisz do burdelu w kodzie.

Tak ale skoro stosuje CC w kodzie to dlaczego mam go nie używać w SQLu?

Powtórzę:A SQL ma utartą konwencję nazewnictwa, gdzie słowa kluczowe pisze się wielkimi literami, a identyfikatory zapisuje w_ten_sposób.

No to w takim razie w php też_należy_pisać_tak patrząc na stdlib co nie zmienia faktu, że każdy pisze jak chce klamry oraz nazwy kluczowe.
Ważne jest w sumie nie tyle forma zapisu co jego czytelność i spójność - idąc tym tropem wg. mnie powinno się pisać w całym projekcie w jeden sposób (baza danych jest częścią projektu, right?).
Kolejna sprawa - nie nazwałbym SQLa językiem - formalnie się do nich zalicza ale nie pisze się w nim jako takich funkcji, pętli, przekształceń (a bynajmniej nie powinno się - jest to możliwe ale wciąż trzeba pamiętać, że to BAZA danych a nie PREPROCESOR danych).

PHP w to nie wciągaj. PHP to książkowy przykład burdelu spowodowanego tym, że każdy robił jak chciał. Pomijamy fakt, że obecnie PHP jest w fazie przejściowej, tj. cały nowy kod powinien być pisany wg notacji camelCase.
Kod PHP pisze się inaczej, kod CSS pisze się inaczej, kod XML pisze się inaczej, kod YAML pisze się inaczej, kod SQL pisze się inaczej, kod Javy pisze się inaczej, kod Basha pisze się inaczej - wszystkie pisze się inaczej mimo iż nie ma najmniejszego problemu by wystąpiły wszystkie w jednym projekcie.
Język SQL jest pełnoprawnym deklaratywnym językiem programowania w którym występują przekształcenia, pętle czy funkcje (no, te ostatnie to raczej zaliczają się do rozszerzeń SQLa, ale ogólnie przyjmuje się to wszystko za jedność). Nie wiem też co tutaj mają preprocesory do rzeczy.

W skrócie: nie rób burdelu i dostosuj się do ogólnie przyjętych konwencji.

Faktycznie skończymy już temat cc/us - do niczego nie dojdziemy
Jeśli chodzi o język SQL to nie odpuszcze swojej racji - owszem, można w nim pisać pełnoprawny kod ale nie do tego on służy! Od przetwarzania danych mamy stronę aplikacji a nie bazę danych.
Dużo lepszym wyjściem jest pobranie w prostrzy sposób nawet nieco większej porcji danych i przetworzenie jej po stronie PHP niż pisanie zapytania które na zwrócenie wyniku potrzebuje kilku sekund.
Baza służy do gromadzenia i zwracania danych a nie do obróbki danych - tyle w temacie.

@kiler129: W tej chwili skompromitowałeś się. Celem istnienia baz danych jest... gromadzenie i przetwarzanie danych. Zadaniem aplikacji jest przetwarzanie tylko tego czego z poziomu bazy danych się nie da, albo jest to efektywniejsze. Chociażby dla zachowania spójności danych czy pisania kodu raz i wykorzystywania go wielokrotnie (w przypadku gdy kilka aplikacji korzysta z jednej bazy). To, że Ty się ograniczasz do operacji CRUD na bazie danych to tylko i wyłącznie Twoja sprawa, ale nie wypisuj głupot, że bazy służą wyłącznie do tego.
Tak, bo PHP przetworzy te dane w jedną tysięczną sekundy...
Do poczytania: http://en.wikipedia.org/wiki/PLSQL (i inne warianty innych baz danych).

A to PLSQL jest częścią standardu SQL? Bo czysty SQL chyba jednak nie jest pełnoprawnym językiem programowania.

@everth:

No i masz rację, rację ma też @kiler129, wszystko zależy od tego co wpiszecie sobie pod skrót SQL

Ja to ujmę inaczej - można ale żadko wydajniej jest przetwarzać coś na bazie danych niż w aplikacji. Szczególnie ta zasada ma się do PHP gdzie kod jest odpalany w większości na shared-hostach gdzie bazy są bardzo obciążone.

Chciałeś chyba powiedzieć coś dokładnie odwrotnego?
1. Transport danych z bazy do aplikacji jest dosyć kosztowny.
2. PHP samo w sobie będzie raczej minimalnie wolniejsze od bazy danych (mimo iż testów nie przeprowadzałem).

Tak, tylko w przypadku aplikacji odpalanych na współdzielonych maszynach ten aspekt wydajności jest kompletnie bez znaczenia.

Maszyny bazodanowe mają tendencję do słabszego CPU kosztem większego ramu w przeciwieństwie do serwerów aplikacji.
Jeśli chodzi o środowisko współdzielone to patrząc na statystyki zaprzyjaźnionego hostingu najwięcej problemów jest z dostępem do dysku a najbardziej "aktywnym" procesem jest mysql (głównie przez kiepskie szukajki).

kiler mógłbyś poprzeć swoją teorię o mocy maszyn bazodanowych i maszyn gdzie stoją aplikacje?

Co do dostępu do dysku - dane tak czy inaczej musisz pobrać. Od tego są RAID'y, dyski SSD (wiem, drogie ale kto ma tani serwer?), dyski typu ramdisk (jak sama nazwa wskazuje, informacje przechowywane są w ramie, z tego co pamiętam gigabyte wypuszczało bodajże i-ram)

Co do "aktywności" procesu mysql, przez kiepskie szukajki jak to napisałeś, kto w dużym projekcie użyje MySQL do tego celu?
Po co zwalać pracę na coś co nie jest do tego przystosowane? Od czego jest niby sphinx ?