Typy dat v MySQL vysvětleny: Vyberte správné typy sloupců pro výkon a škálovatelnost

1. Introduction: Why You Should Understand the MySQL Data Type List

Když navrhujete tabulky nebo integrujete aplikace s MySQL, jednou z nejčastějších otázek je: „Jaký datový typ mám použít pro tento sloupec?“
Má to být INT? Opravdu potřebujete BIGINT? Stačí VARCHAR pro řetězce, nebo je lepší TEXT? Tyto volby se mohou zdát drobné, ale tvoří základ, který později ovlivní váš systém.

Pokud podceníte, jak si vybrat datové typy, často narazíte na problémy jako jsou následující:

• Jak data rostou nad očekávání, plýtváte úložným prostorem
• Indexy se nafouknou a výkon dotazů postupně klesá
• Hodnoty mimo rozsah nebo přetečení způsobí neočekávané chyby či výjimky
• Jste nuceni později měnit typy sloupců, což spouští rozsáhlou migraci

Jednoduše řečeno, systematické pochopení datových typů MySQL a výběr toho správného pro každý případ použití je nejrychlejší cesta, jak zlepšit jak výkon, tak udržovatelnost.

Tato stránka je primárně určena čtenářům, jako jsou:

• Inženýři, kteří se chystají zahájit seriózní vývoj systémů s MySQL
• Backendoví / infrastrukturní inženýři, kteří chtějí zrevidovat existující návrhy tabulek
• Weboví vývojáři a programátoři, kteří hledají „doporučené typy“ podle konkrétního použití

Začneme uspořádáním hlavních datových typů MySQL jako kategorizovaného „seznamu“. Poté vysvětlíme klíčové typy — číslicové, řetězcové, datum/čas, JSON, ENUM/SET — a popíšeme jejich charakteristiky, typické případy použití a tipy pro výběr. Nakonec shrneme časté chyby v návrhu a jak se jim vyhnout, spolu s FAQ.

Nejedná se jen o „seznam pojmů“. Je strukturován jako průvodce rozhodováním, aby vás při navrhování tabulek v reálných projektech nic nezastavilo. V další sekci se ponoříme do toho, jak přemýšlet o datových typech a projdeme kategorizovaný seznam.

2. What Is a Data Type, and Why Does “Choosing the Right Type” Matter?

V databázi je „datový typ“ pravidlo, které definuje, jaké hodnoty může sloupec ukládat.
MySQL poskytuje mnoho datových typů — celá čísla, desetinná čísla, řetězce, data, binární data, JSON a další — takže je třeba zvolit ten správný podle účelu.

The Role of Data Types

Datový typ není jen „kategorie formátu“. Plní několik rolí najednou:

• Omezují druh dat (číselná vs. řetězcová, boolean atd.)
• Definují povolený rozsah a počet číslic
• Určují potřebnou paměť (velikost úložiště)
• Ovlivňují struktury indexů a výkon vyhledávání
• Mají vliv na implicitní konverze a pravidla porovnávání (např. kolace řetězců)

Stručně řečeno, datové typy nejsou jen „kontejnery“ — jsou základní návrhová rozhodnutí, která ovlivňují celý životní cyklus správy dat.

What Happens If You Choose the Wrong Type?

Když zvolíte špatný datový typ, v praxi se často objeví problémy jako tyto:

• Wasting Storage

Například pokud je BIGINT (8 bytů) dostatečný, ale omylem použijete DECIMAL nebo LONGTEXT, můžete spotřebovat mnohem více místa na disku, než je potřeba.

• Slower Queries

Pokud nadměrně používáte LIKE na obrovských TEXT sloupcích, nebo pokud indexy nafouknou kvůli příliš velkým číselným typům, výkon SQL dotazů se zpomalí.

• Inconsistent Values or Overflow

Můžete uložit hodnoty, které se nevejdou do INT, což způsobí neočekávané záporné hodnoty, zaokrouhlování nebo jiné problémy.

• High‑Cost Table Changes

Zvláště u velkých tabulek může změna typů pomocí ALTER TABLE vést k:

• Dlouhým časům uzamčení
• Dopadu na služby
• Práci na migraci dat a dalším rizikům

Key Categories You Should Understand Up Front

Datové typy MySQL jsou obecně rozděleny do následujících kategorií:

• Číselné typy (celá čísla, desetinná čísla)
• Řetězcové typy
• Typy datum a čas
• Binární typy
• Typ JSON
• Typy ENUM / SET
• Prostorové datové typy

Each category has different trade-offs—strengths/weaknesses, “light vs. heavy,” and “easy vs. hard to search.” That’s why you need the optimal type selection for each use case.

3. Kategorie datových typů MySQL (Přehledný seznam)

In this section, we’ll summarize the data types available in MySQL as a categorized overview list. In practice, the first things you want to confirm are “What types exist?” and “Which one should I use?”
So here we’ll clearly show use cases, key characteristics, and representative type names, and then explain each category in more detail in the following sections.

3.1 Číselné typy

Číselné typy jsou základem pro veškeré číselné zpracování, včetně celých čísel, desetinných a floating‑point hodnot.
Tato kategorie se používá nejčastěji pro ID, množství, ceny, kontrolu příznaků a mnoho dalších účelů.

Celé čísla

Poznámky

• Přidání UNSIGNED zdvojnásobí kladný rozsah.
• INT se používá v mnoha případech, ale neuvážené použití BIGINT může učinit indexy těžší.

Desetinné / Floating‑Point typy

Poznámky

• Pro peníze je DECIMAL jedinou rozumnou volbou. Floating‑point typy (FLOAT / DOUBLE) mohou zavádět chyby.
• V případech zahrnujících mnoho výpočtů se někdy volí DOUBLE kvůli kompromisu rychlost/přesnost.

Další číselné typy

3.2 Datové a časové typy

Zpracování data/času se používá velmi často při vývoji aplikací.
V závislosti na účelu se liší faktory jako „chování časové zóny“, „automatické aktualizace“ a „přesnost na úrovni sekundy“, takže výběr správného typu má význam.

Poznámky

• Pokud chcete automaticky spravovat „updated at“, je TIMESTAMP pohodlný.
• Pro „logy“ nebo „historii“, kde chcete ukládat přesné časové značky, se běžně používá DATETIME.

3.3 Řetězcové / Binární typy

Uživatelská jména, e‑mailové adresy, hesla, popisy—řetězce jsou často nejkomplexnější oblastí v návrhu tabulek.

Řetězce pevné délky

Řetězce proměnné délky

Velký text (rodina TEXT)

Poznámky

• Použijte TEXT, když potřebujete uložit velmi dlouhé řetězce, jako jsou těla článků nebo dlouhé popisy.
• Buďte opatrní při vyhledávání a návrhu indexů.

Binární data (BINARY / BLOB)

※ Obecně se velké soubory neukládají do databáze; běžný návrh je uložit je do externího úložiště.

ENUM / SET typy (Výčty)

Poznámky

• Pokud potřebujete později měnit definici typu, údržba se stane těžkou.
• Může být efektivní pro malé, statické kandidáty.

3.4 JSON typ

• Získáte flexibilitu podobnou NoSQL, přičemž můžete stále používat funkce specifické pro JSON.
• Nicméně nedoporučuje se balit často vyhledávaná data do JSON. Pokud lze data normalizovat, měla by být modelována jako strukturované tabulky.

3.5 Prostorové typy

Tyto typy se používají při práci s geografickými a lokalizačními daty.

V typických webových aplikacích se nepoužívají často, ale jsou důležité pro mapové aplikace a integrace GPS.

4. Jak vybrat a používat každý datový typ (Klíčové rozhodovací body)

V této sekci se hlouběji ponoříme do kategorií představených výše, zaměřených na „jak vybírat v reálných scénářích“.
Pouze znát názvy není dostačující—výběr nejvhodnějšího datového typu má zásadní dopad na udržovatelnost, výkon a budoucí škálovatelnost.

4.1 Jak vybrat číselné typy

Kritéria pro výběr celých typů

Při výběru celých typů se zaměřte na tyto tři body:

1. Pochopte maximální požadovaný rozsah

• Malé čítače → TINYINT
• Množství produktů / příznaky → SMALLINT / INT
• Velké ID nebo logy → BIGINT

Některé projekty nadměrně používají BIGINT pro primární klíče, což může snadno vést k větším velikostem indexů a negativně ovlivnit výkon.

2. Aktivně zvažujte UNSIGNED

If you only handle positive values (e.g., numeric IDs, inventory counts)
→ using UNSIGNED doubles the range and may allow you to use a smaller type.

3. Pro peníze nebo hodnoty vyžadující přesnost, použijte DECIMAL

For values where “errors are not acceptable,” avoid FLOAT/DOUBLE and always use DECIMAL.

4.2 Jak vybrat typy data a času

The appropriate type depends on your use case.

Differences Between DATETIME and TIMESTAMP

General Rules for Choosing

• Aplikační logy nebo záznamy událostí → DATETIME (vyhněte se efektům převodu časových pásem)
• Když chcete automaticky zaznamenávat aktualizované časové razítka → TIMESTAMP (pohodlné chování automatické aktualizace)

Where YEAR Is Useful

• Fiscal‑year categories, release years, founding years, etc. → Manage compactly (1 byte)

4.3 Jak vybrat řetězcové typy

How to Decide Between CHAR and VARCHAR

Kdy byste měli použít CHAR

• Length is always constant: prefecture codes, country codes, fixed‑length identifiers, etc.
• Data that needs fast access and is updated infrequently

Kdy byste měli použít VARCHAR

• Length varies: names, email addresses, titles, etc.
• The best default choice in most situations

Should You Use TEXT?

Advantages of TEXT

• Supports large text (descriptions, article bodies, etc.)

Cautions for TEXT

• Indexing is limited (prefix indexes are required)
• Performance can degrade when used in JOINs or WHERE clauses
• Search and sorting can be heavy

Recommendation:
Use TEXT for “large strings” such as bodies or notes,
and use VARCHAR as much as possible for everything else.

4.4 Jak vybrat typ JSON

The JSON type is very useful, but you need to use it “correctly.”

When JSON Works Well

• Flexible settings or data with a variable number of fields
• Limited lookup use cases, or when the application expands/parses it
• Storing lightweight data that doesn’t require a master table

When JSON Is a Bad Fit

• Data you search frequently
• Data used for filtered searches, aggregation, or JOINs
• Structured data that should be normalized

Rule of thumb:
Data you need to search should be normalized and treated as structure.
Don’t forget that JSON is “flexible but weak for search.”

4.5 Jak vybrat typy ENUM / SET

When ENUM Is Appropriate

• States are fixed: e.g., status ( draft / published / archived )
• A small set of options that rarely changes

Cautions for ENUM

• Adding or changing values requires ALTER TABLE
• Risk of losing consistency with application‑side definitions

When SET Is Appropriate

• Small‑scale data that requires multiple selection (e.g., available weekdays, or when there are only a few tag options)

Cautions for SET

• Combinations of values can become complex
• Managing multi‑value states can become difficult

4.6 Jak vybrat typy Binary / BLOB

BINARY / VARBINARY

• Tokens, IDs, hash values, etc.
• Fixed‑length binary (e.g., 16‑byte UUIDs)

Typical Use Cases for BLOB Types

• Small files, thumbnail images, encrypted data

But Note

• Storing large files in the database makes backups heavier
• Read/write load also increases → In real systems, external storage + path management is recommended

5. Praxe: How to Use the “Data Type Reference List” When Designing Tables

In this section, we’ll explain how to use the MySQL data type list in a practical workflow when designing tables.
Rather than just memorizing types, organizing “why you choose that type” through logic and steps leads to higher‑quality database design.

5.1 Krok 1: Clarify the Column’s “Purpose” and “Nature”

First, clearly define what will be stored in the column.

Checklist

• Je to číselný typ, řetězec, datum nebo příznak?
• Je proměnlivé délky nebo pevné délky?
• Jaká je maximální hodnota nebo maximální délka?
• Má být povoleno NULL?
• Je pravděpodobné, že v budoucnu poroste?

Pokud zde budete vycházet z nejasných předpokladů, výběr typu se později zbytečně zkomplikuje.

5.2 Krok 2: Odhad požadovaného rozsahu a formátu

Dále odhadněte horní/dolní mez, délku znaků a požadovanou přesnost hodnot, které budete ukládat.

Příklad: Sloupec ID

• Dosáhne maximální počet záznamů desítek milionů? Stovek milionů? → To vám pomůže určit, zda je INT dostačující, nebo je nutný BIGINT.

Příklad: Název produktu

• Průměrně 15–25 znaků, maximálně kolem 50? → VARCHAR(50) je dostačující. TEXT není potřeba.

Příklad: Cena

• Je vyžadována přesnost? → Měli byste zvolit něco jako DECIMAL(10,2).

5.3 Krok 3: Zvažte objem dat a výkon

Volba datových typů MySQL přímo ovlivňuje výkon.

Klíčová úvaha

• Typy, které jsou příliš velké → spotřebují úložiště a ztíží indexy
• TEXT / BLOB → snižují výkon vyhledávání
• JSON → flexibilní, ale slabý pro vyhledávání
• TIMESTAMP → efektivní pro automatické aktualizace a porovnání

Obzvláště sloupce s indexy by měly používat co nejlehčí možný datový typ.

5.4 Krok 4: Ověřte typy pomocí vzorových dat

Po navržení tabulky vložit desítky až stovky řádků testovacích dat a ověřit chování.

Co zkontrolovat

• Existují neúmyslné problémy s zaokrouhlováním nebo ořezáváním?
• Je VARCHAR dostačující, nebo by měl být TEXT?
• Funguje řazení a vyhledávání datetime podle očekávání?
• Výkon čtení/zápisu JSON

Testování s realistickými daty snižuje „teoretické omyly“.

5.5 Krok 5: Zvažte škálovatelnost a udržovatelnost

V závěrečné fázi návrhu tabulky zkontrolujte, zda budou budoucí změny snadné.

Příklady náročných změn typů

• ENUM (vyžaduje ALTER TABLE při přidávání hodnot)
• TEXT → VARCHAR (rozšíření je snadné, zmenšení je riskantní)
• FLOAT → DECIMAL (může změnit sémantiku)

Zvolte typy podle toho, zda je pravděpodobná budoucí expanze.

5.6 Krok 6: Příklad CREATE TABLE (praktický vzor)

Níže je ukázková tabulka odrážející běžné standardy výběru datových typů v typické webové aplikaci.

CREATE TABLE products (
    id           BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
    name         VARCHAR(100) NOT NULL,
    price        DECIMAL(10,2) NOT NULL,
    stock        INT UNSIGNED NOT NULL DEFAULT 0,
    status       ENUM('draft', 'published', 'archived') NOT NULL DEFAULT 'draft',
    description  TEXT,
    created_at   DATETIME NOT NULL,
    updated_at   TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
);

Klíčové body v tomto příkladu

• id : Používá BIGINT UNSIGNED s ohledem na budoucí škálování
• name : Středně dlouhý proměnný řetězec → VARCHAR
• price : Peněžní hodnota → přesný DECIMAL
• stock : Počet zásob → INT UNSIGNED
• status : Pevná množina hodnot → ENUM
• description : Potenciálně dlouhý text → TEXT
• updated_at : Pohodlný automaticky aktualizovaný TIMESTAMP

Jak je vidět, každá volba typu by měla mít jasnou motivaci a schopnost tuto motivaci vysvětlit je znakem dobrého návrhu.

6. Běžné chyby a jak se jim vyhnout

Protože MySQL nabízí mnoho datových typů, v reálných projektech se často objevují několik běžných chyb.
Tato sekce zdůrazňuje typické úskalí a poskytuje praktická opatření.

6.1 Používání příliš velkých datových typů

Běžné příklady

• Používání BIGINT pro všechna ID
• Nastavení každého řetězce na VARCHAR(255)
• Používání TEXT pro netextový obsah

Problémy

• Zbytečná úložná kapacita
• Nafouknuté indexy poškozující výkon dotazů
• Zbytečná šířka pásma sítě (větší přenosy dat)

Jak se vyhnout

• Odhadněte maximální a minimální hodnoty předem
• Nastavte délky VARCHAR na základě důkazů
• Používejte TEXT jen když je to skutečně nutné

6.2 Používání FLOAT/DOUBLE pro desetinné hodnoty (Problémy s přesností)

Běžné příklady

• Ukládání cen jako FLOAT
• Číselné porovnání selhává kvůli chybám zaokrouhlování

Jak se vyhnout

• Používejte DECIMAL pro peníze a hodnoty kritické na přesnost
• Vyhněte se FLOAT / DOUBLE, kromě vědeckých nebo dočasných výpočtů

6.3 Příliš velké sloupce VARCHAR

Běžné příklady

• Používání VARCHAR(255) jako výchozí
• Nastavování velkých délek pro sloupce, které ukládají jen cca 30 znaků

Problémy

• Zbytečná paměť a úložiště
• Indexy se často stávají těžšími

Jak se vyhnout

• Odhadněte průměrné a maximální délky z reálných dat
• Vyhněte se zbytečně velkým velikostem (např. e‑mailové adresy → VARCHAR(100) )

6.4 Nadměrné používání typů TEXT

Běžné příklady

• Předpokládání, že “string = TEXT”
• Používání TEXT pro data, která potřebují filtrování nebo vyhledávání

Problémy

• Mnoho omezení indexování
• Náročné vyhledávání pomocí LIKE
• Pomalejší zpracování v JOINech

Jak se vyhnout

• Používejte TEXT jen pro dlouhý obsah, jako jsou popisy nebo těla textu
• Ukládejte vyhledávatelné řetězce do VARCHAR, kdykoli je to možné

6.5 Výběr typů Date/Time bez pochopení jejich vlastností

Běžné příklady

• Používání DATETIME pro vše
• Používání DATETIME pro “updated at”, takže se neaktualizuje automaticky
• Časová razítka se posouvají kvůli rozdílům časových pásem

Jak se vyhnout

• Potřeba auto‑aktualizace: TIMESTAMP
• Chcete se vyhnout posunům časových pásem: DATETIME
• Potřebujete jen rok: YEAR

6.6 Příliš neformální používání ENUM / SET

Běžné příklady

• Používání ENUM, i když se možnosti mohou v budoucnu měnit
• Používání SET jako čárkou oddělený seznam

Problémy

• Změny vyžadují ALTER TABLE
• Nesoulad s definicemi na straně aplikace je pravděpodobnější

Jak se vyhnout

• Pokud se hodnoty mohou zvyšovat, spravujte je v samostatné hlavní tabulce
• Používejte ENUM jen když je množina malá a skutečně pevná

6.7 Vkládání příliš mnoha věcí do JSON „protože je to pohodlné“

Běžné příklady

• Vkládání struktur, které by měly být normalizovány, do JSON
• Ukládání často vyhledávaných dat uvnitř JSON

Problémy

• Výkon vyhledávání se zhoršuje
• Indexy jsou méně efektivní / těžší k použití
• Více práce s parsováním na straně aplikace
• Návrh bez schématu usnadňuje porušení konzistence

Jak se vyhnout

• Používejte JSON jen pro data, která nevyhledáváte
• Omezte jej na „malá, proměnná data“ jako nastavení
• Normalizujte informace používané pro JOINy a vyhledávání

6.8 Podcenění nákladů na změny typů

Problémy

• ALTER TABLE může být na velkých tabulkách extrémně náročný
• Může dojít k výpadku služby nebo dlouhým časům zamčení
• V některých případech je vyžadována migrace dat

Jak se vyhnout

• Plánujte budoucí růst během fáze návrhu
• Používejte ENUM opatrně
• Nechte rezervu v přesnosti/škále DECIMAL (ale nepřehánějte to)

7. Shrnutí

MySQL poskytuje širokou škálu datových typů a typ, který zvolíte, může významně ovlivnit výkon, škálovatelnost a udržovatelnost.
Obzvláště v prostředích jako webové aplikace, kde data mají tendenci růst, mají rozhodnutí v raném návrhu přímý dopad na dlouhodobou kvalitu.

Hlavní poznatky v tomto článku

• Datové typy jsou kritické faktory, které ovlivňují „druh hodnoty, rozsah, přesnost, úložiště a výkon.“
• Číselné, řetězcové, datum/čas, JSON, ENUM/SET a BLOB typy mají své silné i slabé stránky.
• Celá čísla, řetězce a typy datum/čas se používají nejčastěji, takže jejich správná volba má význam.
• JSON a ENUM jsou pohodlné, ale nesprávné použití může ztížit údržbu.
• Nadměrné používání TEXT a BLOB může degradovat výkon.
• Racionální přístup k návrhu je: „Účel → Rozsah → Výkon → Škálovatelnost.“

Kontrolní seznam návrhu, který můžete použít již dnes

• Je účel sloupce jasně definován?
• Rozumíte maximálním a minimálním možným hodnotám?
• Existují důkazy pro zvolenou délku VARCHAR?
• Používáte DECIMAL pro peníze?
• Jsou časové značky „updated at“ spravovány pomocí TIMESTAMP a automatické aktualizace tam, kde je to vhodné?
• Než použijete ENUM, zvážili jste, že se hodnoty v budoucnu mohou zvýšit?
• Vyhýbáte se návrhům, kde vyhledávání zpomaluje kvůli nadměrnému používání JSON?
• Navrhli jste tak, aby se předešlo těžkým operacím ALTER TABLE na velkých datových sadách?

Finally

Neexistuje vždy jediná „správná odpověď“ při výběru datových typů v MySQL.
Nicméně pokud volíte s úmyslem a ohledem na budoucí růst, můžete předejít vážným problémům a udržet strukturu dat čistou.

Nakonec nejlepší volba závisí na povaze vašeho projektu, objemu dat a požadavcích aplikace. Pokud však použijete kritéria představená v tomto článku jako základ, měli byste být schopni učinit lepší rozhodnutí o datových typech v jakékoli situaci.

Dále představíme sekci FAQ, která shrnuje otázky často kladené v praxi. Když si nejste jisti výběrem typu, kontrola této FAQ vám pomůže rozhodnout se plynuleji.

8. FAQ

Výběr datových typů v MySQL je oblast, kde se rozhodnutí mohou výrazně lišit v závislosti na reálných zkušenostech. Zde shromažďujeme běžné otázky od vývojových týmů a poskytujeme stručné, jasné odpovědi.

Q1. Mám použít INT nebo BIGINT?

Odpověď: Používejte INT jako výchozí. BIGINT použijte jen pokud by v budoucnu mohlo překročit 2,1 miliardy.

INT (4 bajty) podporuje až přibližně 2,1 miliardy a je dostačující pro většinu aplikací. BIGINT zvažte pro logy, služby s vysokým provozem nebo systémy, které mohou generovat extrémně velké množství ID.

Q2. Mám použít VARCHAR nebo TEXT?

Odpověď: Použijte VARCHAR, pokud potřebujete vyhledávání. Použijte TEXT pro dlouhý obsah.

• VARCHAR : Přátelský k indexům a vhodnější pro vyhledávání
• TEXT : Vhodný pro dlouhý obsah, ale neideální pro vyhledávání nebo JOINy

※ Nadměrné používání TEXT může vést k degradaci výkonu.

Q3. Je v pořádku ukládat peníze jako DOUBLE?

Odpověď: Ne. Vždy používejte DECIMAL.

DOUBLE a FLOAT mohou zavádět zaokrouhlovací chyby, takže nejsou vhodné pro peníze nebo hodnoty vyžadující vysokou přesnost. V obchodních systémech je běžný standard DECIMAL(10,2) nebo DECIMAL(12,2).

Q4. Nerozumím rozdílu mezi DATETIME a TIMESTAMP. Jak si vybrat?

Odpověď: Použijte TIMESTAMP, pokud potřebujete automatické aktualizace. Použijte DATETIME, pokud potřebujete uložit přesný časový údaj bez konverze časové zóny.

• TIMESTAMP : Automatická aktualizace a konverze časové zóny
• DATETIME : Není ovlivněn časovými zónami; ukládá datum/čas „tak, jak je“

DATETIME se často používá pro logy a historické tabulky.

Q5. Je bezpečné používat ENUM?

Odpověď: Je užitečný jen když jsou hodnoty „zaručeně neměnné“.

ENUM je nenáročný a pohodlný, ale přidání nebo změna hodnot vyžaduje ALTER TABLE. Pro pole, která mohou růst, se doporučuje správa v samostatné tabulce.

Q6. Mohu zatím jen použít JSON?

Odpověď: Používejte JSON jen pro data, která nevyhledáváte. Data, která vyhledáváte, by měla být normalizována.

JSON je flexibilní, ale má slabiny ve výkonu.

• Slabý pro vyhledávání
• Struktury indexů se stávají složitějšími
• Těžší udržovat konzistenci dat

Funguje dobře pro nastavení a volby – atributy, které nejsou použity jako podmínky vyhledávání.

Q7. Jak si mám určit maximální délku pro VARCHAR?

Odpověď: Odhadněte maximum na základě reálných dat a přidejte malý rezerva.

Příklad: E‑mailová adresa → VARCHAR(100) je dostačující
Příklad: Uživatelské jméno → VARCHAR(50) je často v pořádku

„255 jen tak“ se nedoporučuje.

Q8. Když jsem zvolil špatný typ, mohu jej později změnit?

Odpověď: Ano, ale může to být velmi náročné na velkých tabulkách.

ALTER TABLE často zahrnuje úplné skenování a přestavbu, což může způsobit výpadek nebo dlouhé zamykání.

→ Pečlivé plánování v počáteční fázi návrhu je nejdůležitější