Új hozzászólás Aktív témák
-
-
PazsitZ
addikt
Összetett kulcs esetén nem. Esetleg alkalmazol egy PK oszlopot is és az id1, id2 oszlopokat simán UNIQUE-ra rakod.
PRIMARY(id1, id2)/ kulcs esetén lehet 100 kapcsolat is.
Arra kell figyelni, bár ez függ attól, hogy logikailag hogyan kezeled, hogy az (1,2) és (2,1) relációk szükségesek-e számodra vagy sem.
Ha csak a kapcsolat megléte számít az iránya nem, akkor ne engedd az ilyet, ha számít, akkor szerepeltetned kell mindkét "kapcsolatleírást" a friendship tábládban.[ Szerkesztve ]
- http://pazsitz.hu -
-
PazsitZ
addikt
A tába így néz ki:
users:
id name
1 Soak
2 PazsitZ
3 xyrelation (id elhagyható, akkor a elsődleges kulcs: (user, friend), egyéb esetben csak unique key):
id user friend
1 1 2
2 1 3kérdés ezzel magvan a kapcsolat vagy kellenek továbnbi mezők, nálad ezek szerint számít az irány tehát kell:
3 2 3
Ekkor mi kölcsönösen haverok vagyunk id:1. relation soka haverja PazsitZ-nek
id:3 PazsitZ haverja Soaknakid:2 itt csak Soak haverja xy-nak, de xy-n nem haverja Soaknak.
Amit írsz, hogy text/blob-ban tárolni egy user kapcsolatát, nem működőképes, nem tudsz kapcsolatot felállítani join-al, nehezen kezelhető...
- http://pazsitz.hu -
-
-
Soak
veterán
SELECT * FROM users LEFT JOIN relations ON users.id = relations.users_id and relations.friend_id = 65 and relations.typeofrelation = 1 GROUP BY relations.users_id
Ezzel a kóddal már majdnem ott vagyok, de valamiért mindig 1-el több usert kapok vissza és annak nincs is relation oszlopokban semmi csak NULL, mit keres ott?
szerk: Nem LEFT JOIN ,hanem JOIN csak simán. Így müködik.
[ Szerkesztve ]
-
Apollo17hu
őstag
select u.id
,u.username
,r.friend_id
,r.typeofrelation
from users u
,relations r
where 1=1
and u.id = r.users_id
and r.friend_id = 5
and r.typeofrelation = 1Ha a két táblában további mezők is szerepelnek, ami miatt duplikálódás fordulhat elő, akkor azokat ne sorold fel a SELECT-ben, hanem használj DISTINCT-et!
-
Speeedfire
nagyúr
-
Speeedfire
nagyúr
Ha jól értem akkor egy sorban 40 oszlop és mindegyikben egy ekkora "cimke"
Igen, kb így van. Ugye a címke mérete az változik, lehet 5-20 karakter is.akkor egyszerűen le lehetne dokumentálni a Classod elején, hogy mi micsoda.
Így van, én is hasonlóra gondoltam, de ha több controllerből akarom lekérdezni, akkor lehet jobb lenne egy segédtábla.Én azt javaslom, hogy legyen VARCHAR vagy TEXT , mert sokkal gyorsabban programozol ha nem kell felkeresni mindig, hogy melyik kategoria melyik szám, plusz ha esetleg csinálsz keresőt pl, akkor az URL is beszédesebb lehet. (example.com/search.php?haj=szoke&mell=nagy)
Valóban egyszerűbb, gyorsabb, viszont nem tudom, hogy teljesítményben meg mindenben melyik lenne a jobb.
Hely szempontjából lényegtelen szerintem 500-600 bejegyzésnél, viszont ha sokan nézik az oldalt akkor lehet jobb ha csak számok vannak az adatbázisban és csak akkor vannak lekérdezve a tényleges adatok, amikor kell.pl ha a user oldalát nézi valaki:
Seged_tabla::item("szemszin", 1);
//a segéd modell meg visszaadná a hozzá tartozó értéket
//valami ilyesmi lekérdezéssel
select text from seged_tabla where item=szemszin && code=1Viszont ugye itt meg több kisebb lekérdezés lenne. Ugye userenként olyan kb40/tábla. Mert ugye van még egy tábla ahol van kb 50 hasonló mező.
Ezt nem tudom hogy mérlegeljem.Több kisebb lekérdezés, vagy egy az egyben mentsek el mindent az adatbázisba.
Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com
-
-
Lacces
őstag
skálázhatóság alatt olyasmit értek, ha jól fordítom angolról, hogy amikor terhelés történik az alkalmazásnál akkor ha nő a kliensek kérése, akkor a rendszer terhelhetősége lineárisan nő, mint a mysql esetében is, és nem exponenciálisan.
Csak ahogy olvastam el lehet ezt szúrni, és nem lineárisan növekszik hanem rosszabbul... de már nem tudom melyik weboldalon, de azóta találtam más-mást is, és úgy látom, hogy ez inkább a hardverre vonatkozik (cache stb) a skálázhatóság és nem az adatbázis struktúrára. -
Lacces
őstag
Itt találtam erről a témáról leírást.
A többit köszi! . -
Sk8erPeter
nagyúr
Az előbb már írtam: nagyvállalati környezetben, bizonyos adatok kinyerése érdekében, naplózáshoz és egyéb célokhoz is. Ha nem hiszed, megadom az elérhetőségeit egyik haveromnak, ha szeretnél vele erről diskurálni, hogy egy németországi rohadt nagy cégnél miért művelnek ilyen elmebeteg dolgokat. Először én is le voltam hidalva a számokon, amikről mesélt. De félreértés ne essék, NEM MySQL-ben dolgoznak.
Sk8erPeter
-
futár
aktív tag
csak a jelszóval van gondom, a táblákat és a jelszót is látom. A progi nem telepítős, úgyhogy csak le kell mentenem a könyvtárat. És ennyi, de ugye a jelszó az valamilyen titkosítással szerepel, a progi pedig egy előre konfigurált felhasználónévvel - jelszóval kommunikál. Egy másik gépen XAMPP van telepítve, oda nem is tudtam felrakni, mert hisztizett a felhasználónév és jelszó miatt.Ha hallgattál volna, bölcs maradtál volna.
Új hozzászólás Aktív témák
- Tudományos Pandémia Klub
- Milyen processzort vegyek?
- Nvidia GPU-k jövője - amit tudni vélünk
- Politika
- Épített vízhűtés (nem kompakt) topic
- Bivalyerős lett a Poco F6 és F6 Pro
- Xbox Series X|S
- Asus Zenfone 10 - kicsit más az új kicsi
- A fociról könnyedén, egy baráti társaságban
- Gumi és felni topik
- További aktív témák...
- HP Pavilion x360 14-ek Convertible - ÚJ - 14" TOUCH notebook - i5-1235U, 16GB, 512SSD, Win11
- HP Spectre x360 16-aa0775ng - ÚJ - 16"-os OLED notebook - Intel U7 155H
- Apple 96W USB-C hálózati adapter / töltő
- 189 cm-es (75"-es) Ambilight Philips 75PUS7354/12 OLVASD VÉGIG!
- Be Quiet! SHADOW ROCK 3 Processzor Hűtő (venti nélkül) (AMD)
Állásajánlatok
Cég: Alpha Laptopszerviz Kft.
Város: Pécs
Cég: Ozeki Kft.
Város: Debrecen