Návrh databáze pro komentáře

Pěkný den, mám v plánu pod články umístit komentáře. Bohužel můj návrh se mi moc nezdá:

Komentář má svůj PK id_komentar a s článkem je propojen pomocí FG id_clanek. Čeho se obávám je, že pokud v tabulce komentar bude tisíce záznamů, výpis komentářů u jednotlivých článků pomocí klasického dotazu SELECT bude pomalý...
Je tohle běžná praxe a moje obavy jsou zbytečné nebo se postupuje jinak? Díky.

Nebude pomalý, takto je to v pořádku.
Edit: resp. bude se zpomalovat s logaritmem počtu článků.

Takhle je to v pořádku, náročnosti se při indexu na id_clanek nemáš proč bát.

mozna OT, za coz se omlouvam, ale v cem je z praktickeho hlediska lepsi pouzivat varchar nez text

varchar je v idealnim pripade o jeden(?) byte mensi nez text, takze z hlediska mista je podle me lepsi text, na druhou stranu ma rychlejsi fulltext ne ?

Imho varchar ma nastavenou velikost, ale text je mnohem větší... Nebo se pletu?

Díky, nechám to asi tak...
VARCHAR() lze nastavit max. na 255 znaků, u php5 až na 65 535 znaků. TEXT až 65 535.

velikost VARCHARu v databázi je délka hodnoty + 1 bajt pro zaznamenání délky
velikos TEXTu v databázi je délka hodnoty + 2 bajty pro zaznamenání délky

Zásadní rozdíl mezi Varcharem a Textem je ve způsobu uložení a v algoritmech na úrovni DB enginu. Jiné možnosti a práce s indexací, způsobu zpracování stringů při porovnání, vyhledávání, nahrazování apod. varchar je oproti textu většinou výrazně rychlejší, má menší I/O costs. Varchar je obvykle uložený přímo, zatímco text je uložený ukazatelem na pozici, co se pamatuju tak dřív nešel nad textem dělat index vůbec, v některých novějších DB enginech to už jde, ale při potřebě indexu je stále vhodnější použít varchar. Při potřebě porovnávat nebo jakkoliv zahrnovat pole do JOIN podmínek nebo do WHERE podmínek, případně GROUP BY apod. je také vhodnější použít varchar. V MSSQL jde nově varchar(MAX), který už nemá omezení na 255 znaků a jde indexovat, nicméně i tam je třeba používat index s rozmyslem, pokud jde o vleký obsah dat.

Další rozdíl je ve funkcích, většina SQL funkcí pro práci se stringy jako LEN, LEFT, RIGHT atd. pracuje s VARCHAR typem nikoliv s TEXT typem. Je toho víc, ale pro základní pochopení rozdílu to snad stačí.

pri weboch by som sa toho moc nebal za niektorych predpokladov:
* celkove mnozstvo zaznamov neprekroci rozumnu hranicu (radovo 1k clankov * 100 komentarov) pred zavedenim pripadnym optimalizacii
* pod clankami neocakavas diskusie vo velikosti 10k zaznamov
* komentare sa nebudu casto menit a hlavne nie vo velkom mnozstve
* mazes spam :)

pripadne optimalizacie, resp. riesenia z praxe, ktore vsak mozu (ale nemusia) komplikovat logiku riesenia, ale jednoznacne zvysuju overhead:
* indexy, podla typu db: "cluster/necluster", pre datumy (radenie), pre rozne id (clanku, sekcie clanku - rusi 3NF) ...
* "partitioning", opat podla dostupnych prostriedkov db: komentare pre clanky z posledneho polroka (napr.) do (materializovaneho) pohladu, tabulky, zbytok zvlast; prip. vyuzit "zabudovany partitioning"
* kombinacie predchadzajucich, napr. bud indexy iba na zaznamy z posledneho roka, alebo indexy pre datumy iba na tabulku z posledneho polroka (nizsi overhead a disk space) ...

=> zavisi na preferenciach, realnych datach + behovych metadatach, ocakavanej doby odozvy a vyske investicii

Původně odeslal Paradiso

velikost VARCHARu v databázi je délka hodnoty + 1 bajt pro zaznamenání délky
velikos TEXTu v databázi je délka hodnoty + 2 bajty pro zaznamenání délky

mel jsem za to ze VARCHAR(10) ma vzdy 11 bajtu bez ohledu na to kolik ma znaku

duben
dekuji za odpoved :)

to CHAR má bajtu tolik na kolik je nastaven ;-)

Původně odeslal Twista

mozna OT, za coz se omlouvam, ale v cem je z praktickeho hlediska lepsi pouzivat varchar nez text
varchar je v idealnim pripade o jeden(?) byte mensi nez text, takze z hlediska mista je podle me lepsi text, na druhou stranu ma rychlejsi fulltext ne ?

V MySQL je jeden zásadní výkonnostní rozdíl - dočasné tabulky se sloupcem typu TEXT/BLOB se vždy vytvářejí na disku místo v RAM.
Viz http://dev.mysql.com/doc/refman/5.0/...ry-tables.html

(Ale zase pozor, VARCHAR se v tabulkách typu MEMORY ukládá s fixní šířkou, viz http://nicj.net/2011/01/20/mysql-tex...ar-performance)

Píšu si pomocné funkce pro práci s databází a nevím zda-li strukturu koncipovat tak, že
1) na začátku scriptu se připojím k databázi, provedu všechny možné funkce zahrnující operace typu SELECT, INSERT, UPDATE atd. a ke konci scriptu spojení ukončím nebo
2) každá funkce co pracuje s databází se na začátku připojí k db, provede co musí (SELECT, INSERT, UPDATE atd.) a ke konci (funkce) zase spojení ukončí.
Nevím jaká je režie spojená s připojováním a odpojováním od databáze. Probíhá tam autorizace, čili mi přijde zbytečné 10x během scriptu se připojovat/odpojovat od db, ale na druhou stranu když by každá funkce si spojení řešila sama, můžu jí volat odkudkoliv a neřešit jestli jsem v momentě volání k db připojen nebo ne... jak se prakticky řeší tohle..?

Vytvoř jedno připojení a to můžeš předávat jako parametr funkce, viz Dependency injection.