Дешифрирање CHAR и VARCHAR во MySQL

[Soham1087]

Во моментов ги истражувам типовите на податоци на MySQL и барам појаснување за разликите помеѓу складирањето CHAR и VARCHAR. Овие два типа на податоци се основни за дизајнот на базата на податоци, но разбирањето на нивните нијанси и импликации понекогаш може да биде предизвик.

CHAR е тип на податоци со знаци со фиксна должина, што значи дека секогаш зафаќа иста количина на простор за складирање, без оглед на вистинската должина на податоците. Спротивно на тоа, VARCHAR е тип на податоци со знаци со променлива должина, што овозможува пофлексибилно складирање само со користење на потребниот простор за складирање на податоците.

Ајде да навлеземе подлабоко во овие концепти со фрагмент од код:

-- Code Snippet 3
CREATE TABLE data_types (
    id INT AUTO_INCREMENT PRIMARY KEY,
    category CHAR(10),
    description VARCHAR(100)
);

Во оваа изјава за креирање табела, дефинираме две колони: категорија како CHAR(10) и опис како VARCHAR(100). Еве неколку клучни размислувања и прашања што ги имам во врска со складирањето CHAR и VARCHAR:

1. Ефикасност на складирање и складирање со фиксна должина: Со CHAR, MySQL доделува фиксен простор за складирање за секоја вредност, дури и ако вистинската должина на податоците е пократка. Како MySQL се справува со складирањето со фиксна должина за колоните CHAR и кои се импликациите за ефикасноста на складирањето?

2. Складирање и ефикасност на складирање со променлива должина: VARCHAR, од друга страна, го користи само потребниот простор за складирање врз основа на вистинската должина на податоците. Како MySQL управува со складирањето со променлива должина за колоните VARCHAR и кои се предностите во однос на ефикасноста на складирањето?

3. Интегритет и перформанси на податоците: додека CHAR нуди складирање со фиксна должина, VARCHAR обезбедува поголема флексибилност и може да резултира со заштеда на простор за податоци со променлива должина. Сепак, дали има некои размислувања за интегритетот или перформансите на податоците при изборот помеѓу CHAR и VARCHAR? На пример, дали VARCHAR носи некакви трошоци за изведба поради складирање со променлива должина?

4. Индексирање и перформанси на пребарување: во MySQL, индексирањето е критично за оптимизирање на перформансите на барањето, како што е прикажано во тој напис. Како се споредуваат типовите на податоци CHAR и VARCHAR во однос на индексирањето и перформансите на пребарувањето? Дали има загриженост при индексирање на колони со типови на податоци CHAR или VARCHAR?

Овие прашања имаат за цел да ми помогнат подобро да го разберам складирањето на CHAR и VARCHAR во MySQL, како и последиците за архитектурата на базата на податоци и оптимизацијата на перформансите.

Вашите сознанија во врска со овие прашања неверојатно ќе ми помогнат да го сфатам складирањето на CHAR и VARCHAR на MySQL.

 

[zmej gorjanin]

Не е многу сложено, и си го објаснил на долго и широко.

Ако знаеш дека колоната во табелата ќе ти содржи податоци за секој ред со фиксна должина користи CHAR. Кандидати за CHAR се било какви скратеници кои имаат фиксна должина. Ко на пример скратеници за земји или валути или можеби пол или можеби јазик. Која е предноста на CHAR? Зафаќа помалку простор, податоците побргу се читаат и запишуваат и користи статичка алокација на меморија. Ако декларираш колона на пример вака:

name CHAR(5)

а пробаш да внесеш име ко "Александра", ќе ти го скрати името до 5 тиот карактер или "Алекс". Ако пробаш да внесеш "Перо" ќе додаде еден empty space за да дојде до бројка од 5 карактери или "Перо ". Кај VARCHAR не е така, ако декларираш колона да биде 150 карактери значи дека можеш да внесеш стринг со било која должина ама да биде до 150 карактери, што значи на стрингот нема да му бидат додаени empty spaces ако не одговара на бројката од 150 карактери. Исто така ако декларираш колона вака: name CHAR(100), во било кој случај меморијата што ќе ја зафати тој стринг ќе биде 100 бајти. Додека ако имаш случај name VARCHAR(100) и внесеш да речеме вредност "Bojan" меморијата нема да ти биде 100 бајти туку ќе ти биде 5 бајти.