Cədvəllərin yaradılması və dəyişdirilməsində tipik səhvlər

Salaam, gələcəyin PostgreSQL guru-ları! Bugünkü mövzu bəlkə də proqramlaşdırmada ən dəyərli skill-lərdən birinə həsr olunub — səhvlərdən yayınmaq. Hamısından qaçmaq mümkün deyil, xüsusən də SQL-ə yeni başlayırsansa. Amma tipik səhvləri tez başa düşmək tam realdır. Bu, sanki qaranlıq otaqda çoxlu künclər arasında gəzməyə bənzəyir: bir-iki dəfə dəyirsən, amma sonra bilirsən nə haradadır. Mən də sənə cədvəl yaradanda və dəyişəndə "iti künclərdən" yan keçməyə kömək edəcəm.

Səhv 1: Data type-ın səhv seçilməsi

Data type-larla işləmək — açarı qıfıla uyğunlaşdırmağa bənzəyir. Səhv "açar" kimi data type seçsən, cədvəlin ya düzgün işləməyəcək, ya da effektli olmayacaq.

Səhv nümunəsi:

Telefon nömrələrini saxlamaq üçün bir sütun yaratmaq istəyirsən və adət üzrə INTEGER seçirsən. Məntiqlidir, axı nömrələr rəqəmdir. Amma problem ondadır ki, INTEGER bu datalar üçün uyğun deyil, çünki:

• Sıfırla başlayır (0123456789 sadəcə 123456789 olacaq).
• "+" və ya boşluq kimi simvollar ola bilər.

-- Səhv:
CREATE TABLE customers (
    id SERIAL PRIMARY KEY,
    phone_number INTEGER -- Oy-oy
);

-- Düzgün:
CREATE TABLE customers (
    id SERIAL PRIMARY KEY,
    phone_number VARCHAR(15) -- Bütün nömrə formatlarını saxlamaq üçün uyğundur
);

Necə yayınmaq olar?
Saxlayacağın datanın təbiətini diqqətlə analiz elə, sonra data type seç. Əmin deyilsənsə, PostgreSQL-in rəsmi data type sənədinə bax.

Səhv 2: NOT NULL, CHECK, UNIQUE constraint-ləri unudulub

Constraint-lər datanın bütövlüyünü qorumağa kömək edir. Onları unutdunsa, cədvəldə xaos başlayacaq, məsələn, boş dəyərlər orada olacaq ki, olmamalıdır.

Səhv nümunəsi: Tələbələri saxlamaq üçün cədvəl yaradırsan və unudursan ki, ad və yaş mütləqdir.

-- Səhv:
CREATE TABLE students (
    id SERIAL PRIMARY KEY,
    name VARCHAR(100),
    age INTEGER
);

INSERT INTO students (name, age) VALUES (NULL, NULL); -- Oy, bu nədir?!

Düzgün variant:

CREATE TABLE students (
    id SERIAL PRIMARY KEY,
    name VARCHAR(100) NOT NULL, -- Ad mütləqdir
    age INTEGER CHECK (age > 0) -- Yaş müsbət olmalıdır
);

Necə yayınmaq olar?
Mütləq sahələr üçün həmişə constraint-lər təyin et. Bu, bir növ "müdafiə mexanizmi"dir, problemli datanın daxil olmasının qarşısını alır.

Səhv 3: Unikallıq problemləri

Bəzən unudursan ki, UNIQUE constraint əlavə edəsən, halbuki sütunda unikal dəyərlər olmalıdır. Bu isə təkrarlanan datalara gətirib çıxarır.

Səhv nümunəsi: Email-ləri saxlamaq üçün cədvəl yaradırsan, amma UNIQUE əlavə etməyi unudursan.

-- Səhv:
CREATE TABLE users (
    id SERIAL PRIMARY KEY,
    email VARCHAR(100)
);

INSERT INTO users (email) VALUES ('user@example.com');
INSERT INTO users (email) VALUES ('user@example.com'); -- Bu email artıq var!

Düzgün variant:

CREATE TABLE users (
    id SERIAL PRIMARY KEY,
    email VARCHAR(100) UNIQUE -- Unikal email-lər
);

Necə yayınmaq olar?
Əgər dəyərlər unikal olmalıdırsa, həmişə UNIQUE əlavə et. Daha çevik olmaq istəyirsənsə, constraint-ə ad verib istifadə edə bilərsən:

CREATE TABLE users (
    id SERIAL PRIMARY KEY,
    email VARCHAR(100),
    CONSTRAINT unique_email UNIQUE (email)
);

Səhv 4: Cədvəlləri dəyişəndə səhvlər (ALTER TABLE)

ALTER TABLE istifadə etmək bəzən tələyə çevrilir, xüsusən də cədvəldə artıq data varsa. Məsələn, sütunda icazə verilən dəyərləri unudursan və mövcud datalarla işləyəndə səhvlər çıxır.

Səhv nümunəsi: Mövcud sütuna NOT NULL constraint əlavə etmək istəyirsən, amma orada NULL dəyərlər var.

-- Səhv:
ALTER TABLE students ALTER COLUMN name SET NOT NULL; -- Səhv!

Əgər cədvəldə artıq NULL olan sətirlər varsa, PostgreSQL constraint əlavə etməyə imkan verməyəcək.

Necə olsun?

Constraint əlavə etməzdən əvvəl datanın tələblərə uyğun olduğuna əmin ol. Məsələn:

UPDATE students SET name = 'Naməlum' WHERE name IS NULL;
ALTER TABLE students ALTER COLUMN name SET NOT NULL;

Səhv 5: Cədvəlləri və ya datanı yoxlamadan silmək

DROP TABLE ilə cədvəli və ya DELETE ilə datanı silmək — bu addımı geri qaytarmaq olmur. Ona görə də silməzdən əvvəl həmişə nəyi sildiyinə bax.

Səhv nümunəsi:

DROP TABLE courses; -- Oy, bu başqa cədvəl idi!

Necə yayınmaq olar?

psql-da \dt komandasından istifadə et, hansı cədvəllərin olduğunu gör və əmin ol ki, düzgün cədvəli silirsən.

Və ya DROP TABLE IF EXISTS istifadə et ki, mövcud olmayan cədvəli siləndə səhv çıxmasın:

DROP TABLE IF EXISTS courses;

Səhv 6: Müvəqqəti cədvəllərlə problemlər

Müvəqqəti cədvəllər session bitəndə yox olur. Əgər səhvən session bitəndən sonra müvəqqəti cədvəli istifadə etməyə çalışsan, səhv alacaqsan.

Səhv nümunəsi:

CREATE TEMP TABLE temp_students (
    id SERIAL PRIMARY KEY,
    name VARCHAR(100)
);

-- Session bitdi, indi isə...
SELECT * FROM temp_students; -- Səhv: cədvəl artıq yoxdur!

Necə yayınmaq olar?

Session-lar arasında istifadə olunacaq müvəqqəti datanı adi cədvəldə saxla və ya session daxilində istifadəsini sənədləşdir.

Səhv 7: Test zamanı constraint-ləri unutmaq

Çox vaxt development zamanı bəzi constraint-ləri "sonra əlavə edərik" deyib ötürürsən. Amma təcrübə göstərir ki, "sonra" çox vaxt unudulur.

Səhv nümunəsi:

CREATE TABLE test_table (
    id SERIAL PRIMARY KEY,
    name VARCHAR(50)
);

-- Data əlavə edirik:
INSERT INTO test_table (name) VALUES ('Təkrarlanan Ad');
INSERT INTO test_table (name) VALUES ('Təkrarlanan Ad'); -- Problemlər başlayır...

Necə yayınmaq olar?

Test zamanı belə cədvəlləri constraint-lərlə yarat:

CREATE TABLE test_table (
    id SERIAL PRIMARY KEY,
    name VARCHAR(50) UNIQUE -- Baş ağrısından xilas edəcək
);