offline
- beli0135
- Executor
- Pridružio: 03 Jan 2005
- Poruke: 2990
- Gde živiš: Beograd
|
Mali trikovi u radu sa bazama.
Ovaj clanak je namenjen i pocetnicima i iskusnijim programerima, pa je preporuka da se procita.
1. Dizajn baze
==============
Prvo se postavlja pitanje za cega ce program da sluzi? Da li je to licna bazica podataka, tipa kataloga CD-ova, filmova itd, ili je to komercijalni program?
U slucaju da je licna baza, lokalne baze tipa Access, Paradox, DBaseIII, AbsoluteDB, pa cak i FlatFile su odlicne za taj posao: Lako prenosive i male.
Medjutim, to nije dobro za komercijalne programe, ma kako firma bila mala ili mali broj kompjutera imala. Firme imaju tendenciju da se zatvaraju i da se shire. Skoro nikad ne ostaje na istom. Ako se shire, brzo ce i da raste broj kompjutera koji pristupa bazi, eventualno i razlicite lokacije u zemlji, pa cak i na planeti.
Lokalne baze tu ne rade posao. Mora se instalirati server.
Ako firma vec ima server baze, i obavezuje vas da ga koristite, onda nemate izbora. Medjutim, ako su do sada imali lokalnu bazu ili vam uopste ne diktiraju uslove kakav server moze da bude. Onda je izbor na vama.
Klasicne zamke:
----------------
1. Ostaviti klijenta na lokalnoj bazi koju vec koristi
2. Praviti program za moderniju lokalnu bazu
3. Ostaviti istu strukturu baze i vecinu tabela
4. Ostaviti ista pravila (Business rules) koja su vazila u starom programu, bez istrazivanja da li su ona uopste ispravna.
5. "Ja sam navikao tako da radim" uopste ne znaci da je to i pravilno. Treba klijentu objasniti implikacije, a ne prihvatiti zdravo za gotovo, i naci resenje koje je pravilno i prihvatljivo.
Sto se samog dizajna tice, obicno ide pravilo: nikad ne stavljaj tekstualno polje, koje je moguce zameniti drugom tabelom i vezati ga preko integer, kljuc polja.
Serveri baza imaju tendenciju da se usporavaju, ne u zavisnosti od broja tabela, broja zapisa i megabajta/gigabajta, nego ne pravilnim odabirom polja, losim indeksiranjem itd.
Mali primer:
Ako imate tabelu od 3 polja, ID, datum i status (text), u koji cete upisivati slovima, recimo "Otisao", "Dosao"... bice mnogo sporije nego da napravite 2 tabele, od kojih ce prva imati ID, Datum i ID polja statusa, a druga "status" tabela, imati svoj ID i opis statusa. Naravno, polja ID Status iz prve tabele, i primarni kljuc ID Status iz statusne tabele, bice u relaciji. Samim tim, treba kreirati index na prvoj tabeli, ka tom polju.
2.Kako kreirati tabele
======================
Svako ima neki svoj nacin na koji je navikao da kreira tabele i daje imena poljima. Razumljivo je, ali nije i najbolji nacin. To ste sigurno primetili ako ste prepravljali necju tudju bazu. Koliko ste ga samo psovali?
Iskustvo od preko 20 godina je kreiralo jedan novi standard, koji se, moram priznati, najvise koristi u Brazilu. Elem, posto je zadnjih decenija, Brazil poznat kao najveci izvoznik tehnologije na planeti, treba shvatiti ove standarde krajnje ozbiljno.
Sada cu vam navesti pravila koja se koriste kod nomenklature tabela i polja.
Pravilo 1:
Tabela, uvek ima naziv onoga sta predstavlja, uvek u mnozini. (primer za artikle, tabela bi trebala da se zove "Artikli".
Pravilo 2:
Nazivi polja uvek pocinju sa prefiksom od 3 slova, koje smisleno odgovara svojoj tabeli, ako je moguce. Iza prefiksa sledi "underscore" ( _ ), pa onda 3 slova koja oznacavaju tip podatka u polju. (za tabelu "Artikli", smislen prefix bi bio "ART_" ili "ATK_", "ARK_" ili nesto slicno).
Za 3 slova od tipa podataka cu objasniti detaljnije u nastavku.
Pravilo 3:
Ime polja primarnog kljuca UVEK sadrzi ime tabele, ali u jednini.
(Za tabelu "Artikli", polje primarnog kljuca bi izgledao "ART_CdiArtikal")
Oznake tipova podataka
-----------------------
Od ta 3 slova, prva sva slova su "Upotreba", a zadnje je sam tip.
(ovde iznosim najcesce koriscene)
Cdi = Code, Integer (ova polja su obicno primarni i sekundarni kljucevi)
Cos = Code, String (tekstualno polje koje ima zadatak da prikaze tekstualnu identifikaciju, recimo neke opreme ili string oznaku - ona se obicno ne indexiraju)
Dss = Description, String
ovde ima malo grananje. Ako je aplikacija multijezicka, obicno se koristi, SAMO za polja koja podlezu promeni usled jezika: D1s, D2s, D3s.... gde su 1,2,3 razliciti jezici
Dsb = Description, BLOB / IMAGE
Nui = Number, integer (ova polja se nikad ne indeksiraju)
Nus = Number, string representation
Vln = Value, number (double precision)
Qti = Quantity, integer
Qtn = Quantity, number (double)
Dti = Date, integer (obicno za cuvanje meseca (april = 4) ili godine)
Dtd = Date, DateTime
Hrd = Hour, DateTime (obicno frakcionarni deo.... 0,6266262)
Pci = Percentage, integer
Pcn = Percentage, number (double)
Opl = Option, logic (boolean - mada je praksa pokazala da je bolje praviti integer polje koje ce da sadrzi 0 i 1, nego da sadrzi boolean vrednost. Ime je ostalo ne promenjeno)
Zasto sve ovo?
==================
Iz vise razloga. Prvi je sto je vrlo ocigledno, na prvi pogled, cemu koje polje sluzi i kog je tipa. Drugi, lako se pamti da je primarni kljuc tabele Rafovi, RAF_CdiRaf (eventualno treba pogledati prefix) i samim tim se odmah zna koja tabela vezuje koju. Takodje, ko god da uzme da radi program od predhodnog programera, ne gubi vreme da razume sta je sta.
Treca stvar je da se izbegava maksimalno stavljanje prefiksa u SQL upite.
Hajdemo da napravimo malu banalnu bazu artikala i polica. Necu navoditi tipove polja, ako pogledate listu iznad, bice vam jasno kako to radi.
Materijali (nek budu materiali od kog su napravljeni artikli, a moze da koristi i za police.. recimo tekstil, drvo, metal itd)
MAT_CdiMaterijal, MAT_DssMaterijal
Artikli (informacije o artiklima)
ART_CdiArtikal, ART_DssArtikal, ART_CosArtikal_Oznaka, ART_VlnCena, ART_CdiMaterijal
Police (informacije o policama)
PLC_CdiPolica, PLC_CdiMaterijal, PLC_NuiVisina_Cm, PLC_NuiSirina_Cm
PolicexArtikli (Police X Artikli - dodeljujemo artikle na odredjenu policu)
PLA_CdiPolicaxArtikal, PLA_CdiPolica, PLA_CdiArtikal
-----------------------
Sada zelimo da vidimo koji su artikli na kojoj (drvenoj) polici, i od kog je materijala koji artikal
SELECT PLC_CdiPolica, ART_CosArtikal_Oznaka, ART_DssArtikal, ART_VlnCena, MAT_DssMaterijal
FROM PolicexArtikli
INNER JOIN Police on (PLC_CdiPolica=PLA_CdiPolica)
INNER JOIN Artikli on (ART_CdiArtikal = PLA_CdiArtikal)
INNER JOIN Materijali on (MAT_CdiMaterijal = ART_CdiMaterijal)
WHERE
PLC_CdiMaterijal = 2 --(drvo)
Nadam se da je za sada jasno. Bice jos o bazama 
Article published by GPL/GNU license
|
