Autor Zpráva
juho123
Profil *
Ahojte,

ked vytvaram tabulku, kde mam typ VARCHAR, tak ake dlzky su odporucane davat?
Ide mi o to, ako maju byt ,,zaokruhlovane,, - teda ked davam mocniny dvojky
256, 512, 1024 ci je to najlepsie riesenie?

Ide mi o tu pamatovu efektivitu ;-)))

Dakujem velmi pekne.
Joker
Profil
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).
juho123
Profil *
Joker:
Podle maximální možné délky textu, který se má dovnitř vkládat.
Dakujem, toto vsetci vieme ;-)))

Ne
Ok, ide mi o pamatovu zlozitost, napr. ci pri kazdej dalsej mocnine dvojky si nevytvori viac pamate pre danu bunku a tak.
Teda neexistuje ziadny vzorec pre najefektivnejsie zvolenie si dlzky?
Str4wberry
Profil
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“.
Medvídek
Profil
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
Profil *
Str4wberry, Medvídek:
Dakujem Vam pani, uz mi to je jasne! ;-))

Ale zaujimave, ze v literaturach to davaju vzdy okolo mocniny dvojky, tak ma to zmylilo.


Joker:
Aj tebe dakujem :)
Joker
Profil
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).
juho123
Profil *
Joker:
Jinak rozdíl tam teda je, VARCHAR delší než 255 zabírá o 1 bajt víc (viz manuál).
No presne nieco taketo som myslel ;-)) ale ano, je pravda, ze nie je potrebne sa s tym
zaoberat. Ale aspon uz vieme, ako to vlastne je.

Dakujem.
Camo
Profil
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..
Medvídek
Profil
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)
Camo
Profil
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.
Medvídek
Profil
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ě.
Joker
Profil
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.
Camo
Profil
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ť...

Vaše odpověď

Mohlo by se hodit


Prosím používejte diakritiku a interpunkci.

Ochrana proti spamu. Napište prosím číslo dvě-sta čtyřicet-sedm: