Návrh databáze pro komentáře

30. 11. 2011 17:25:12

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.

30. 11. 2011 17:25:12

https://webtrh.cz/diskuse/navrh-databaze-pro-komentare#reply702684

naniccz

(3 hodnocení)

30. 11. 2011 17:27:37

Nebude pomalý, takto je to v pořádku.

Edit: resp. bude se zpomalovat s logaritmem počtu článků.

30. 11. 2011 17:27:37

https://webtrh.cz/diskuse/navrh-databaze-pro-komentare#reply702683

duben

(49 hodnocení)

30. 11. 2011 17:35:09

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

30. 11. 2011 17:35:09

https://webtrh.cz/diskuse/navrh-databaze-pro-komentare#reply702682

Michal Haták

(1 hodnocení)

30. 11. 2011 17:55:56

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 ?

30. 11. 2011 17:55:56

https://webtrh.cz/diskuse/navrh-databaze-pro-komentare#reply702681

Tom

(6 hodnocení)

30. 11. 2011 18:04:33

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

30. 11. 2011 18:04:33

https://webtrh.cz/diskuse/navrh-databaze-pro-komentare#reply702680

MD1

30. 11. 2011 18:26:58

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.

30. 11. 2011 18:26:58

https://webtrh.cz/diskuse/navrh-databaze-pro-komentare#reply702679

Jan Matoušek

(12 hodnocení)

30. 11. 2011 18:35:34

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

30. 11. 2011 18:35:34

https://webtrh.cz/diskuse/navrh-databaze-pro-komentare#reply702678

duben

(49 hodnocení)

30. 11. 2011 20:04:41

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čí.

30. 11. 2011 20:04:41

https://webtrh.cz/diskuse/navrh-databaze-pro-komentare#reply702677

blob

(1 hodnocení)

30. 11. 2011 22:04:50

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

30. 11. 2011 22:04:50

https://webtrh.cz/diskuse/navrh-databaze-pro-komentare#reply702676

Michal Haták

(1 hodnocení)

1. 12. 2011 19:30:41

Napsal Paradiso;728670
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 :)

1. 12. 2011 19:30:41

https://webtrh.cz/diskuse/navrh-databaze-pro-komentare#reply702675

Jan Matoušek

(12 hodnocení)

1. 12. 2011 20:09:38

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

1. 12. 2011 20:09:38

https://webtrh.cz/diskuse/navrh-databaze-pro-komentare#reply702674

Martin Schlemmer

(36 hodnocení)

2. 12. 2011 10:20:51

Napsal Twista;728651
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/en/internal-temporary-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-text-vs-varchar-performance)

2. 12. 2011 10:20:51

https://webtrh.cz/diskuse/navrh-databaze-pro-komentare#reply702673

MD1

1. 2. 2012 23:43:41

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..?

1. 2. 2012 23:43:41

https://webtrh.cz/diskuse/navrh-databaze-pro-komentare#reply702672

Tom

(6 hodnocení)

2. 2. 2012 08:30:45

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

2. 2. 2012 08:30:45

https://webtrh.cz/diskuse/navrh-databaze-pro-komentare#reply702671

Pro odpověď se přihlašte.

Přihlásit