Hirdetés
Új hozzászólás Aktív témák
-
válasz
adika4444
#16045
üzenetére
Az enum az egy lista, olyan típus, ahol az érték nem érdekes, csak az, hogy vannak neki valamilyen értékei, oszt majd a compiler/interpreter ad neki valamit. Ez most csak egy pszeudokód, tehát pl. DB-ben leginkább valami INT-et mentenél le.
Na most, pl. kaptál tőlem egy üzenetet, akkor valami ilyesmi lesz a rekordban:
'Ez egy üzi', 'weiss', 'adika4444', 2017-12-18 16:26:23, true, 0)A törlésnél honnan tudom hogy ki jelölte törlésre?
Egyezzünk meg abban, hogy mindig A lesz a feladó és B a címzett, ebből pedig egyértelmű, hogy ki is jelölte. -
válasz
adika4444
#16034
üzenetére
Hirtelenjében:
TABLE üzik(tartalom, kitol, kinek, időpont, olvasott, törölt)
olvasott bool
törölt enum(nem törölt, A törölte, B törölte)Hogy számolhatom meg a xy-től jött olvasatlanok számát?
select count(*) from uzik where kitol = xy and kinek = én and olvasott = nope
2. A törlés,...
Ha valaki törli, akkor átállítod az állapotot, a második törlésre törlöd az üzenetet.
[ Szerkesztve ]
-
Rickeffe
aktív tag
-
ceripapa
aktív tag
válasz
adika4444
#15717
üzenetére
Igy van kell egy külön id a sorsoknak , az első id azért kell h a táblába meg tudja különböztetni a sorokat , ha szeretnéd összevonhatók-e egy közös kulcsra a topic es opcionális belüli id -t , de sztem jobb az egyszerűbb megoldás a számodra ,
( id ,topic_id , hsz_id , text , válaszolva, ha volt ilyen akkor kiére , létrehozás ideje, módosítás ideje , aktiv ( vagy csak törlöd a hsz-t ) )
Index ai lehet a id,
Beszuraskor neked kell hozzáadni a topic id illetve neked kell le kérdezni a topic hoz tartozó uccso hsz_idt , az indexeles miatt ez eleg gyors lesz , O log2 (N) a futasideje + gyorsabb ha cashelte. -
DNReNTi
őstag
válasz
adika4444
#15717
üzenetére
Jo lesz a MySQL, nem fogsz te meg olyan vitez dolgokat csinalni, hogy elerd a korlatait. Ezzel nem bantani akarlak mielott meg felreertened. Topikon beluli sorszamozasra meg bevezthetsz egy uj mezot a hozzaszolasok tablaban, amiben ertelem szeruen azt vezeted adott topikban hanyadik az adott poszt. Ezt persze egy AI nem fogja megoldani, neked kell majd manualisan beszurni (az utolso poszt ugyanilyen topic_id-val plusz egy). Nem olyan veszett mint ahogy elsore talan latszik.
-
ceripapa
aktív tag
válasz
adika4444
#15714
üzenetére
Nem feltétlen kell és érdemes külön topicnak külön tábla , relácios algebrai szinten neked egy : egy- sok kapcsolatra van szükséged , ergo, 1 táblába kerülne a topicoknak a nevei és egy másik táblába a hsz-k, itt érdemes egy al id-t fenntartani a hsz-knek. a kapcsolod id pedig az adott , a topicneveket tartalmazo tábla egy sorának id-ja .
Vastagok az indexelt oszlopok a gyorsabb keresések miatt .
Topic tábla:
( id , topic neve , topic csoporthoz tartozo id )Hsz Tábla:
( id ,topic_id , text , válaszolva, ha volt ilyen akkor kiére , létrehozás ideje, módosítás ideje , aktiv ( vagy csak törlöd a hsz-t ) )[ Szerkesztve ]
-
DNReNTi
őstag
válasz
adika4444
#15714
üzenetére
"sql-ben minden topicnak új tábla"
Semmikeppen se igy.
Erre tokeletesen eleg ketto darab tabla, mivel a topik hozzaszolas viszony 1:n kapcsolat. Tehat pl nagyon nagyon nagyon leegyszerusitve:Topic tabla mezoi:
id, namePosts tabla mezoi:
id, topic_id, contentEbbol mar talan egyertelmu hogy a posts.topic_id a topics.id mezore fog mutatni, lehet ez akar egy kulso kulcsmegkotes is (FK), ami alapjan pontosan tudod melyik hozzaszolas melyik topikhoz tartozik.
Új hozzászólás Aktív témák
Hirdetés
- Ps5 Slim lemezes 1TB/2TB extrákkal
- HP játékra is,corei5 7200u,R5 2GB videokártya,8-16GB RAM,120GB-1TB SSD,jó állapot
- ACER UltraBook,FullHD core i5 6200u(4X2,8Ghz)8-16GB RAM,SSD,szép
- ACER SWIFT 5 970 gramm,Érintős FullHD IPS,core i5 8250u(8X3,4Ghz)Vil.bill,16GB RAM,256-512GB SSD
- Ultrakönnyű Toshiba UltraBook core i5 (4x28Ghz)Vil.bill, 8-16GB RAM,256GB SSD,jó akku