Data tipinin seçilməsi – bu, iş üçün alət seçmək kimidir. Məsələn, mismarı vurmaq üçün tornavida istifadə etməzsən (ümid edirəm). Eləcə də database-də: düzgün data tipi performansa, yaddaşa qənaətə və məlumatların idarə olunmasına ciddi təsir edir. Məsələn, əgər pulu REAL formatında saxlasan, dəqiqlik problemləri ola bilər, qısa sətirlər üçün VARCHAR əvəzinə TEXT istifadə etsən, database daha çox yaddaş tutacaq.
Data tipi seçəndə bir neçə faktoru nəzərə al:
Məlumatın xarakteri
Məlumat hansı kateqoriyaya aiddir: rəqəmlər, sətirlər, məntiqi dəyərlər, tarixlər, yoxsa daha mürəkkəb bir şey, məsələn, JSON strukturları?
Məlumatın həcmi
Nə qədər məlumat saxlamağı planlaşdırırsan? Məsələn, 50 simvola qədər mətn üçün TEXT əvəzinə VARCHAR(50) seçmək daha yaxşıdır.
Dəqiqlik və diapazon
Yüksək dəqiqlik lazımdırmı (məsələn, maliyyə hesablamaları üçün)? Dəyərlərin diapazonunu məhdudlaşdırmaq istəyirsən?
Sorğuların tezliyi və xarakteri
Məlumatlara nə qədər tez-tez müraciət edəcəksən? Unutma ki, JSONB kimi mürəkkəb tiplər daha çox resurs tələb edir.
Data tiplərinin seçilməsi nümunələri
Fərqli məlumat – fərqli tapşırıq. Bəzən qəpik-qəpik dəqiqlik lazımdır, bəzən isə əsas odur ki, hər şey yerləşsin. Aşağıda konkret situasiyalara uyğun data tipini necə seçmək olar, nümunələr var.
Maliyyə məlumatları
Pul saxlamaq məsələsinə gələndə, mühasibatlıqda olduğu kimi, səhvlərə yol vermək olmaz. Ona görə ən yaxşı seçim NUMERIC tipidir, çünki yüksək dəqiqlik verir. Məsələn, belə sütunları olan cədvəl istəyirik:
| Sütunun adı | Data tipi | Şərh |
|---|---|---|
| id | SERIAL | Əsas açar |
| amount | NUMERIC(10, 2) | On rəqəm, ikisi vergüldən sonra |
| currency_code | CHAR(3) | Valyutanın ISO kodu, məsələn "USD", "EUR" |
| transaction_date | TIMESTAMP | Əməliyyat vaxtı, default olaraq cari vaxt |
Niyə REAL yox? Çünki vergüllü ədədlər dəqiqliyi itirə bilər, bu isə maliyyə üçün kritikdir.
Mətn məlumatları
İstifadəçi adları, ünvanlar və ya başqa sətirlər saxlayanda, mümkün olduqca maksimum uzunluğu təyin et. Məsələn, TEXT əvəzinə VARCHAR(50). Bu, səhvlərin qarşısını alır və yaddaşı optimallaşdırır.
| Sütunun adı | Data tipi | Şərh |
|---|---|---|
| id | SERIAL | Əsas açar |
| username | VARCHAR(50) | İstifadəçi login-i, unikal və mütləqdir |
| VARCHAR(255) | E-poçt ünvanı | |
| bio | TEXT | Bioqrafiya, yəni uzun mətn |
Əgər sətirin uzunluğu tam sabitdirsə (məsələn, iki simvolluq ölkə kodları), CHAR istifadə et:
| Sütunun adı | Data tipi | Şərh |
|---|---|---|
| code | CHAR(2) | Ölkənin ISO kodu (məsələn, "US"), əsas açar |
| name | VARCHAR(100) | Ölkənin adı, doldurulması mütləqdir |
Zaman məlumatları
Hadisələrin vaxtını və ya cədvəlləri saxlamaq üçün ən çox TIMESTAMP istifadə olunur, çünki həm tarix, həm də vaxtı saxlayır.
| Sütunun adı | Data tipi | Şərh |
|---|---|---|
| id | SERIAL | Əsas açar |
| event_name | VARCHAR(100) | Hadisənin adı |
| start_time | TIMESTAMP | Hadisənin başlama vaxtı, mütləqdir |
| end_time | TIMESTAMP | Hadisənin bitmə vaxtı, mütləqdir |
Əgər yalnız vaxt lazımdırsa, TIME, yalnız tarix lazımdırsa — DATE istifadə et.
Unikal identifikatorlar
Qlobal səviyyədə unikal identifikatorlar yaratmaq lazımdırsa, UUID istifadə et. Məsələn, tranzaksiya üçün unikal identifikator yaratmaq üçün:
| Sütunun adı | Data tipi | Şərh |
|---|---|---|
| request_id | UUID | Sorğunun unikal identifikatoru, default olaraq gen_random_uuid() ilə yaradılır |
| endpoint | VARCHAR(255) | Çağırılan API endpoint ünvanı |
| timestamp | TIMESTAMP | Sorğunun vaxtı, default olaraq cari vaxt |
JSONB: mürəkkəb strukturlar
Strukturu dəyişə bilən və ya mürəkkəb olan məlumatları saxlamaq lazımdırsa, məsələn, istifadəçi ayarları və ya metadata, JSONB istifadə et.
| Sütunun adı | Data tipi | Şərh |
|---|---|---|
| user_id | SERIAL | Əsas açar (istifadəçi ID-si) |
| preferences | JSONB | İstifadəçi ayarları JSON formatında |
JSONB ilə işləmək rahatdır, amma nəzərə al ki, çoxlu insert/update olanda performans aşağı düşə bilər.
Massivlər
Əgər eyni tipli məlumatların siyahısını saxlamaq lazımdırsa, massivlər uyğundur. Məsələn, tag-ların siyahısı:
| Sütunun adı | Data tipi | Şərh |
|---|---|---|
| id | SERIAL | Əsas açar |
| title | VARCHAR(255) | Məqalənin başlığı |
| tags | TEXT[] | Tag-lar massivi |
Tapşırıqlara görə data tiplərinə baxış
| Tapşırıq tipi | Tövsiyə olunan data tipi | Nümunə |
|---|---|---|
| Qeyd identifikatoru | SERIAL, BIGSERIAL, UUID |
id SERIAL PRIMARY KEY |
| Miqdar, tam ədədlər | INTEGER, BIGINT |
quantity INTEGER |
| Maliyyə hesablamaları | NUMERIC |
price NUMERIC(10, 2) |
| Sətirlərin saxlanması | VARCHAR(n), TEXT |
username VARCHAR(50) |
| Qısa sabit sətirlər | CHAR(n) |
status CHAR(1) |
| Tarix və vaxt | DATE, TIME, TIMESTAMP |
created_at TIMESTAMP DEFAULT NOW() |
| Unikal identifikatorlar | UUID |
id UUID PRIMARY KEY DEFAULT gen_random_uuid() |
| Mürəkkəb strukturlar (JSON) | JSONB |
metadata JSONB |
| Dəyərlər siyahısı | ARRAY |
tags TEXT[] |
| Məntiqi dəyər | BOOLEAN |
is_active BOOLEAN |
Yəqin ki, SERIAL istisna olmaqla, bütün tiplərlə artıq tanışsan. Məsələ burasındadır ki, SERIAL əslində INTEGER-dir, sadəcə olaraq cədvəldə sətirlərin identifikatoru kimi istifadə olunur.
O, cədvələ yeni sətir əlavə olunanda avtomatik olaraq 1 artır. Yəni, cədvələ 10 sətir əlavə etsən, birinci sətirin id-si 1, ikinci 2 və s. olacaq. Bütün bunlar barədə növbəti leksiyada daha ətraflı öyrənəcəksən :)
GO TO FULL VERSION