ugrás a tartalomhoz

MySQL ismerősök

abicska · 2010. Már. 13. (Szo), 03.17
Szevasztok!
Szeretnék egy kis segítséget kérni, mert elakadtam.

Adott egy adatbázis, amiben külön táblában tárolom a felhasználókat és az alapvető adataikat. A fő kapcsolódási pont a sorszám ugye.
Adott egy másik tábla, amiben két felhasználó kapcsolatát tárolom.

RELATIONS tábla
relations_id (INT 11)
relations_from (INT 11) //Ez jelzi, hogy ki jelölt...
relations_to (INT 11) //...kit.
relations_created (TIMESTAMP)
relations_accept (TINYINT 1) //Ez jelzi, hogy él e kapcsolat (igaz, hamis)

A gondom ezzel pedig az, hogy szeretném kiválasztani az én kapcsolataimat a táblából és ehhez hozzácsatolni az 'users' tábla megfelelő sorát.

Vagyis:
SELECT * FROM relations WHERE (rel_from = 1 OR rel_to = 1)

Ezzel ugye lekérem a kapcsolatokat. Ahhoz szeretnék segítséget kérni, hogy mi az az SQL függvény, amivel le tudom kérni a kapcsolataimat és hozzá is tudom csatolni az 'users' megfelelő sorát?

Elvben valahogy így nézne ki:
SELECT * FROM relations LEFT JOIN users ON (IF rel_from = 1 THEN rel_to ELSE rel_from) = users_id WHERE (rel_from = 1 OR rel_to = 1)

Kiválasztok mindent a relations táblából és hozzácsatolom az users táblát (ha én jelöltem be, vagyis a rel_from = 1(én), akkor a rel_to a csatoló pont, egyébként a rel_from a csatoló pont) ott, ahol a (rel_from, vagy a rel_to = 1)
//Kérlek ne vegyétek most figyelembe, hogy nem jól hivatkoztam az oszlopokra//

Vagy eleve rosszul tárolom a kapcsolatokat? Mindenféle kritikát, ötletet elfogadok. A segítséget, pedig nagyon megköszönöm!

Ábel
 
1

index

janoszen · 2010. Már. 13. (Szo), 08.02
Szerintem, kerd le kulon a user adatait, mert egyreszt tudomasom szerint a MySQL in dex es query cache hasznalata ilyen kifejezesekre suboptimalis, masreszt ugy a userek adatait tudod PHP oldalon cachelni.
2

rel_from nem elég?

zzrek · 2010. Már. 13. (Szo), 10.23
Ha úgyis benne van a relations táblában a from-to pár, akkor minden "from"-hoz tartozik egy "to" is egy másik rekordban, vagyis elég lenne az egyik alapján kapcsolódást keresni, nem?
3

csak egyszer

abicska · 2010. Már. 13. (Szo), 14.41
Azért így kérem le, mert két felhasználó között csak egyszer tárolom a kapcsolatot. Gondolod, hogy érdemes lenne kétszer?
Egy "ismerősnekjelölés elfogadásnál" tároljam oda-vissza a kapcsolatot?
4

Akár

janoszen · 2010. Már. 13. (Szo), 18.37
Próbáld ki azt, hogy eltárolod az eredeti adatot és abból generálsz egy "keresőtáblát".
5

Légyszíves

abicska · 2010. Már. 13. (Szo), 18.45
Légyszíves ezt fejtsd ki bővebben, mert nem értem mire gondolsz eredeti adat néven.
6

persze

zzrek · 2010. Már. 13. (Szo), 21.53
Szerintem igen.
Ami egy felhasználóra vonatkozik, azt érdemes hozzá kötődően tárolni, úgy átláthatóbb és gyorsabb.
7

?

abicska · 2010. Már. 13. (Szo), 23.33
Gondoljuk végig akkor.
Jelenleg az oldalnak 3.500 aktív tagja van. Ha csak egy átlag 50 ismerős/emberrel számolok (ami talán nem sok, mert ugye lesz, aki használja majd és lesz, aki egyáltalán nem), akkor 3.500x50x2= 350.000 sor. Nem lesz így óriási a tábla és nem lesz így iszonyat lassú a keresés/lekérdezés?

(Ne vedd tolakodásnak a kérdést, csak gondolkodom) :)

Ábel
8

nem óriási

zzrek · 2010. Már. 13. (Szo), 23.53
Szerintem ez nem óriási. Csak egy párosítótábláról beszélünk. Ha 3500 tag van, akkor az ID lehet akár 2 bájtos is (már az is 65536 lehetőség, tehát felülméreteztük) és így a 350 000 sor az 350 000*4 bájt, vagyis néhány megabájtos nagyságrendű. Egyébként meg ennek a fele minimum kellene. Nem nagy különbség, de a keresés (stb) egyszerűbb.
9

rendben

abicska · 2010. Már. 14. (V), 01.07
Igazából így valóban könnyebb a helyzet, mert akkor tényleg csak annyi a dolgom, hogy a rel_from = én-eket lekérdezem és pont.
Tehát akkor minden új ismerősnek jelölésnél beszúrom a sort egyszer úgy hogy a rel_from = én utána rel_from = ő ugye?
Viszont akkor hogy érdemes kialakítani a táblát? Jó így, ahogy most van?

relations_id int(11) UNSIGNED AUTO_INCREMENT
relations_from int(11) UNSIGNED users->id
relations_to int(11) UNSIGNED users->id
relations_time timestamp ON_UPDATE_CURR_TMPSTMP
relations_accept tinyint(1) UNSIGNED


Elgondolkodtam azon is, hogy vajon érdemes és szabad e session-ben tárolni az ismerősök ID-jét és NICK-jét?
Ezt azért, mert viszonylag sokszor kell elérnem az ismerősöket és szeretném kímélni a szervert és magamat is a "bocs, de nagy a szerver terheltsége miattad" levelektől.
10

Csak ötletelek

zzrek · 2010. Már. 14. (V), 10.11
Csak ötletelek:
Szerintem a párosítótáblában nem kell a rekordoknak plusz egyedi id. A párosítást pedig úgy tárolnám, hogy eltárolnám felhasználó azonosítóját, mellé hogy ki az ismerőse, és az accept bájton belül adnám meg az irányt flagként hogy ebből most a kérdéses user indította a jelölést, vagy őt jelölte-e meg az ismerőse. Így könnyen legyűjthető lenne hogy kinek ki az ismerőse és az accept jobban ki lenne használva. Az acceptbe lehetne tenni egy olyan bitet is akár, amivel a felhasználó jelölhetné, hogy fontos-e a kapcsolat a számára, vagy nem, stb.

Szerintem nem érdemes a session-ben tárolni, csak akkor ha szinte minden lekéréskor kezdesz vele valamit. Esetleg csak a fontos ismerősöket, ha azt mindenképp ki akarod rakni.
11

Légyszíves

abicska · 2010. Már. 14. (V), 14.19
Ezek nagyon hasznos tanácsok! Köszönöm!
Ha megkérlek szépen, meg tudnád csinálni nekem ezt a táblát, mert bevallom őszintén, hogy flageket nem használtam még sosem. És így, ezt példaként használva könnyen meg tudom érteni, hogy mire is valók és hogyan használhatom őket. Hogyan tudok flagre, illetve a plusz egy bitre rákérdezni SQL-ben és PHP-ban?
Köszönöm mégegyszer!

Ábel
12

nem bonyolult

zzrek · 2010. Már. 15. (H), 00.03
Nem gondoltam nagyon bonyolultra. Mivel ID alapján a resultset eleve kicsi (50-100 ismerőse van valakinek max), a where részt további feltétellel még kisebbre szűkítheted.
Ha mondjuk az accept flaget magas (pl. 64 értékű) bitre rakod, akkor a where-t kiegészíted azzal, hogy ... "and accept>63" és akkor máris csak azok jönnek le, amik visszaigazolt kapcsolatok. Lehet persze bitenként is bogarászni, a mysql is ismeri a bitműveleteket.
mysql bitwise operators
Ennél mélyebben én sem foglalkoztam vele, elképzelhető hogy vannak spéci ehhez igazodó adattípusok is, de szerintem itt nem szükséges ilyesmi.