Ideální návrh tabulky

Ahoj,

dělám auditko (knihu návštěv, diskusní fórum nebo jak chcete) jak asi tady každej. Chtěl bych to ale mít fakt vychytaný a tak se snažím tabulku navrhnout co nejlépe a zajímal by mě váš názor na ni.

CREATE TABLE strasnice_forum (
sekce int(11) NOT NULL,
autor varchar(255) NOT NULL,
email varchar(255),
nazev varchar(255),
text text,
datum timestamp(14) NOT NULL,
PRIMARY KEY (datum, autor),
KEY sekce (sekce)
) COMMENT='Diskusní fórum';

Tak to je ona. Jen ji trochu popíšu. 'sekce' je vždycky téma (není to tedy lineární diskuse). Na tento atribut jsem taky udělal index, jelikož přes něj se bude často dělat select (k jednomu tématu vždy několik příspěvků, stejně jako tady na wz).
Co se týče primárního klíče, tak nemám sice rád, když jsou to dva atributy zároveň a dále vím že datum není ideální pro primary key (byť v tomto spojení), ale přijde mi zbytečné tam přidávat adlší ID.
To mě přivedlo na dotaz, jak je vlastně dělaný tohle fórum na WZ.

Dík za vaše názory a připomínky.

No, s SQL moc zkušenosti nemám, s fórem taky ne, ale připadá mi podezřelý dávat jako primary key datum a autora - obojí může být stejný a mohlo by to dělat problémy (jeden "autor" bude třeba s někým debatovat v průběhu hodin a pak by to mohl být vskutku problém).

A pokud jsem ze sebe zase udělal debila, tak už si to budu jenom číst a nebudu odpovídat :-D.

Mno, měl bych to upřesnit. Datumem míním TIMESTAMP. Jsou dvě možnosti jak by to mohlo být stejný. Jedna je, že se bude hejbat s časem na servru nazpět a tutíž se čas bude opakovat. Druhá je, že ten skript bude v jedné vteřině spuštěn několikrát. Druhá možnost je při frekvenci na mých stránkách málo pravděpodobná, ale přesto je a tak ji ošetřuji tím, že doplňuji do primary key autora. Jeden člověk prostě nemůže během jedné vteřiny vložit více příspěvků. Tu první možnost (posun času na servru) ignoruji, jelikož pokud k tomu dojde, tak je pravděpodobnost, že stejný člověk zadá znovu příspěvek přesně ve stejnou sekundu po posunutí času zanedbatelně malá, že to podle mě nestojí za ošetřování.

Co se týče jedinečnosti primárního klíče, tak tou jsem si docela jist. Spíš se mi nelíbí jeho komplikovanost, ale myslím, že to je lepší než přidávat id.

Tak použij funkci auto_increment na nějáké ID - bude půjde i snadno rozřazovat příspěvky třeba po 20.

Mě je jasný jak udělat primary key když vytvořím ID. To vědět nepotřebuji. Mimochodem využívat hodnot v ID k rozdělování skupin třeba po 20 není ideální nápad a je to nepoužitelné v struktuře mé tabulky - k tomu slouží LIMIT v SELECTU.

Co mě zajímá, kdyby se tu někdo, kdo něco podobnýho dělal vyjádřil se svým názorem, jak na strukturu tabulky pro fórum, tak na problém primárního klíče: ID versus dva atributy

To jak co vytvořit vím.

Mno jak jsem tak koukal, tak všichni používají ID, tak to asi taky tak udělám, byť ten složenej PRIMARY KEY nerad opouštím.

Rozhodne bys mel pouzivat novy sloupec ID. Ze lze zaznam jednoznacne rozlisit pomoci tech dvou atributu ti verim, ale kdyz budes treba znat konkretni zaznam, se ktery chces pracovat, budes muset k nemu pristupovat pomoci ... WHERE datum='...' && autor='...' ... coz je dost clozitejsi nez jen WHERE id=123 ... Navic podle me vzroste rychlost prace MySQL serveru, coz je na webzdarma jedine plus. Popravde receno je pouziti zvl. sloupce ID daleko prirozenejsi nez tve reseni.

Datum radeji pouzivam obycejny format INT a pomoci PHP tam vkladam vysledek funkce time() ... lehceji se mi to formatuje na zobrazitelne datum, pricita a odcita, ale to je jen detail.

Jinak ja osobne mam v tabulce na forum jeste dva atributy : do jednoho ukladam verzi prohlizece ($HTTP_USER_AGENT) a ip adresu ($REMOTE_ADDR). Nic z toho nezobrazuji, ale nekdy se to docela hodi.

A nakonec NOT NULL muzes dat prakticky ke vsem sloupcum (atributum), jelikoz NULL neznamena to stejne co prazdny retezec! Pokud nekdo nezada email, tak v bunce bude prazdny retezec, nikoliv hodnota NULL.

4Johnny:

Dík za názory. S tím ID souhlasím a udělám to tak. Výhoda při použité u WHERE je jasná a to zrychlení možná také bude.

Co se týče typu INT vs. TIMESTAMP, tak je to jedno. Já do toho budu totiž vkládat také výsledek fce time() (popř. fce UNIXTIMESTAMP() v SQL, dává to stejný výsledek). Jde jen o to, že jsem té hodnotě ten typ chtěl maximálně uzpůsobit.

Další položky v tabulce nepotřebuji, neboť to fórum bude v registrované části, takže o uživatelích budu mít podrobné info jinde. Jinak někdy se to může hodit.

Co se týče NOT NULL, tak uznávám, že bude lepší ho dát všude. Jinak co to je samozřejmě vím. NULL hodnotu jsem umožnil z důvodu, abych nemusel při INSERTU použít všechny atributy, ale stejně netuším, kdy by se to hodilo.

Dík, na tuhle reakci jsem čekal, abych si to mohl v hlavě utřídit.

4Johnny:

Tak sorry. Hloupě jsem se zmílil. To je tak, když někdo čte manuál příliš rychle :-( Říkal jsem si, jak je typ TIMESTAMP skvělej, že mi tam automaticky vloží čas a nevšim jsem si, že to je ten blbej formát času a ne unixový časový razítko. Tak se budu muset vrátit opět zpět k INT a nevymíšlet nějaké novoty.

Dík