Mysql VARCHAR - ake najlepsie dlzky?

juho123:
„ake dlzky su odporucane davat?“
Podle maximální možné délky textu, který se má dovnitř vkládat.

ked davam mocniny dvojky (…) ci je to najlepsie riesenie?
Ne (pokud teda shodou okolností takovou délku nemají mít ukládané texty).

„Teda neexistuje ziadny vzorec pre najefektivnejsie zvolenie si dlzky?“

Vždyť ti ho Joker píše. Měla by se stanovit „podle maximální možné délky textu, který se má dovnitř vkládat“.

juho123:
Pokud budeš mít VARCHAR(200) tak ti v paměti zabere 200 bytů, v úložišti podle délky řetězce, co záznam to byte. Čili jak psali výše, maximální možná délka textu.

juho123:
„toto vsetci vieme ;-)))“
Tak o čem se tu pak bavíme?

„Ale zaujimave, ze v literaturach to davaju vzdy okolo mocniny dvojky“
A není to čistě náhodou konkrétně VARCHAR(255)?
To má jednoduché vysvětlení, ve starších verzích MySQL byla 255 maximální délka pro VARCHAR.
Jinak rozdíl tam teda je, VARCHAR delší než 255 zabírá o 1 bajt víc (viz manuál).
Ale nedomnívám se, že by to hrálo nějakou podstatnou roli (když budu mít 10 000 záznamů a samotný řetězec ve sloupci bude mít v průměru 100B, zabere to celkově s „krátkým“ VARCHAR 1,01MB a s „dlouhým“ 1,02MB).

Pokiaľ sa dobre pamätám, tak MySQL pracuje rýchlejšie s typom CHAR. Takže ak nepotrebuješ mať na konci zachované biele znaky prečo nepoužiť tento? Ja ho používam bežne..

Camo:
To bych netvrdil. Pokud budeš mít CHAR(180) a VARCHAR(180), tak se do paměti u CHAR vždy načte 180 znaků, kdežto u VARCHAR se načte tolik znaků, kolik má nejdelší řetězec. CHAR ti právě doplňuje bílé znaky do plnýho počtu. Navíc při práci jako třeba LIKE '%%' bych řekl, že bude VARCHAR na porovnáváníé rychlejší.

CHAR by byl rychlejší pouze v případě, že každý řetězec bude mít délku 180 znaků, jelikož se u CHARu neukládá velikost řetězce, jako u VARCHARU (bytově podle délky řetězce)

Ide o to, že pri type VARCHAR si Mysql pri každej bunke ukladá dĺžku reťazca, čo ju musí pri prácou s tabuľkou spomaľovať. Pri CHAR je dĺžka konštantná. Neviem ako to bude s LIKE, ale asi bude rozdiel hladne u tých dát, ktoré majú výrazne odlišnú dĺžku. Ale aj tam bude myslím pri väčších tabuľkách rýchlejší CHAR.

Camo:
„Ale aj tam bude myslím pri väčších tabuľkách rýchlejší CHAR“
CHAR bude rychlejší pouze v případech, kdy se délka řetězců blíží délce zadané hodnoty CHARU.

Dejme tomu příklad:

CHAR(100) a VARCHAR(100), kde budeme ukládat řetězce, kde nejdelší bude 60 znaků. u CHAR se uloží a pracuje stále se 100 znakama, tj. 100bytů. (V porovnávání latin, UTF-16 tuším dvojnásobek), kdežto u VARCHAR se bude pracovat pouze s 60bytama (+pár bytů informace o délce řetězce)

Bavíme-li se o práci s pamětí, pro úložiště enginu budou velikostně stejně.

Camo:
„Pokiaľ sa dobre pamätám, tak MySQL pracuje rýchlejšie s typom CHAR.“
Nakolik vím já, je to pravda v případě, že v tabulce není žádný jiný sloupec dynamického typu. Pokud jsou všechny sloupce statické, může celá tabulka být statická a tím o něco rychlejší.

Na druhou stranu bych určitě nedoporučil používat vždy CHAR.
CHAR je vhodný v případech, kdy všechny nebo skoro všechny záznamy budou obsahovat řetězec dané délky (například pro uložení MD5 hashe může být vhodný sloupec CHAR(32), protože ten hash je prostě vždycky stejně dlouhý).
Naopak v případech, kdy mám text rozdílné délky, ale maximálně o n znacích, je lepší VARCHAR.

Například: Mám nadpis, ukládaný v UTF-8, maximální délka 200 znaků, mám 1000 záznamů s průměrnou délkou 20 bajtů.
VARCHAR(200) zabere celkem 21kB. CHAR(200) zabere celkem 600kB (600B na záznam, protože rezervuje maximální délku řetězce), což už je trochu rozdíl.

Joker, Medvídek:
Chápem, čo chcete povedať. Vy vravíte, že VARCHAR ukladá len to čo tam skutočne je. Ale ja hovorím, že okrem toho ešte ukladá aj to akú to má dĺžku s čí súvisia aj nejaké výpočty pri ukladaní a čítaní nie? Takže tých Jokerových čistých 21kb sa mi nejako nevidí a o tom píšem. Nieje to náhodou s tým VARCHAROM tak ako napr. s INTEGEROM - teda, že má určitý rozsah(ktorý je vždy rovnaký) ale čísla v ňom uložené nemusia zaberať v pamäti zrovna toľko bitov aký je max rozsah. Pri veľkom objeme to určite bude mať negatívny vplyv, ale pri menšom(napr. menu/zoznam adries obrázkov...) asi nie.
Keby si to dokázal nejako lepšie vysvetliť...