Szó sincs spanyol viszról. Nem olvastam még tervezési mintákról, nagyon nem is találtam még.
Köszi az infót. Az adatok lekérésére jó lehet amit utólag írtam? Vagy más megoldás lenne rá a jobb?

Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com

Sok mindent írtál. Az biztos, hogy ebben az esetben lesz egy select-ed, aminek lesz annyi join-ja, ahány mezőben használod a paraméter Id-jait.
Ez így csúnyának fog látszódni, pláne eg egy soros select * from tábla-hoz képest, de hidd el a TSQL-t nem fogja zavarni. Picit teljesítményben persze rosszabb egy select 40 join-nal, de ha abból a 40-ből mind a 40 ugyanannak a táblának ugyanaz a mezője, akkor nem vészes a dolog. Az SQL-ed viszont kevesebb memóriát, tárhelyet fog használni a normalizálásnak hála, ami hoszting cégek esetében előny.
Egy jótanács. Azért ne akarj mindent normalizálni. Pl. kezesség bal - jobb. Ezt egy sima bit mezővel elég megoldani, nem kell, hogy ehhez legyen két paramétered, mint 1 - bal, 2 - jobb.
Még egy jótanács, ha már normalizálunk, és táblát tervezünk. Ne int-ként, hanem tinyint, smallint ilyesmikként kezeld a mezőket. Ezzel további sok byte-ot lehet nyerni mezőnként. És úgy sincs több százezer választható opció egy adott mezőhöz.

Én kérek elnézést!

Igazából a sebesség lenne a fontosabb számomra, inkább nagyobb látogatottság lesz, mint sok adat a táblákban.

Akkor a modellből visszafejtést te el is veted? Csak, mert azt pl még leprogramozni is könnyebb a sok join miatt.

Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com

"Akkor te külön kapcsolótáblát tennél mondjuk a 40 mezőhöz? "
Hogy mi van? Te valamit nagyon félreérthettél.
Én azt mondtam, hogy nehogy már ismétlődően stringeket tárolj, hogy sokszor előforduljon, hogy "szemszin", "szemszin", "szemszin", 'hajszin", "hajszin", "hajszin".............. Mi van, ha egyszer meg akarod változtatni az ember által is olvasható, stringesített nevét? Ha lesz mondjuk 5000 felhasználód, akkor 5000 helyen cserélsz majd le egy stringet?
Egy teljesen egyedi azonosítót viszont valószínűleg nem akarnál megváltoztatni, mert tök felesleges.
Ráadásul itt tök feleslegesen stringeket tárolsz, amikor tárolhatnál tiny/smallinteket is mondjuk...

A lekérdezéshez meg elég a paraméter nevét tartalmazó táblát hozzákapcsolni, ha név szerint szeretnél lekérdezni...
ha meg "nincs kedved" joinolgatni 2-3-4 táblát - egy szebb megoldást választva -, akkor válassz másik szakmát. (bocs, de ezt muszáj volt )

==============

(#850) martonx :
hát az szerintem meg nagyon nem "szabályos menet", hogy mindenhol ismétlődően stringeket tárol, mint a "hajszin", "szemszin", stb. stringek...
Tök jó, hogy megdicséred, de ne akkor tedd, amikor rossz módszert alkalmaz.

[ Szerkesztve ]

Sk8erPeter

Modellből visszafejtés nagyon nem szép megoldás. Ráadásul simán el tudok olyan helyzetet képzelni, mikor hátulról akarsz adatokat lekérni a DB-dből, és akkor hol van a PHP-s modelled? Szvsz gányolás.

Én kérek elnézést!

Lehet nem voltam elég érthető? Én arra a módszerre értettem a szabályosat, hogy van egy paraméter táblája, és ebből csak az ID-ket tárolja le ténylegesen. Ezért is írtam a normalizálásról, meg a Paraméter tábláról.

Én kérek elnézést!

Dehogyis, az hajszin, szemszin csak a fő tábla mezője lenne, illetve a második kereszttáblában is csak amiatt, hogy számomra jól értelmezhető legyen. Lásd "1." hsz-emet.

Pont, hogy tinyint-eket akarok tárolni.
40-50 mezőhöz, ha mondjuk lesz olyan 300-400 sor sor a kereszt táblában. Ahol csak 1 mező a varchar és csak amitt, hogy Én tudjam legalább, hogy mi az.

2-3-4 táblát join-olni? He? csak 1 táblát kellene a fő mellé, de az on záradékban lenne egy pár bejegyzés 40-50 mezőnél.

Lényegében egy portál szerű dolog lenne, de csak 500-600 felhasználóról beszélünk!!! Nem 5000-6000.

Gondolkozok rajta, hogy kőműves leszek.

martonx: Köszi, akkor marad a join.

Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com

Erre van valakinek ötlete, hogy lehetne megoldani union nélkül?

Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com

"2-3-4 táblát join-olni? He? csak 1 táblát kellene a fő mellé, de az on záradékban lenne egy pár bejegyzés 40-50 mezőnél."
Hát nem tudom, ez neked hogy jön ki.

A legegyszerűbb eseteket mondom.
- 1 tábla a paraméter (szemszín, hajszín, stb.) id-jának és ember által olvasható nevének; esetleg lehet machine_name-je is, ami nem tartalmaz ékezeteket, stb., csak olvashatóbb azonosításra szolgál (opcionális). Vegyük azt az esetet, hogy mondjuk nem kívánod lefordítani a paraméterek (szemszín, hajszín, stb.) nevét, VAGY ha lefordítod, akkor ugyanabba a táblába bedobálod külön mezőként a fordításokat nyelvek szerint (bár elvileg szét kéne bontani, és lenne mondjuk egy id-je egy fordítási "csomópontnak", ahogy már említettem). Szóval
id | name
(vagy translation_node_id)
- 1 tábla a paraméterek (szemszín, hajszín, stb.) lehetséges értékeinek (pl. szemszín: barna, zöld; hajszín: ugyanezek, stb.), tehát pl.
param_id | param_value. Ez szebben megint inkább külön id-val lenne tárolva, tehát param_id | param_value_id felosztásban, és a paraméterek lehetséges értékeinek lenne tök általános külön táblája is; ez azért is lehet érdekes, mert a szemszínek és hajszínek közt sok egyező is lehet (pl. barna).
- 1 tábla a felhasználók által beállított paramétereknek; lehet esetleg egy bitmezővel (vagy tinyint 0, 1) jelezni, hogy saját beállított paraméteréről, vagy a kívánt partner paramétereiről van szó; így pl.
user_id | param_id | param_value_id | is_own
felosztás.

Ez egy lehetséges megoldás. És igen, a feltételek között az egyezőségek vizsgálatakor elég sok paraméter fog szerepelni, ha OR-ral választod el, akkor még paraméterek egyezőségét is tudod vizsgálni százalékosan, egyetlen lekérdezéssel akár... tehát rengeteg előnye van ennek a felosztásnak (tapasztalat).

"csak 500-600 felhasználóról beszélünk!!! Nem 5000-6000."
500-600 felhasználónál sem mindegy, meddig tart egy lekérdezés eredményeinek megmutatása. Ha jól értem, az oldal legfőbb profilja egyfajta társkeresés lenne, így itt pont ez lehet a szűk keresztmetszet a sebességben a sok keresgélés miatt.

Sk8erPeter

Ja, akkor bocs, ezek szerint félreértettem!

Sk8erPeter

Igen, ezt értem én is. Csak az on miatt nagyon sok lekérdezést kellene magamtól megírni.

Az unios kérdésre meg ezt találtam:
select h.id, h.pid, ifnull(k.id, 1000) as sorrend
from tbl_hirdetes h
left join tbl_kiemeles_fizetve k
on (h.pid=k.kuid)
where ((k.k_ido<=1346955990 and k.v_ido>=1346955990) or k.id is null)
order by sorrend

Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com

Sziasztok,

Megint meggyült a bajom egy query-vel. Egy intervallumra szeretnék lekérdezni, de mivel a date_time formátuma '%Y%m%d%H%i%s' ezért ez a query nem fut le, azaz nem ad vissza értékelhető eredmény.
Tudnátok segíteni, hogy mit kellene módosítanom?
SELECT * FROM li_mtsn_index where date_time < (DATE_SUB(NOW(), INTERVAL 1 DAY)) order by date_time;

A tudást mástól kapjuk, a siker a mi tehetségünk - Remember: Your life – Your choices!

Szia !

SELECT * FROM li_mtsn_index WHERE date_time < now() - INTERVAL 1 DAY ORDER BY date_time DESC;

Próbáld meg így.

Na, ez az unios helyettesítés mégsem annyira jó. Ugyanis ha már valaki volt kiemelt, akkor az nem jelenik meg a listában, hacsak nem vesz ismét kiemelést. Ötlet rá?

Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com

Nem lehetne egy táblával megoldani a dolgot? A kiemelés táblából generálnád az egészet úgy, hogy akinél nincs töltve a "mettol", "meddig" és "hely_erteke" mező, azoknak - ahogy írtad - 1000-et adnál, a többieknek pedig a "hely_erteke" mező értékét.

2 tábla mindenféleképp kellene, 1 tábla kevés az adatok miatt.

Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com

De miért ne lehetne egy olyan tábla, hogy:

id | user_id | sorrend | mettol | meddig | hely_erteke

...és ebből generálnád a tényleges sorrendet az utolsó 4 mező alapján.

A kiegészítő paramétereket nyilván nem kézzel kéne hozzáírnod, hanem mondjuk legenerálni.
Amúgy hány paraméter van?

Egyébként próbáld ki a dbForge Studio for MySQL progit, szerintem iszonyat jó, sokkal jobb, mint a MySQL Workbench, nekem komplex query-k összeállításához való segítségként nagyon jól jött már párszor. Van, amikor nem áll össze fejben a query (pl. nagyon összetetteknél már belekavarodsz), és ilyenkor egy ilyen grafikus alapú program elég jól jön.

===
A unionos kérdésre azért nem reagálok, mert ott inkább először visszakérdeznék, de akkor meg jössz azzal, hogy na már megint én vagyok a hülye, mert nem értem a kérdésedet egyből.

[ Szerkesztve ]

Sk8erPeter

Hát, mert most akkor emiatt csináljak még egy táblát?
Biztos meglehet oldani, csak kicsit kacifántosan.
Lehet, hogy a left join után kellene tennem még egy select-et, ami csak az aktuális kiemeléseket íratja ki. Utána meg már csak a maradék kell.

Sk8erPeter: Apollo17hu pedig érti.

[ Szerkesztve ]

Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com

Mondom én, néha jó aludni rá egyet és friss erővel nekiesni megint.

SELECT t.id, t.cim, (t.nap_2_0) as start_time, (t.nap_2_1) as end_time, t.telszam, t.pid, t.kid, ifnull(k.kid, 1000) as sorrend
FROM `tbl_hirdetes` t
LEFT JOIN (
select kuid, kid from tbl_kiemeles_fizetve where k_ido<=1347353832 and v_ido>=1347353832
) k ON (t.pid=k.kuid)
order by sorrend

Egyelőre jónak tűnik. Majd kiderül...

Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com

Jó, akkor elmondom a problémámat (egyébként gondolhatod, h ezeket segítő szándékkal mondom Te is sokszor visszakérdezel, úgyhogy ne szóljá' be ) az itt írtakkal:
ha jól értem, vannak hirdetések "valamikre" az oldalon, amiket le lehet foglalni bizonyos időtartamra. Vagy meg lehet venni. Vagy kiemeltté lehet nyilvánítani egy adott hirdetést. Mittudomén, melyik, ez nem volt egyértelmű, pedig sokat segítene az érdemi megvalósításban. Vegyük mondjuk azt, h van egy kéró, amit bérbe lehet venni, megveszi mondjuk egy júzer az X-től Y-ig tartó időtartam erejéig. VAGY van egy júzer, aki felrak hirdetést, és azt kiemeltté lehet nyilvánítani, és akkor prioritást élvez a többi hirdetéssel szemben. De azt írod, "A kiemeléseknél van egy hely értéke, ami azt mutatja, hogy melyik helyet ki vetette meg mettől meddig." - attól függ a hely értéke, hogy mennyi ideig vette meg valaki? Vagy mennyi ideig számít kiemelt hirdetésnek?
Ez akkor ha jól értettem, változna mondjuk hetenként, mert egy-egy hétre lehet "megvenni" (ki tudja milyen értelemben) ezeket a helyeket. Akkor viszont csak adott időtartamra érdekes egy hely értéke, nem értem, miért akarod ezt nullázni: "Ha a következő hétre nem vett helyet akkor lenullázom az értékét." Adott hétre vonatkozik az érték, akkor a következő hétnél az előző hétre vonatkozó értékkel nem kell foglalkozni, újabb sor kerül a táblába, és annyi. De mondom, mindenféle megvalósítási kérdés a konkrét, jobban specifikált feladattól függene. Lehet, hogy szebben is meg lehetne oldani a feladatodat. Van egyszer user_id a hirdetés táblájában, meg a kiemelés táblában. Feltételezem, ennek az az oka, hogy van egyszer a hirdető, meg van egyszer a vásárló. De akkor ezek szerint nem a hirdetés kiemeltté minősítéséről van szó. Tehát körbe-körbe csavarodik valahogy ez a sztori, ha elsőre elolvasom a hsz.-edet, mert sztem a specifikáció így hiányos, és nehéz rá megmondani a tutit. De ha azóta megoldottad, akkor végül is nekem mindegy.

==============
Amúgy erre nem nagyon reagáltál, hogy mi is a gondod vele.

[ Szerkesztve ]

Sk8erPeter

Adott a 2 tábla. Mindenki hirdethet az oldalon, de ha gondolja akkor ki is emelheti magát, adott hétre, adott helyre*.
*adott hely: 100db kiemelési hely van. Az 1. van legelöl, a 100. van a legvégén.

A kiemelés táblában azért van uid, hogy valamivel össze tudjam kapcsolni a 2 táblát.

Tehát, van a lekérdezés, ami már jól megy.
Itt ugye lekérdezi az összes felhasználót a hirdetés táblából, akik adott kategóriában hirdetnek. Ha van az aktuális időpontban lekérdezése, akkor ahhoz az 1-100 közötti értéket hozzárendeli. Ez lesz az order értéke.
Akiknek nincs adott hétre kiemelése, azoknak pedig 1000 lesz ez az order érték, így a lista legvégén lesznek.

Én jelenleg ezzel értem el ezt a lekérdezést. Lehet van jobb, egyszerűbb, de nem vagyok egy sql májer.

SELECT t.id, t.cim, (t.nap_2_0) as start_time, (t.nap_2_1) as end_time, t.telszam, t.pid, t.kid, ifnull(k.kid, 1000) as sorrend
FROM `tbl_hirdetes` t
LEFT JOIN (
select kuid, kid from tbl_kiemeles_fizetve where k_ido<=1347353832 and v_ido>=1347353832
) k ON (t.pid=k.kuid)
order by sorrend

A másikra meg annyi, hogy én jobbnak találtam inkább varchar-kánt menteni az adatbázisban. Emiatt páran biztos megköveznek majd, meg gányolás...de mindegy. Én ezt találtam most a legjobb megoldásnak. AR-ben nem fogok, mindent join-olni. Illetve nem is vagyok annyira megfizetve, hogy ezzel szenvedjek.

Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com

Kurvajó ez a progi, kicsit probálgattam a trial-t , tök bonyolult queryket elsőre össze kattingattam 1perc alatt.

Hát, mert most akkor emiatt csináljak még egy táblát?

Egyetlen táblával gondoltam az egészet:

id | user_id | sorrend (Kell egyáltalán ez a mező?) | mettol | meddig | hely_erteke | ...

SELECT id
,user_id
,CASE WHEN mettol <= sysdate AND meddig > sysdate
THEN hely_erteke
ELSE 1000 -- Vagy sorrend mező?
END
,...
FROM egyetlen_tabla
ORDER BY 3

Pont ezt írtam fentebb, hogy a hirdetes táblából nekem mindenki kell. A kiemeles_fizetve táblából pedig megtudom, hogy kik azok akik kivannak emelve.

Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com

Ebben benne van mindenki. Aki ki van emelve, annál a "mettol", "meddig" és "hely_erteke" töltött, a többinél null. Ha null, akkor 1000-et kap a sorrend felállításakor. Ha ki van emelve, akkor a "hely_erteke" mező értékét kapja.

Nem kell táblákat kötögetni, csak egy elágazást berakni a SELECT utáni felsorolásba.

[ Szerkesztve ]

Hát, én ezt mindig nem értem, hogy ez az egyetlen_tabla honnan származtatik.

Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com

id | user_id | (sorrend) | mettol | meddig | hely_erteke | ...

Ez az egy táblád lenne. Lényegében a "hirdetes_tabla" táblád kiegészítve a "mettol", "meddig" és "hely_erteke" mezőkkel a "kiemeles_tabla" tábládból, ami így feleslegessé válik.
Ennél egyszerűbben nem tudom.

És ezeket az értékeket, hogy írnám át? Számomra még mindig nem tiszta a kép.
Hirdetésenként van 7 kategória, kiemelésenként van 2. Az 7*2 féle kiemelés.

Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com

Ahogy a "kiemeles_tabla" tábládban írod, úgy.

Ez a sok kategória meg kétféle kiemelés nekem új, így valószínűleg jobb is, hogy külön táblába szedted őket, de ebben nincs tapasztalatom, hogy melyik az erőforrás-igényesebb megoldás.

Hanyagolom inkább ezt.

Végre van egy kis szabadidőm, elkezdtem tervezni a saját oldalamat.
A postokhoz a hozzászólásokat úgy akarom kezelni, mint itt a PH!-n van. Tehát ha valaki hozzászól egy cikkhez vagy valamihez, akkor az a fórumban fog megjelenni. Ezt nem tudom még, hogy kössem össze post-forum.

A forum valahogy így nézne ki:
//itt ha a parent értéke 0 akkor az a fő kategóriában van, ha nem akkor a megadott forum id alá tartozik
//nem jöttem rá, hogy itt mi legyen még, kellene még egy sor aminek postid a neve, ha 0 akkor az nem post. Viszont így hogy kötöm össze a post táblával?
id | Egysoros poszt | 1 | 1201231231 | 3 | 2

[ Szerkesztve ]

Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com

"A kiemelés táblában azért van uid, hogy valamivel össze tudjam kapcsolni a 2 táblát. "
Miért nem a hirdetés id-vel kapcsolod össze? A kiemelés a hirdetésre vonatkozik, a hirdetés megvásárlója meg egyértelmű, hogy kicsoda, elég egyszer tárolni. Mivel a hirdetés részleteit boncolgatod tovább, tök értelmetlen a user id-t letárolni a külön táblában. Az összekapcsolás is egyértelműbb lenne.
A kérdéseimre meg nem nagyon válaszoltál, úgyhogy úgy veszem, hogy nem kell neked a segítség.

"A másikra meg annyi, hogy én jobbnak találtam inkább varchar-kánt menteni az adatbázisban"
Hát felőlem... de ha majd a teljesítmény-szempontok kerülnek majd előtérbe (keresés lassabb lesz, mert szövegalapú keresgélést kell végrehajtani, nem pl. egy tinyintre kell rákeresni, annak mentén összekapcsolni a táblákat), lehet, hogy változtatnod kell majd az adatbázis-struktúrát, és akkor majd szidni fogod magad, hogy miért nem alakítottad ki eleve jól. Mondjuk ha akkor újabb lóvét adnak, akkor nyilván nem.

=================

(#873) Soak :
jaja, én is sokszor hasznát vettem már. Főleg akkor jön jól, amikor nincs kedved gondolkozni.

=================

(#881) Speeedfire :
most ez ujjgyakorlat? Vagy miért nem használsz tényleg valami CMS-t? (pl. Drupalt, ha már van tapasztalatod vele...)
Miért kezded minden táblád nevét tbl_ prefix-szel? Mivel adatbázisban van, elég egyértelmű, hogy itt táblák lesznek.

Amúgy mi az az "ext" mező a tbl_post_items-nél?
Az meg remélem csak egy rossz vicc, hogy a posthoz tartozó tageket TEXT-ként akarod letárolni. A másik, hogy ha már külön táblád van a tbl_forum-nak, akkor ahhoz kéne kapcsolni a tageket, nem a posthoz - vagy minden hozzászólásnak külön taget szeretnél? Gondolom nem.
De az mindenesetre biztos, hogy a tagek összekapcsolását egy teljesen különálló táblában kéne megcsinálni, nem pedig egy TEXT típusú mezőben...
A usernél a saltot miért tárolod külön?
Minél többet nézem a struktúrádat, annál furább dolgokat látok. Miért kell külön tbl_comment és tbl_post tábla a FÓRUMHOZ? Most akkor kommentálni is lehet a fórumot, meg külön hozzászólást is lehet írni? Mi a különbség? Ha kommentálni lehet, akkor már miért nem magát a bejegyzést, ahogy pl. stackoverflow-n van?
Na, most inkább nem nézem tovább.

(#883) Speeedfire: miért, régen nem volt komolyabb?

[ Szerkesztve ]

Sk8erPeter

A hirdetes_id is opció lehet, de itt inkább a juzerek vannak előtérben. Jobbnak láttam, inkább a user_id-t használni erre.
Valóban nem kell már a segítség, amilyen infó kellett azt megkaptam.

Pont, hogy a teljesítmény miatt (részben) maradtam a varchar mellett. Nagyon sok keresés szerintem nem fog itt lenni. Szinte az összes hirdető az emberek arcába lesz nyomva, így csak görgetnie kell és nézegeti a felhasználókat. Mivel te tudod már milyen tartalmú oldal, ajánlom nézd meg a konkurenciát.
De majd meglátjuk, hogy mit fog majd csinálni az oldal.

Eddig is cms-t (drupalt) használtam, de nekem egyedibb megoldásokra, jobban fekszik egy saját kód, mint egy cms.
Minek kell a prefix? Hátha lesznek mással kapcsolatos táblák is az adatbázisban. Nem tudom, ezt így szoktam meg.
Az ext mező a fájl kiterjesztése. Több féle fájl mehet egy bejegyzéshez. Akár kép, akár pdf stb. Képeknél meg jobb szeretem így használni, ha vannak kisebb/nagyobb képek. Könnyebb belinkelni a képeket. valami.tn.jpg/valami.jpg/valami.small.jpg

Miért fűzném a tag-eket a fórumhoz? A blogokhoz kell a tag.
User salt. Mégis hol kellene ezt tárolni?

Minden egyes bejegyzéshez tartozik egy fórum és a fórumhoz tartozik a comment. A fórum csak a fórum címeket tárolja el. Kicsit úgy, mint itt a PH!-n.

Ez az újabb, javított verzsön.

De, régen is komolyabb volt.

Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com

"A hirdetes_id is opció lehet, de itt inkább a juzerek vannak előtérben."
Ez itt attól még sztem nem szempont, mert a konkrét hirdetést boncolgatod tovább, arra jelölsz meg külön táblában kiemelést, tehát a hirdetés_id szerint lenne értelme összekapcsolni a két táblát.

"Pont, hogy a teljesítmény miatt (részben) maradtam a varchar mellett."
Ezt kifejtenéd?
Ha tinyint vs. varchar, akkor az utóbbi mellett keresés ideje szempontjából nem túl sok szempont szól.....

"Nagyon sok keresés szerintem nem fog itt lenni."
Szép, magyaros mondattal jól megaszontad.

"Szinte az összes hirdető az emberek arcába lesz nyomva, így csak görgetnie kell és nézegeti a felhasználókat. Mivel te tudod már milyen tartalmú oldal, ajánlom nézd meg a konkurenciát. "
Még mindig nem látok semmilyen érvet amellett, hogy varchar legyen a mező. Mi köze ennek ahhoz, hogy néz ki a többi oldal? Attól még nem látod, a háttérben hogy oldják meg, az, hogy a frontendre hogyan kerül ki a tartalom, nem befolyásolja azt, hogy hogyan kellene megoldani szépen a háttérben.

"Minek kell a prefix? Hátha lesznek mással kapcsolatos táblák is az adatbázisban."
A prefix önmagában indokolt lenne, de inkább úgy, hogy egyértelműen jelölsz vele valamit, pl. application id-t vagy hasonlót.

"Miért fűzném a tag-eket a fórumhoz? A blogokhoz kell a tag."
A korábbi struktúrádban TEXT-et jelöltél meg a tagre, ez volt az elsődleges gond, de látom azt már legalább azóta javítottad.
A táblaszerkezet meg nálad közel sem volt egyértelmű, inkább félrevezető: volt forum tábla, volt postokat gyűjtő tábla, meg volt comment tábla. Ebből olyan, mintha a fórumokhoz lehetne postot is írni, meg kommentet is. Erre mondtam, hogy ennek úgy van értelme, ahogy a stackoverflow-n van, de ott mondjuk az is bonyolítja, hogy a postok majdnem ugyanúgy kezelendőek, ahogy az első, nyitópost is, mert mindet lehet pontozni, meg mindet el lehet fogadni, mint megfelelő választ, kivéve az első, nyitópostot.
A tagek meg csak magára a kérdésre kellenek, ami az elnevezéseidből úgy tűnt, magába a forum táblába tartozik, mint gyűjtőtábla. De akkor ezek szerint csak nem voltak egyértelműek az elnevezések.

Amúgy csak azért kérdeztem rá, miért nem CMS-t használsz erre a célra, mert mások már eleget szoptak azzal, hogy megfelelő táblastruktúrát kialakítsanak ilyesmire, mint pl. a fórum, ami Drupalnál eleve a core része. Mondjuk ha tanulási céllal akarsz sajátot fejleszteni, akkor oké. De ha a könnyű továbbfejleszthetőség is cél, akkor ezerszer jobban járnál pl. egy Drupallal (persze minimum 7-es verzió), nagyon jól testreszabhatóak a fórumok is, jó modulok készültek hozzá.

Sk8erPeter

A tbl_forum-hoz nem tartozik status, pedig kellene, illetve szóba jöhet más táblák esetén is még.

Ha pakolsz a rendszerbe állapotokat mutató oszlopokat, akkor ki kellene vezetni a lehetséges értékeket külön táblába, pl. tbl_forum_status. Ezt sokan el szokták felejteni, pedig integritást lehet vele növelni, plusz sem programkód, sem adatbázisoldalról nem kell keresgetni, hogy az "1"-es állapot mégis mit takar, plusz pl. tárolt eljárások írásánál minden kiegészítőinformáció jól jöhet.

A tbl_user táblában miért van benne a salt?

Következetlen a táblák elnevezése, néhol többes, máshol egyes számban írod.

A tbl_ prefix nem rossz ötlet, hasznos tud lenni, mi pl. a táblákat pont nem látjuk el prefix-szel, de a view-ok v-vel, user defined function-ok uf/udf-fel kezdődnek, tárolt eljárások pedig usp-vel, így mindig lehet tudni, hogy miről is van szó, ami pl. több száz soros sp-k esetében nagy előny.

Ugye lesznek majd index-ek is?

"Ez itt attól még sztem nem szempont, mert a konkrét hirdetést boncolgatod tovább, arra jelölsz meg külön táblában kiemelést, tehát a hirdetés_id szerint lenne értelme összekapcsolni a két táblát."
A hirdetőknek vannak jutalom tallérjaik, egyenlegük stb stb.

Ezt kifejtenéd?
Ha tinyint vs. varchar, akkor az utóbbi mellett keresés ideje szempontjából nem túl sok szempont szól.....
Wááá!
Pont ezt írom, hogy ezeken az oldalakon a keresés nem jellemző. Belép valaki az oldalra és előtte van 100+x hirdető az 1. oldalon a második oldalon meg megint 100+x összesen max 500-600 hirdetés. Nagyon keveset fognak az oldalra látogatók keresni hirdetőket.

Attól még nem látod, a háttérben hogy oldják meg, az, hogy a frontendre hogyan kerül ki a tartalom, nem befolyásolja azt, hogy hogyan kellene megoldani szépen a háttérben.
Nem, de látom az oldalon működését. Meg belső infókat kapok!

A prefix önmagában indokolt lenne, de inkább úgy, hogy egyértelműen jelölsz vele valamit, pl. application id-t vagy hasonlót.
Jogos, de nekem most itt nem ez volt a szempont. Legyen valahogy jelölve, melyek tartoznak az adott oldalhoz. Így később sem kell bajlódni a nevekkel, ha költözik másik szolgáltatóhoz.

A tages dolgot meg indokoltam már.
PH! copy!

Amúgy csak azért kérdeztem rá, miért nem CMS-t használsz erre a célra, mert mások már eleget szoptak azzal, hogy megfelelő táblastruktúrát kialakítsanak ilyesmire, mint pl. a fórum, ami Drupalnál eleve a core része
Adott dolgokra jó, most is drupal van rajta. Csak ha már konkrét igények vannak, akkor én azt már drupallal nem tudom megoldani.
Meg akkor már teljes mértékben úgy alakítom ki az oldalt, ahogy nekem tettszik.

Athlon64+:
A tbl_forum-hoz nem tartozik status, pedig kellene, illetve szóba jöhet más táblák esetén is még.
Azóta már azt is beleraktam, illetve egy ordert is. A status csak az aktív/inaktív miatt van benne más egyéb miatt még nem gondolkoztam rajta el.

sem adatbázisoldalról nem kell keresgetni, hogy az "1"-es állapot mégis mit takar, plusz pl. tárolt eljárások írásánál minden kiegészítőinformáció jól jöhet.
Nem tudom erre mennyire jó megoldás, de én láttam már olyat, hogy felvesznek a model-ben pár constans változót, ami ezeket hivatott megmondani.
pl

const STATUS_DRAFT=1;
const STATUS_PUBLISHED=2;
const STATUS_ARCHIVED=3;

Következetlen a táblák elnevezése, néhol többes, máshol egyes számban írod.
Hát, ezen még nem agyaltam. Csak írtam, ami eszembe jutott.

Ugye lesznek majd index-ek is?
Nyilván lesznek és vannak is.

Látom mindenki leragadt a salt mellett.
Ezt a yii-ből vettem.

A salt regisztrációkor kerül a táblába ami egy unique kulcs és amikor valakit validál a rendszer akkor ezt is nézi.

public function validatePassword($password)
{
return $this->hashPassword($password,$this->salt)===$this->password;
}

public function hashPassword($password,$salt)
{
return md5($salt.$password);
}

Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com

A salt-ot nem kell menteni, lehet olyat csinálni, hogy mindenkinek mindig random, működik a jelszóellenőrzés is, én is ilyet csináltam.

Azzal, hogy constansaid vannak, még nem vagy kisegítve SQL oldalon.

Lehet úgy is, megy így is. Ez a legszebb az egészben.

SQL-ben nem, de a model tudja és legtöbbször AR-el szoktam a lekérdezéseket megcsinálni.

Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com

Akkor te a saltot és a hash-t is lemented a user táblában?

Szerk : Ez egy elég jó és biztonságos módja a user passok tárolására.

[ Szerkesztve ]

Agyalok a monoDb-n, de majd meglátom mi lesz belőle. Vagy másra gondolsz?
Ebben nem vagyok otthon annyira.

Soak: Pontosan.

Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com

Annak nem sok értelme van, ha támadás éri az adatbázisod , e mellé még fölösleges adatbázis terhelést is jelent.

Hát, de lehet többet ér mint a semmi. Jelenleg 4 ember kérdezte meg, hogy mi a salt.

Athlon64+: Miért redundancia ez?

[ Szerkesztve ]

Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com

Nem értem ,hogy ezzel mire célzol. Valószínűleg a kérdés arra irányult, hogy mi értelme van.

"A hirdetőknek vannak jutalom tallérjaik, egyenlegük stb stb."
Attól még lehet a hirdetés_id-hoz kapcsolni.

"Nagyon keveset fognak az oldalra látogatók keresni hirdetőket."
Már megint kezdünk elbeszélni egymás mellett. Korábban még júzerek paramétereiről (hajszín, szemszín, csöcsméret, stb.) beszéltünk.
Arról beszéltem, hogy ha egyes paraméterekre szűkítenek, akkor nem mindegy a sebesség. varchar-alapú keresés meg lassabb lesz, mint a tinyintre keresés.
De nekem mindegy.

"Jogos, de nekem most itt nem ez volt a szempont. Legyen valahogy jelölve, melyek tartoznak az adott oldalhoz. Így később sem kell bajlódni a nevekkel, ha költözik másik szolgáltatóhoz."
Miért, a tbl_ prefix csak a saját védjegyed, teljesen egyedi valami?

"Adott dolgokra jó, most is drupal van rajta. Csak ha már konkrét igények vannak, akkor én azt már drupallal nem tudom megoldani."
Pedig ott a Drupal topic, meg a drupal.hu meg még számtalan potenciális segítség.
Rengeteg dolog ráadásul készen van modul formájában.
Persze az tény, hogy a Drupal-modulfejlesztés beletanulásához is bőven kell idő, meg hogy az ember átlássa a dolgokat. De ehhez nagyon jó könyvek vannak az 1. hsz.-ben a belinkelt topicban.

"Meg akkor már teljes mértékben úgy alakítom ki az oldalt, ahogy nekem tettszik."
Ez tény, de több is a potenciális hibalehetőség (pl. nincs felügyelve egy közösség által, mint a legtöbb Drupal-modul), meg egyes feladatok megvalósítása sokkal szopóbb lehet, ha mindent elölről, saját agyból és erőből kell megoldani.

Sk8erPeter