Téma: Adatbázis optimalizálás

Érdemi tapasztalattal csurig megtöltött vélemények, hálás vagyok, kimagaslóan.

TLoF,
Egy konkrét példára levetítve valami ilyesmit kapok. Adott egy tábla, amelyben tároljuk a fórumtémákat. Mivel keresőbarát url-eket használok, nem lesz elég csupán a nevet letárolni, szükséges lesz hozzá egy seoname mező is (lévén a vBulletintől eltérő módon működik).
Így aztán lesz egy elsődleges kulcs, egy auto_increment egész; lesz egy szöveges mező a téma nevének sértetlen tárolására („Téma megnevezése: ez csak egy példa”), és még egy varchar(255) a téma egyértelmű azonosítására („tema-megnevezese-ez-csak-egy-pelda”). Figyelni kell természetesen, hogy egy fórumkategórián belül ne lehessen két azonos seourl.

huncyrus,
Mivel saját igényeim vannak, az időpontot egész számként fogom letárolni - igaz, hogy a szabványos megjelenítés visszanyerése miatt pazarlás lenne, de az „1 napja”, „2 hete”, stb. formában kiiratni... Szóval nem time-ra és timestamp-ra van szükségem.
auto_increment használata nélkül bele sem mernék vágni adatbázistervezésbe.
A gyakorlati értékű példáid felbecsülhetetlenek.

MKarcsi,
Az esztelen pocsékolás tényleg kerülendő, osztom a véleményed. IPv6 miatt egyelőre nem fáj a fejem, jól beszélsz. Az elméleti határra szűkítés pedig az optimalizált tervezés része.

Mit gondoltok, megengedhetem magamnak, hogy a munkafolyamatok (sessionök) tárolására használt táblában egy varchar(32) (maga az azonosító) legyen az elsődleges kulcs? (Vagy méginkább: char(32)?)

Szerintem a varchar(32) helyett adj hozzá még egy ID mezőt a táblához, aminek a típusa legyen unsigned tinyint.
Igaz így soronként +1 bájt, de így az index mérete 1 bájt lesz és nem 32.

Köszönöm a véleményt, bár minekután a „jegyezz meg” kapcsolót használó tagok session-jét nem törlöm ki, sem a böngészőből, sem a táblából, ezért a tinyint elég kevés lesz. Egyébként is, mi ez a pesszimista feltételezés, hogy nem lépi túl a egyetlen időpillanatban az oldalt böngésző felhasználók száma a 255-öt?
Ez esetben legalább egy bigint.

Azonban úgy érzem, hogy mivel a keresés úgy is a session id-re fog irányulni, amit így is, úgy is indexeltetnem kell, visszakanyarodtunk a kiindulási pontba, és elpazaroltunk soronként egy bájtot. Mit gondolsz?

session id -ra char32 a megoldás, és ez a tábla primary key-e. Ugy nincs probléma a dologgal.

pestaa: A te esetedben én egyszerüen oldanám meg a problémát. A mysql 5-ösben a varchar 512 -ig mehet.

Tehát lenne egy táblám amiben 3 mező van, nevezzük mondjuk routingnak. felépitése:
- seourl (category/topic formában)
- type category vagy topic
- ext_id

Ahol a seourl lenne a primary key.
Igy amikor bejön a fórum url akkor a request_uri -ból rögtön 1 db select után tudod, hogy mit kell csinálnod. És mivel a seourlt nem kell feldolgoznod, ezért gyors is lessz a rendszer.

Emellé természetesen kell egy category tábla ami tartalmazza a
- categoryid
- category name
- category url
- last poster username
- last poster userid
- last posted topic name
- last posted topic url
- last post time

egy topic tábla
- topic_id
- topic name
- topic url
- topic starter ( ha akarod tárolni)
- topic start time
- topic last poster time
- topic last poster id
- topic last poster name

post tábla
- post id
- topic id
- post time
- user id
- post text
- egyébb a posthoz menteni akart adatok. (ip, ilyenek)

user tábla
- user id
- user name
- user pass
- user email
- user post count

Tessék kb az én értelmezésemben igy néze ki egy forumnak az alapja.

A fórum megjelenités szempontjából gyors lenne, hiszen a kötések mind csak id -k alapján történnek. egy egy post mentése lenne kicsit összetetteb, hiszen a post táblán kivül 2 másik helyet is frissetni kell.

Ezek az alapok, a redundancia elég nagy, hiszen egy csomó adatot olyan táblákban tárolok ahol nincs semmi keresni valója, viszont jelentősen meggyorsitja a kiszolgálást. hiszen igy egy topic megjelenitése mondjuk 2 sql query-ből megoldható (az elsőből megtudjuk hogy melyik topicot kell megjeleniteni, a másodikból a postokat amit meg kell jeleniteni és a postokhoz tartozó member adatokat. subelect eredményéhez, left join.)

Ha category-t kell listázni az pedig szintén 2 select.

A főlap pedig 1 select.

Köszönöm TLoF a mélyreható analízist, a legtöbb ponton egyezik a már megvalósított adatbázis az elképzeléseddel. Egy rugóra jár az agyunk, ahogy mondani szokás.

Noha nem fogom kihasználni a fél kilobájtos címet, megnyugtató tudni, hogy beállíthatok szöveges mezőt indexnek. Mégegyszer köszönöm.

Szerk.: Pontot nem tudok adni, pedig honorálni szerettem volna a szorgalmadat.