[keevitaja]

on 2 tabelit v2ljadega

tabel 1 users:
user_id
user_name

tabel 2 admins:
user_id

[606]

miks Sul admin ja user eraldi tabelites üldse on?
miks mitte teha tabel USERS ja RIGHTS
USERS:
user_id
username
rights

RIGHTS:
right_id
r_name (määrad ära, kas tavakasutaja - user, admin jne, saad alati ja lihtsalt uusi õiguste gruppe juurde teha)

lisaks on kõik kasutajad olenemata õigustest samas tabelis.

[mikk36]

Või siis tekitada vastavad tulbad õiguste tabelisse et kas on admin, mingi muu tase jne.

[606]

[wk]

[2korda2]

Kindlasti on vale teha kasutajate tabelisse iga privileegi kohta eraldi tulp.
Täpselt sama vale kasutajate tabelis veerg RIGHTS. Mis siis teed, kui kasutajale vaja liita rohkem, kui 1 privileeg?

Ei tea süstemi keerukust aga vähegi keerulisemal juhul on mõistlik teha järgmiselt:
Tabelid:
USERS - sisaldab kasutajaid
RIGHTS - sisaldab funktsionaalseid privileegidega (kasutaja näeb menüüpunkti X, saab otsida isikut jne)
ROLES - sisaldab töökorralduslikult paika pandud "töökohti" (müügisekretär, laohoidja jne)

nüüd teed lisaks seosetabelid:
ROLES_RIGHTS - siin seod vastava töökoha õigused vastavate privileegidega
USERS_RIGHTS - saad siduda kasutaja konkreetse funktsionaalse õigusega (see on pigem erandkorras kasutamiseks)
USERS_ROLES - siin annad konkreetsele kasutajale konkreetse töökoha õigused.

Mis puutub konkreetsesse päringusse, siis mysql pole kasutanud aga võtmesõnaks võiks olla näiteks (OUTER) JOIN.

[wk]

[mrkaarel]

Või siis vahepealse variandina võimalus jätta rollimajandus kõrvale ja tekitada lihtsalt USERS, RIGHTS ja USERS_RIGHTS tabelid.. Kui kogu kasutaja õiguste pärimise osa koodis ühtekohta kokku koondada, ei ole kuigi keeruline hiljem vajaduse tekkimisel ka rolle juurde lisada.

[606]

täielikult nõus 2korda2'ga, kui on vaja mitu erinevat õigust lubada. lihtsa funktsionaalsuse puhul piisab 2'st tabelist.

[keevitaja]

OK, aga pöördume nüüd minu küsimuse juurde tagasi. kas seda minu koodi optimiseerida saab ilma tabeleid muutmata?

[mrkaarel]

Nagu öeldi, märgusõna on JOIN. Antud juhul siis umbes:
SELECT u.user_id, u.user_name, CASE a.user_id WHEN NULL THEN 0 ELSE 1 END CASE AS is_admin FROM users u LEFT JOIN admins a ON (u.user_id = a.user_id) ORDER BY u.user_name

[keevitaja]

[mrkaarel]

Üks viga minul endal:
CASE a.user_id WHEN NULL THEN 0 ELSE 1 END CASE
asemel peaks olema:
CASE WHEN a.user_id IS NULL THEN 0 ELSE 1 END CASE

Aga mis ta muidu teeb sul? Annab veateadet? Töötab, aga valesti?

[keevitaja]

[keevitaja]

aga mis vahet on näiteks inner join, left join jne

ja huvitav kuidas sellesse päringusse veel kolmas tabel kaasata?

[mrkaarel]

Kui sa joinid tabelit B tabeli A külge tingimusel X:
- (INNER) JOIN tagastab ainult sellised read, kus tingimus X on täidetud
- LEFT (OUTER) JOIN tagastab kõik read tabelist A ja ühendab neile külge B, kus tingimus X on täidetud
- RIGHT (OUTER) JOIN tagastab kõik read tabelist B ja ühendab neile külge A, kus tingimus X on täidetud
- FULL (OUTER) JOIN tagastab kõik read tabelist A ja tabelist B ja ühendab omavahel need read, kus tingimus X on täidetud (enda praktikas läheb väga harva vaja seda)

INNER ja OUTER ei ole JOINide nimedes olulised, võid ära jätta ja kasutada LEFT OUTER JOIN asemel lihtsalt LEFT JOIN jne.


Vaata joonised mõttega läbi ja katseta oma andmetega:
http://www.codinghorror.com/blog/archives/000976.html

Kolmanda tabeli saad samamoodi külge nagu teisegi said: sobiv JOIN ja tingimused, millega teda külge võtta.

[2korda2]

[mrkaarel]

[wk]

[nn3_]

[mrkaarel]

[wk]

[keevitaja]

nüüd veel üks päring. kas seda saaks kah optimiseerida? vaja siis kustutada erinevatest tabelitest kirjed, millel igas on üks ja sama page_id

[mrkaarel]

Kui antud olukord on selline, kus kustutatakse nii põhikirje kui ka sellele viitavad kirjed, siis sa saaks foreign key'de juures määrata ära cascade võimaluse ja põhikirje kustutamisel kustutab andmebaasimootor kõik sellele viitavad kirjed automaatselt. Kui olukord selline pole, siis koodi pealt ma ei näe küll, kuidas praegust lahendust optimeerida.

[2korda2]

/offtopic