Rozdíl mezi typem VARCHAR a TEXT

tester:
„Napadlo mě proč se dává do tabulky uživatelů heslo typu varchar(32). Proč ne text? Ušetřilo by se místo.“
Čím přesně by se ušetřilo místo? V manuálu k mySQL se píše, že pro uložení:
- varcharu do délky 255 znaků potřebuješ L + 1 bajtů (L = délka skutečně uloženého řetězce), při delším řetězci L + 2 bajtů
- sloupce typu TEXT potřebuješ L + 2 bajtů
(takže pro VARCHAR(32) ušetříš oproti TEXTu jeden bajt)

„Podotázka týkající se BLOBu. Zajímalo by mě jestli je možné vytvořit číselný typ o velikosti 1 byte.“
Odpovědí je datový typ TINYINT

tester:
„Aha, já se domníval že délka varcharu(32) je 32 bytů.“
To má char(32). To var ve varcharu bude nejspíše od variable => řetězes s proměnlivou délkou.

„chci adresy zkracovat“
Velmi pravděpodobně naprosto zbytečná věc. Co ušetříš na datech, to ti zase přidá kód na zkracování a zpětnou rekonstrukci. Určitě nebudeš pracovat s objemy kde by každý bajt hrál význam.

tester:
Hned na začátek: Připadá mi, že řešíte neexistující problém.
Resp. se tomu říká „předčasná optimalizace“.
Různé obskurní úpravy a hacky bych dělal až ve chvíli, kdy reálně narazím na konkrétní problém, nejde ho řešit nějak „čistě“ a hlavně mám ověřené, že ten hack to vyřeší.

Protože je celkem běžné, že podobné „zlepšováky“ mají nejen hromadu nevýhod, ale ještě navíc jsou oproti standardnímu řešení horší i v tom, co měly údajně zlepšit.
(Údajný „hack na zrychlení“ je pomalejší, než standardní řešení, „hack na úsporu místa“ zabere víc místa, atd. A vůbec nejlepší je, když se nějaký amatér začne vytvářet „víc náhodný generátor náhodných čísel“, „bezpečnější kryptografické funkce“, apod.)

„Napadlo mě proč se dává do tabulky uživatelů heslo typu varchar(32). Proč ne text? Ušetřilo by se místo.“
Neušetřilo, viz výše.
Ale ještě doplním, že já to vidím přesně obráceně. Pokud to je pole pro heslo uživatele, určitě tam nebude heslo, ale hash, nejspíš s pevnou délkou, tj. těch 32 znaků.

A naopak by se místo ušetřilo použitím CHAR(32). S typem TEXT heslo zabere 34 bajtů, s VARCHAR 33 bajtů, s CHAR(32) 32 bajtů.

„S tím právě souvisí má myšlenka zda by se BLOB(1) (1 byte) dal použít na SQLite k tomu abych neplýtval místem když potřebuju zapsat hodnotu v rozsahu 0-255.“
BLOB(1) zabere 3 bajty, takže místo opravdu neušetří.

Ještě k původnímu dotazu:
„Rozdíl mezi typem VARCHAR a TEXT“
Co já vím, rozdíl je v tom, že VARCHAR se ukládá přímo jako součást záznamu, zatímco TEXT se ukládá mimo a v záznamu je jen nějaký ukazatel.
Takže na jedné straně není typ TEXT oproti VARCHAR omezený maximální velikostí jednoho záznamu, ale zase zabírá o 1B víc místa a práce s ním je pomalejší.

„Navíc chci adresy zkracovat tím způsobem že pokud tam je nějaká ze častých domén jako seznam.cz, email.cz, gmail.com apod, tak bych tam místo zavináče dal znak identifikující doménu tím pádem to bude ještě kratší.“
Vyrobí to spoustu problémů a reálný přínos bude minimální.
To už by bylo lepší vyrobit zvláštní tabulku pro domény a adresu skladovat jako uživatelské jméno a identifikátor domény (a adresa by se skládala z uživatelského jména, @ a domény získané přes JOIN z té tabulky).
Ale moc smyslu v tom nevidím, kromě toho, že by se snadno dělaly dotazy typu nejpoužívanější domény v e-mailech uživatelů.

Hlavní rozdíl mezi VARCHAR a TEXT je ten, že obsah TEXTu se ukládá bokem mimo tabulku a do dat tabulky se zapíše jen odkaz. To nepatrně zpomalí prohledávání tabulky (SELECT apod.), protože se musí načítat ještě z toho vedlejšího úložiště.

To zpomalení je ale tak nepatrné, že já osobně toto neřeším a všude nastrkám TEXTy, abych nemusel řešit maximální délku. Také se nemá cenu honit za každým bajtem, databáze jsou relativně datově úsporné a sotva se s běžnými stránkami dostaneš na několik MB.

tester:
„…to bys musel celou tabulku vygenerovat znova a přejmenovat.“
Až budeš navrhovat vlastní DBMS, tak dej vědět. Abychom se mu vyhnuli.

Datová struktura se negeneruje znova při každém zápisu. VARCHAR, který překročí vymezený diskový prostor, se zkrátí a doplní ukazatelem na zbylý fragment. Taky smazané řádky se nemažou, ale znovu používají. V závislosti na míře fragmentace pak DBMS tabulky jednou za čas defragmentuje. Nebo to jde udělat i ručně dotazem OPTIMIZE TABLE.

tester:
„Ale tím by vznikala právě ta fragmentace a zní mi to dost složitě.“
Ale tak to taky je. Tedy alespoň přibližně. Ona si to každá databáze řeší trochu jinak. Navíc databáze se potýkají se složitějšími výzvami. A proto je taky nevytvoří jeden tester za víkend ale pracují na nich týmy odborníků i celá desetiletí.

Myslím, že typ TEXT má délku stejnou jako maximální hodnota, VARCHAR je dlouhý jen jako je dlouhý text v něm.

tester:
„Druhá situace - ta mi právě není stále jasná jak ji vyřešit.“
Nechme stranou TEXT a BLOB, ten v hlavní tabulce vůbec data nemá (jen ukazatele). Co se MyISAM tabulek týče, VARCHAR nemá žádné nadbytečné místo (jen to co mohlo zůstat po jeho zkracujícím update). U prodlužujícího updatu se vytváří fragmenty. I samotný fragment pak může končit ukazatelem na další fragment. Je to stejně jako u filesystemu na disku.

Jiné databáze to pak můžou řešit jinak. Například InnoDB tabulky stránkuje, takže i záznamy s dynamickou délkou, jako je VARCHAR, mají nějaký prostor vyhrazený navíc.

Největší rozdíl VARCHAR vs TEXT v nových verzích MySQL je asi využití indexů a rychlejší dotazy u VARCHARu.

Zkus si nějaké složitější OUTER JOINy přes víc než 2 tabulky, přidej třídění či poddotazy a pak ty rozdíly v rychlosti poznáš.

Jinak vlastní uložení hodnot v řádku se dá nastavit různě. Záleží na formátu řádku i použitém enginu.