Shema baze podataka nije dijagram koji završite prije nego što počne „pravi” posao. Ona je jedna od najtrajnijih odluka o performansama u sustavu. Kod se može ponovno postaviti u nekoliko minuta; loše oblikovan podatkovni model može godinama neprimjetno opterećivati svaki upit, predmemoriju, migraciju, API odgovor i operativni incident.

Pragmatični cilj nije teorijska savršenost. To je shema koja jasno predstavlja poslovanje, štiti integritet podataka i podržava obrasce pristupa koji su važni. Vrhunske performanse obično proizlaze iz zajedničkog djelovanja te tri brige, umjesto optimiziranja jedne nauštrb drugih.

Počnite s pitanjima koja postavlja vaša aplikacija

Dizajn sheme često počinje imenicama: korisnici, narudžbe, proizvodi, računi. To je korisno, ali nepotpuno. Performanse uvelike ovise o glagolima: pronaći nedavne narudžbe kupca, rezervirati zalihe, navesti neplaćene račune, izračunati ukupan iznos za nadzornu ploču, dohvatiti API resurs s njegovim odnosima.

Prije odabira stupaca ili indeksa zapišite važna čitanja i pisanja. Uključite rutu ili zadatak koji ih pokreće, očekivane filtre, redoslijed sortiranja te zahtijeva li operacija jedan ili više redaka. To otkriva razliku između modela koji izgleda uredno i onoga koji učinkovito služi aplikaciji.

Primjerice, popis narudžbi često može zahtijevati narudžbe jednog kupca, najnovije prvo:

SELECT id, status, total_amount, created_at
FROM orders
WHERE customer_id = ?
ORDER BY created_at DESC
LIMIT 50;

Složeni indeks koji počinje s customer_id i nastavlja se s created_at usklađen je s tim upitom:

CREATE INDEX orders_customer_created_at_idx
ON orders (customer_id, created_at DESC);

Redoslijed stupaca indeksa nije kozmetički detalj. Indeks je najkorisniji kada odgovara načinu na koji baza podataka sužava i sortira skup rezultata. Indeksiranje svakog stupca nije strategija; povećava pohranu, usporava pisanja i poskupljuje održavanje.

Modelirajte istinu prije optimiziranja praktičnosti

Dobre performanse počinju ispravnim odnosima. Upotrijebite primarne ključeve, strane ključeve, jedinstvena ograničenja i odgovarajuću dopuštenost vrijednosti null kako bi nevaljana stanja bilo teško pohraniti. Validacija aplikacije važna je, ali nije zamjena za ograničenja baze podataka kada više procesa, uvoza, skripti ili usluga može zapisivati iste podatke.

Stavka narudžbe obično bi trebala referencirati i svoju narudžbu i svoj proizvod. Strani ključ dokumentira taj odnos i omogućuje bazi podataka da ga provodi. Jedinstveno ograničenje može spriječiti slučajne duplicirane vrijednosti ondje gdje poslovanje zahtijeva jedinstvenost, kao što je vanjska referenca plaćanja.

CREATE TABLE order_items (
    id BIGINT PRIMARY KEY,
    order_id BIGINT NOT NULL,
    product_id BIGINT NOT NULL,
    quantity INTEGER NOT NULL,
    unit_price DECIMAL(12, 2) NOT NULL,
    FOREIGN KEY (order_id) REFERENCES orders(id),
    FOREIGN KEY (product_id) REFERENCES products(id)
);

Primijetite pohranjeni unit_price. To je namjerna denormalizacija: stavka retka bilježi cijenu u trenutku kupnje umjesto da se oslanja na trenutačnu cijenu proizvoda. Time se čuva povijesna istina i izbjegava rekonstruiranje stare narudžbe iz promjenjivih podataka kataloga.

Normalizirajte prema zadanim postavkama, denormalizirajte uz dokaze

Normalizacija smanjuje dupliciranje i anomalije ažuriranja. Obično je pravo polazište za transakcijske sustave jer svakoj činjenici daje jedno autoritativno mjesto. E-adresa kupca pripada kupcu; pojedinosti proizvoda pripadaju proizvodu; stavka narudžbe bilježi činjenice specifične za tu kupnju.

Ali „uvijek normaliziraj” može postati jednako beskorisno kao i „uvijek denormaliziraj”. Neki putovi čitanja trebaju pažljivo duplicirane podatke, unaprijed izračunate ukupne iznose ili tablice sažetaka. Ključno je jasno izraziti kompromis.

Denormalizirajte kada postoji dokazana potreba, poput skupog i čestog upita koji ne može ispuniti svoj zahtjev usluge uz dobro indeksiranje i dizajn upita. Zatim definirajte kako duplicirano polje ostaje ispravno. Je li nepromjenjivo, ažurira li se transakcijski, ponovno izgrađuje zadatkom ili se tretira kao eventualno konzistentna projekcija? Ako je odgovor nejasan, optimizacija je preuranjena.

Odaberite vrste podataka koje odražavaju domenu

Vrste podataka prenose namjeru i utječu na ispravnost. Novac pohranjujte u numeričke stupce fiksne preciznosti, a ne kao vrijednosti s pomičnim zarezom. Vremenske oznake pohranjujte prema dosljednoj konvenciji, a rukovanje vremenskim zonama učinite odlukom za cijelu aplikaciju. Upotrebljavajte booleane za binarno stanje, ali zasebno polje statusa kada domena ima nekoliko smislenih stanja.

იდენტifikatori zaslužuju sličnu pažnju. Primarni ključ trebao bi biti stabilan i učinkovit za odnose. Javni API identifikatori mogu zahtijevati drukčija svojstva od internih ključeva, posebno kada bi izlaganje sekvencijalnih ID-ova bilo nepoželjno. Neka ta razlika bude namjerna umjesto da nastane iz praktičnosti.

Izbjegavajte generičke stupce koji skrivaju strukturu, poput tekstualnog polja koje sadrži identifikatore odvojene zarezima. Oni otežavaju validaciju, spajanja, indeksiranje i ažuriranja. Povezna tablica obično je jasnija:

CREATE TABLE team_members (
    team_id BIGINT NOT NULL,
    user_id BIGINT NOT NULL,
    role VARCHAR(50) NOT NULL,
    PRIMARY KEY (team_id, user_id),
    FOREIGN KEY (team_id) REFERENCES teams(id),
    FOREIGN KEY (user_id) REFERENCES users(id)
);

Ovaj dizajn prirodno sprječava dvostruko članstvo i podržava upite za članove tima putem primarnog ključa.

Dizajnirajte indekse na temelju stvarnih oblika upita

Indeksi trebaju odgovoriti na određeno pitanje. Pregledajte spore upite, ponašanje krajnjih točaka, pozadinske zadatke i administrativna izvješća. Zatim pregledajte planove upita u ciljnoj bazi podataka umjesto da pretpostavljate kako je indeks učinkovit. Plan otkriva koristi li baza podataka namjeravani indeks, skenira li previše redaka, nepotrebno sortira ili izvodi neočekivano skupo spajanje.

• Indeksirajte stupce stranih ključeva koji sudjeluju u spajanjima ili pretraživanjima odnosa.
• Prednost dajte složenim indeksima za uobičajene kombinacije filtara i sortiranja.
• Upotrebljavajte jedinstvene indekse za provedbu poslovnih pravila kao i za poboljšanje pretraživanja.
• Uklonite redundantne indekse nakon potvrde da ih pokriva bolji složeni indeks.
• Mjerite putove s mnogo pisanja jer svaki dodatni indeks ima trošak pisanja.

Budite osobito oprezni s fleksibilnim filtrima pretraživanja. Jedna krajnja točka „prikaži sve” s neobaveznim filtrima može dovesti do šume indeksa i ipak proizvesti loše planove. Često je bolji odgovor definirati nekoliko podržanih obrazaca upita, dosljedno primjenjivati paginaciju i specijaliziranim izvješćima dati vlastiti namjerni put podataka.

Držite API-je i migracije u razgovoru o dizajnu

Promjene sheme su promjene implementacije. Dodavanje stupca koji ne dopušta null, promjena vrste podataka, ponovna izgradnja indeksa ili preimenovanje polja može utjecati na postojeći kod aplikacije, zadatke u redu čekanja, replike i integracije. Tretirajte migracije kao produkcijski softver, a ne kao pogodnost lokalnog razvoja.

Za promjene koje moraju biti kompatibilne tijekom postupnih implementacija upotrijebite pristup proširenja i sažimanja. Najprije dodajte novi stupac koji dopušta null ili tablicu, implementirajte kod koji zapisuje obje reprezentacije, sigurno popunite postojeće podatke, prebacite čitanja nakon provjere i tek tada uklonite staru strukturu. Taj je slijed manje dramatičan od migracije u jednom koraku, ali znatno smanjuje rizik implementacije.

Na sloju PHP aplikacije izbjegavajte pretvaranje nedostataka sheme u skriveno ponašanje ORM-a. Unaprijed učitajte odnose kada su potrebni API odgovoru, odaberite samo potrebna polja i pazite na ponovljene upite unutar petlji. Elegantan objektni model i dalje može generirati neučinkovito opterećenje baze podataka.

Učinite održivost značajkom performansi

Najbrža shema nije nužno ona s najmanje spajanja. To je ona koju budući inženjer može dovoljno dobro razumjeti da je sigurno mijenja. Upotrebljavajte dosljedno imenovanje, dokumentirajte neuobičajena ograničenja, jasno odredite vlasništvo nad izvedenim podacima i održavajte migracije preglednima.

Performanse su svojstvo sustava. Smislena shema, ciljani indeksi, predvidljivi API upiti i pažljive implementacije međusobno se osnažuju. Počnite s istinom domene, optimizirajte putove kojima korisnici doista idu i zahtijevajte dokaze prije dodavanja složenosti. To je pragmatičan put: ne savršena shema zamrznuta u vremenu, nego jasan model koji se može razvijati bez da postane usko grlo koje je trebao spriječiti.