MyCity :: Baze podataka

Preporuke korisnih aplikacija za baze podataka

nobody@mycity.rs (Fil) — Tue, 07 May 2013 20:06:33 +0100

HeidiSQL is a MySQL front-end that enables you to manage your database and browse table contents from an easy-to-use Windows interface. In addition to common tasks such as running SQL queries, creating, dropping and editing tables, you can also perform various maintenance operations including integrity check, database optimization, repair and more. Furthermore, you can import data from text files, synchronize tables between two databases and export selected tables to other databases or SQL scripts. Other features include editing of BLOBs and MEMOs, support for large SQL scripts, user process management and more. Open Source.

Download and read more from:
Tekst za link

Optimizacija u MySQL 5.1

nobody@mycity.rs (umpirsky) — Sun, 01 Jul 2007 19:45:24 +0100

Uvod

Sistem za upravljanje bazama podataka (database management system, DBMS) je softverska komponenta namenjena rukovo�enju bazama podataka, velikim skupom struktuiranih podataka, i izvr�avanju operacija nad podacima koje zahteva veliki broj korisnika. Tipi�ne upotrebe ovih sistema uklju�uju bankarske sisteme, ra�unovodstvo, sve vrste web i desktop aplikacija i mnoge druge.

Osnove MySQL-a

MySQL је vi�enitni, vi�ekorisni�ki SQL sistem za upravljanje bazama podataka (DBMS), sa oko deset miliona instalacija. MySQL AB obezbe�uje MySQL kao slobodan softver pod GNU licencom.

phpMyAdmin je klijent pisan u programskom jeziku PHP za potrebe administriranja MySQL sistema baza podataka . On pru�a usluge kreiranja I uni�tavanja baza podataka, tabela, vrsta, izvo�enje raznih operacija sa tabelama, dumpovanje baza I tabela, pode�avanje engine-a, kreiranje, brisanje korisnika, izvr�avanje SQL upita I mnoge druge.

U unix okru�enju mogu�a je administracija MySQL servera direktno iz komandne linije kori��enjem mysql klijenta.

Popularnost ovog DBMS-a je sve ve�a, s�obzirom da je besplatan i da je konkurentan sa ostalim DBMS-ovima po kriterijumu funkcionalnosti i performansi. Veoma se dobro pokazao u kombinaciji sa PHP-om. Popularnost ove kombinacije se mo�e pripisati open source prirodi oba proizvoda te postojanjem besplatnih verzija za sve glavne funkcionalnosti, �to olak�ava njihovo u�enje i kori��enje kako po�etnicima tako i profesionalcima.

Optimizacija sistema

Najbitniji faktor optimizacije jednog sistema le�i u osnovi njegovog projektovanja. Moramo unapred znati kakvu vrstu procesiranja podataka na� sistem obavlja i koje su njegove osnovne komponente, kao I �ta u tom sistemu predstavlja �usko grlo�, kako bi znali gde traba izvr�iti optimizaciju. Koreni neoptimalnosti, na koje naj�e��e ne mo�emo da uti�emo le�e u:
� Pretra�ivanje podataka na hard disku. Kod savremenih diskova ova vremena su ispod 10ms. Ovo vreme se postepeno smanjuje napretkom tehnologije. Optimizacija bi se ovde svela na distribuiranje podataka na vi�e hard diskova.
� �itanje i upis podataka. Kada se glava diska nalazi na �eljenoj poziciji, treba pro�itati podatke. Kod novih diskova brzina �itanja je oko 20MB/s. Naravno da je lak�e optimizovati pretra�ivanje podataka, jer mo�emo �itati podatke paralelno sa vi�e diskova.
� Procesorsko vreme. Kada podatke imamo u memoriji, moramo da ih obradimo da bismo dobili �eljeni rezultat.
� Propusni opseg memorije. Kada je procesoru potrebno vi�e podataka nego �to mo�e da stane u njegov interni ke�, propusni opseg glavne memorije postaje usko glo. Ovo nije uobi�ajen problem za ve�inu sistema, ali I o tome se treba voditi ra�una kada se �ele vrhunske performanse.
Ograni�enja MySQL-a
Kada koristimo MyISAM engine za sme�tanje podataka, MySQL koristi ekstremno brz sistem zaklju�avanja tabela koji dozvoljava vi�e �itaoca ili jednog pisca. Najve�i problem sa ovim engine-om za sme�tanje podataka se javlja kada imamo konstantne update-ove I spore select upite na jednoj tabeli. Ako je ovo problem sa odre�enim tabelama, po�eljno je koristiti neki drugi engine za sme�tanje podataka radi postizanja boljih performansi. To mou biti InnoDB, HEAP, NDB�
MySQL mo�e da radi sa transakcionim i netransakcionim tabelama. Ukoliko radimo sa netransakcionim tabelama dobi�emo na brzini, ali neamo mogu�nost da povratimo podatke u slu�aju da ne�to krene naopako sa operacijom koja se izvr�ava (npr ako se ona iznenadno prekina iz nekog razloga). U tu svrhu se mo�e koristiti klju�na re� IGNORE u kombinaciji sa INSERT ili UPDATE.

Projektovanje prenosivih aplikacija
Zbog toga �to svaki od DBMS implementira razli�ite delove SQL standarda, dosta je te�ko napraviti prenosivu(kompatibilnu) aplikaciju. Jednostavno je posti�i kompatibilnost sa prostim selelectima i insertima, ali �to oni postaju komplikovaniji, to je te�e zadr�ati kompatibilnost uz o�uvanje performansi. Tako da ovde projektant mora da napravi kompromis izme�u prenosivosti i performansi.
Da bi kompleksna aplikacija bila prenosiva, pre po�etka samog projektovanja moramo da odlu�imo sa kojim DBMS-ovima mora da bude kompatibilna, i da onda vidimo koje mogu�nosti svaki od njih pru�a. Mo�emo koristiti MySQL crash-me program da bi prona�li funkcije, tipove, i ograni�enja DBMS-a. Na primer kori��enjem crash-me programa, mo�emo dobiti informaciju da ne mo�emo da koristimo imena kolona du�a od 18 karaktera ako �elimo da radimo sa DB2 ili Informix-om.
Crash-me i MySQL benchmark su nezavisni od konkretnoh DBMS-ova. Napisani su u Perl-u I koriste DBI interfejs. Kori��enje DBI interfejsa re�ava mnoge probleme kompatibilnosti jer nudi metode pristupa koje su nezavisne od konkretnog DBMS-a.
MySQL benchmark
MySQL benchmark nam omogu�ava da predvidimo pona�anje i performanse operacija koje nam nudi ovaj DBMS. Izvorni kod benchmark-a je dostupan i nalazi se u sql-bench direktorijumu u bilo kojoj MySQL izvornoj distribuciji.
Ovaj benchmark je jednonitni, tako da �e uzeti minimalno vreme za izvr�enje tra�ene operacije. U planu je implementacija vi�enitnog benchmarka koji �e dati realniju sliku pona�anja sistema.
Optimizacija SELECT upita
Prvi faktor koji uti�e na sve upite koji se izvr�avaju jeste slo�enost korisnikovih privilrgija. Kori��enje jednostavnijih privilegija u GRANT upitu omogu�ava MySQL-u da optimizuje (redukuje) proveru privilegija kada kada korisnik izvr�ava upite. Na primer ako ne ograni�avamo pristup na nivou tabela ili kolona, server ne mora da proverava tabelu privilegija tabela i tabelu privilegija kolona. Sli�no tome, ako ne postavimo ograni�enja vezana za resurse, server ne mora da provrava kori��enje resursa.
Tako ako imamo veliko optere�enje sistema sa dosta upita koji se vrlo frekventno izvr�avaju, pojednostavljenje �eme privilegija mo�e umnogome da optimizuje rad.
Ako je problem vezan za specifi�ne MySQL izraze ili funkcije, mo�emo primeniti tajming test kori��enjem BENCHMARK() funkcije iz mysql klijenta. Njena sintaksa je BENCHMARK(loop_count,expression). Povratna vrednost uvek nula, ali mysql �tampa aproksimativnu procenu vremena izvr�enja upita. Na primer;
mysql> SELECT BENCHMARK(1000000,1+1);
+------------------------+
| BENCHMARK(1000000,1+1) |
+------------------------+
| 0 |
+------------------------+
1 row in set (0.32 sec)
Ovaj rezultat je dobijen na Pentium II 400MHz ma�ini, �to pokazuje da MySQL mo�e da izvr�i 1.000.000 sabiranja za 0.32 sekunde na takvom sistemu.
Sve MySQL funkcije su optimizovane do visokog nivoa, mada ima i nekih izuzetaka. BENCHMARK() je odli�na alatka za lociranje funkcije koja pravi probleme u na�im upitima.
Optimizacija upita kori��enjem klju�ne re�i EXPLAIN
EXPLAIN tbl_name
Ili:
EXPLAIN [EXTENDED | PARTITIONS] SELECT select_options
Mo�e se koristiti kao sinonim za DESCRIBE ili kao na�in da se dobiju informacije o tome kako MySQL izvr�ava SELECT upit:
� EXPLAIN tbl_name je sinonim za DESCRIBE tbl_name ili SHOW COLUMNS FROM tbl_name.
� Kada izvr�imo SELECT upit sa klju�nom re�ju EXPLAIN, MySQL prikazuje informacije prosle�ene od strane optimizatora o planu izvr�enja upita. To je obja�njenje kako MySQL procesira upit, uklju�uju�i i informacije o tome na koji na�in su tabele spojene, kojim redosledom�
� Konstrukcija EXPLAIN PARTITIONS je dostupna sa verzijom MySQL 5.1.5. Korisna je samo kada ispitujemo upite koji uklju�uju parcijalizovane tabele.
Uz pomo� EXPLAIN, mo�emo videti gde su nam neophodni indeksi za br�e izvr�enje SELECT upita. Mo�emo tako�e videti kada optimizator spaja tabele optimalnim redosledom, a kada ne. Mo�emo ga naterati da koristi redosled stajanja tabela u optimalnom redosledu. Da bi spajali tabele u redosledu navedenom u upitu, koristimo SELECT STRAIGHT_JOIN umesto SELECT.
Ukoliko imamo problem da indeksi nisu kori��eni kada mi verujemo da trebaju, mo�emo pokrenuti ANALYZE TABLE za statistiku o kardinalnosti klju�eva, �to mo�e dovesti do promene pona�anja optimizatora.
Brzina SELECT upita
Generalno, kada �elimo da izvr�enje na�eg sporog SELECT � WHERE upita ubrzamo, prva stvar koju treba da proverimo jesu indeksi. Sve veze me�u tabelama treba da budu ostvarene kori��enjem indeksa. Mo�emo koristiti EXPLAIN da otkrijemo koji indeksi se koriste u na�em SELECT upitu.
Evo jo� nekih na�ina za ubrzanje upita nad MyISAM tabelama:
� Da bi pomogli MySQL-u da optimizuje upite, koristimo ANALYZE TABLE ili pokre�emo myisamchk-analyze nad tabelom po�to ona biva napunjena podacima.Ovo osve�ava vrednost svakog indeksa koji ukazuje na vi�e kolona koje imaju istu vrednost (za UNIQUE indekse je uvek jedan). MYSQL ovo koristi da odlu�i koji indeks da izabere pri spajanju dve tabele kada je spajanje bazirano na nekom izrazu koji nije konstanta. Tako�e mo�emo koristiti SHOW INDEX FROM tbl_name da bi ispitali cardinalnost veze. myisamchk --description �verbose prikazuje informacije o indeksima tako�e.
� Da bi sortirali podatke u zavisnosti odindeksa, koristimo myisamchk --sort-index --sort-records=1 (uz pretpostavku da �elimo sortiranje po indeksu 1). Ovo je dobar na�in da ubrzamo izvr�enje upita ukoliko imamo unique indeks pomo�u kog �elimo da pro�itamo sve vrste u redosledu koji zavisi od tog indeksa. Kada prvi put sortiramo veliku tabelu na ovaj na�in, to mo�e da potraje.
Optimizacija WHERE klauzule
Ovde �e biti re�i o optimizaciji WHERE klauzule. U primerima �emo koristiti SELECT upite, ali ista logika va�i i za DELETE i UPDATE upite.
MySQL optimizator sa svakom novom verzijom postaje sve bolji, ali uvek ima mesta za optimalnije napisan upit, koji MySQL ne mo�e da optimizuje bez na�e pomo�i.
Evo nekih optimizacija koje MySQL �ini kada je u pitanju WHERE klauzula:
� Uklanjanje suvi�nih zagrada:
o ((a AND b) AND c OR (((a AND b) AND (c AND d))))
o -> (a AND b AND c) OR (a AND b AND c AND d)
� Evaluacija konstanti:
o (a<b AND b=c) AND a=5
o -> b>5 AND b=c AND a=5
� Uklanjanje suvi�nih uslova:
o (B>=5 AND B=5) OR (B=6 AND 5=5) OR (B=7 AND 5=6)
o -> B=5 OR B=6
� COUNT(*) nad jednom tabelom bez WHERE klauzule biva direktno pro�itana iz MyISAM i MEMORY tabela. Ovo je tako�e slu�aj za bilo koji NOT NULL izraz kada radimo sa samo jednom tabelom.
� Brza detekcija nevalidnih izraza. MySQL brzo detektuje da neki SELECT upit ne�e vratiti podatke.
� HAVING je integrisan sa WHERE ako ne koristimo GROUP BY ili agregacione funkcije (COUNT(), MIN(), i sli�ne).
� Za svaku tabelu u spoju, jednostavniji WHERE je konstruisan da bi se dobila �to br�a evaluacija i �to br�e preskakanje nepotrebnih vrsta.
� Konstantne tabele bivaju pro�itane pre bilo kojih drugih tabela u upitu. Konstantne tabele su:
o Prazna tabela ili tabela sa jednom vrstom.
o Tabela koja je kori��ena u WHERE klauzuli na PRIMARY KEY ili UNIQUE indeksu.
Sve tabele u narednom primeru su kori��ene kao konstantne:
SELECT * FROM t WHERE primary_key=1;
SELECT * FROM t1,t2
WHERE t1.primary_key=1 AND t2.primary_key=t1.id;
� Najbolja kombinacija za spajanje tabela se dobija poku�avanjem svih mogu�nosti. Ako sve kolone u ORDER BY i GROUP BY klauzuli pripadaju istoj tabeli, ta tabela treba da bude prva u spoju.
� Ako postoji ORDER BY klauzula i druga GROUP BY klauzula, ili ako ORDER BY ili GROUP BY klauzula sadr�i kolone tabela koje nisu prve u redu za spajanje, kreira se privremena (temporary) tabela.
� Ako koristimo SQL_SMALL_RESULT opciju, MySQL koristi privremenu tabelu koja se nalazi u glavnoj memoriji.
� Pre izbacivanja vrsta, one koje ne zadovoljavaju HAVING klauzulu bivaju odba�ene.
Evo primera nekih veoma brzih upita:
SELECT COUNT(*) FROM tbl_name;

SELECT MIN(key_part1),MAX(key_part1) FROM tbl_name;

SELECT MAX(key_part2) FROM tbl_name
WHERE key_part1=constant;

SELECT ... FROM tbl_name
ORDER BY key_part1,key_part2,... LIMIT 10;

SELECT ... FROM tbl_name
ORDER BY key_part1 DESC, key_part2 DESC, ... LIMIT 10;
MySQL re�ava slede�e upite kori��enjem samo stabla indeksa:
SELECT key_part1,key_part2 FROM tbl_name WHERE key_part1=val;

SELECT COUNT(*) FROM tbl_name
WHERE key_part1=val1 AND key_part2=val2;

SELECT key_part2 FROM tbl_name GROUP BY key_part1;
Slede�i upiti koriste indekse da dobave vrste u sortiranom redosledu, bez dodatnog prolaska algoritma za sortiranje:
SELECT ... FROM tbl_name
ORDER BY key_part1,key_part2,... ;

SELECT ... FROM tbl_name
ORDER BY key_part1 DESC, key_part2 DESC, ... ;

Optimizacija LEFT JOIN i RIGHT JOIN upita
Optimizator spoja izra�unava redosled u kome tabele trebaju biti spajane. Mo�emo sami nametnuti redosled spajanje kori��enjem by LEFT JOIN or STRAIGHT_JOIN i na taj na�in pomo�i optimizatoru da svoj deo posla obavi mnogo br�e, zato �to je potrebno manje permutacija tada proveriti.Primetimo da ako imamo upit slede�eg tipa:
SELECT *
FROM a JOIN b LEFT JOIN c ON (c.key=a.key)
LEFT JOIN d ON (d.key=a.key)
WHERE b.key=d.key;
MySQL radi �full scan� nad tabelom b, zato �to LEFT JOIN zahteva da je pro�ita pre d.
Optimizacija bi se u ovo slu�aju svela na obrtanje redosleda u kome navodimo a i b u FROM klauzuli:
SELECT *
FROM b JOIN a LEFT JOIN c ON (c.key=a.key)
LEFT JOIN d ON (d.key=a.key)
WHERE b.key=d.key;
Za LEFT JOIN, ako je uslov u WHERE klauzuli uvek false za generisanu NULL vrstu, LEFT JOIN se pretvara u obi�an JOIN. Na primer, uslov u WHERE klauzuli �e biti false u slede�em upitu ako t2.column1 bude NULL:
SELECT * FROM t1 LEFT JOIN t2 ON (column1) WHERE t2.column2=5;
Zato je sigurnije da napi�emo klasi�an join:
SELECT * FROM t1, t2 WHERE t2.column2=5 AND t1.column1=t2.column1;
Ovo mo�e biti br�e zato �to MySQL mo�e koristiti tabelu t2 pre t1 ako to daje bolje rezultate kod planiranja upita. Da bi nametnuli specifi�an redosled koristimo STRAIGHT_JOIN.

Optimizacija INSERT upita
Vreme potrebno za unos vrste u tabelu je determinisano slede�im faktorima, gde brojka u zagradi ozna�ava aproksimaciju proporcije ukupnog vremena:
� Povezivanje: (3)
� Slanje upita serveru: (2)
� Parsiranje upita: (2)
� Unos vrste: (1 � veli�ina vrste)
� Unos indeksa: (1 � broj indeksa)
� Zatvaranje: (1)
Veli�ina tabele usporava unos indeksa za logN, indeksi implementirani pomo�u B-stabla.
Mo�emo koristiti slede�e metode da optimizujemo INSERT upite:
� Ako unosimo vi�e vrsta sa istog klijenta u isto vreme, koristimo INSERT upite sa vi�e VALUES listi da bi uneli vi�e vrsta istovremeno. Ovo je u ve�ini slu�ajeva nekoliko puta br�e od kori��enja odvojenih INSERT upita za svaku vrstu.
� Ako dodajemo podatke u nepraznu tabelu, mo�emo koristiti bulk_insert_buffer_size promenljivu da u�inimo unos podataka br�im.
� Ako vi�e klijenata unosi mnogo vrsta, mo�emo dobiti ubrzanje kori��enjem INSERT DELAYED konstrukcije.
� Sa MyISAM tabele, mo�emo koristiti konkurentne inserte da bi dodavali vrste za vreme izvr�enja SELECT upita.
� Kada u�itavamo tabele iz tekstualne datoteke, koristimo LOAD DATA INFILE. Ovo je obi�no oko 20 puta br�e od INSERT upita.

Optimizacija UPDATE upita
Update upiti su optimizovani kao i SELECT upiti, sa dodatkom za upis. Brzina pisanja zavisi od koli�ine podataka koje osve�avamo i broja indeksa koje osve�avamo. Indeksi koji ostaju nepromenjeni nisu obuhva�eni UPDATE operacijom.
Drugi na�in da dobijemo brze update-ove je da ih �uvamo i onda uradimo vi�e njih odjednom kasnije. Izvr�enje vi�e update-ova odjednom je mnogo br�e od pojedina�nog izvr�enja svakog od njih ako pritom vr�imo zaklju�avanje tabela.
Za MyISAM tabele koje korisre dinami�ki format vrsti, update-ovanje vrste sa pove�anjem njene du�ine, mo�e je podeliti na dve vrste. Ako ovo �inimo �esto, veoma je va�no da koristimo OPTIMIZE TABLE konstrukciju.
Optimizacija DELETE upita
Vreme potrebno za brisanje vrste je proporcionalno broju indeksa. Da bi obrisali vrste �to br�e, mo�emo pove�ati veli�inu ke�a klju�eva kori��enjem key_buffer_size sistemske promenljive.
Ostali na�ini optimizacije
Evo jo� nekoliko na�ina optimizacije u MySQL-u:
� Kori��enje perzistentne(stalne) konekcije na bazu ubrzava sve operacije sa bazom, jer nemeamo gubljenje resursa I vremena na povezivanje, a to je jedna od zahtevnijih operacija. Ako pak ne mo�emo da koristimo perzistentnu konekciju I stalno inicijalizujemo mnogo novih konekcija ka bazi, mo�emo izmeniti vrednost thread_cache_size sistemske promenljive.
� Treba izbegavati komplikovane SELECT konstrukcije nad MyISAM tabelama koje se frekventno update-uju, da bismo izbegli probleme sa zaklju�avanjem koji se javljaju izme�u �itaoca i pisca.
� Replikacija mo�e pobolj�ati neke performanse. Mo�emo distribuirati klijentovo pretra�ivanje na replikacione servere da bi podelili protok podataka. Da bismo izbegli usporenje mastera dok pravi backuo-ove, mo�emo ih praviti kori��enjem slave servera.
� Da bi popravili rezultate koji se dobijaju kori��enjem ARCHIVE tabela, mo�emo koristiti OPTIMIZE TABLE.
� Za MyISAM tabelekoje se �esto menjaju, mo�emo poku�ati da izbegnemo sve tipove kolona promenljive du�ine(VARCHAR, BLOB, and TEXT). Ovakve tabele koriste dinami�ki format za vrste, �to je kriti�no kod frekventnog update-a.
� Mo�emo koristiti INSERT LOW_PRIORITY kada �elimo ve�i prioritet da damo SELECT upitima.
� Kori��enjem SELECT HIGH_PRIORITY mo�emo posti�i da presko�imo klijentski upis koji stoji u redu �ekanja na izvr�enje i momentalno izvr�imo na� SELECT. LOW_PRIORITY i HIGH_PRIORITY uzimaju efekta samo kod engine-a za sme�tanje podataka koji koriste samo zaklju�avanje na nivou tabela (MyISAM, MEMORY, MERGE).
� Kori��enje LOAD DATA INFILE za velike koli�ine podataka je mnogo br�e od INSERT upita.
� Kori��enje AUTO_INCREMENT polja je korisno, tako da svaka vrsta mo�e biti identifikovana jedinstvenom vredno��u.
� Slike I drugi binarni sadr�aji mogu biti sa�uvani kao fajlovi. Zato treba �uvati samo adrese (putanje) do njih na serveru, a ne sadr�aj celih fajlova u bazi. Ve�ina Web servera je bolja u ke�iranju fajlova od samog DBMS-a, tako da je kori��enje fajlova generalno br�e.
Optimizacija baze podataka je veoma kompleksan zadatak, zato �to zahteva razumevanje principa rada celokupnog sistema. Mada je mogu�e primeniti neke loi�ke optimizacije sa malo osnovnog znanja o sistemu ili aplikaciji koju �elimo optimizovati. Jedno je sigurno, �to bolju optimizaciju �elimo, to vi�e znanja moramo posedovati.

Ovde sam poku�ao da objasnim i dam primer razli�itih na�ina optimizacije u MySQL-u. Naravno, uvek postoji na�in da sistem postane br�i, potrebno je eksperimentisati i dublje prou�avati sam sistem.

Kako dizajnirati bazu podataka

nobody@mycity.rs (beli0135) — Fri, 02 Mar 2007 21:35:12 +0100

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

MS Access - korisni linkovi i primeri

nobody@mycity.rs (soxxx) — Fri, 14 Jul 2006 12:31:28 +0100

Sajtovi posveceni MS Access-u:

functionx.com/access/
databasedev.co.uk/
utteraccess.com/
mvps.org/access/
blueclaw-db.com/
accessfreak.net
microsoft-accesssolutions.co.uk/
access-programmers.co.uk/
programmingmsaccess.com/
fabalou.com/
yaccess.com/ (Linkovi do sajtova, uglavnom nemackih, sadrze clanke, primere itd)
databasejournal.com/features/msaccess/
drewslair.com/desk/access_series/Intro.htm
aspfree.com/c/b/Microsoft-Access/
functionx.com/vbaccess/
accessdb.info/
home.bendbroadband.com/conradsystems/accessjunkie.html
techtutorials.net/Applications/Microsoft_Office/MS_Access/index.shtml

Primeri, VBA kodovi, Tutorijali:

fgcu.edu/support/office2000/access/
bcschools.net/staff/AccessHelp.htm
databases.about.com/od/tutorials/
databasedev.co.uk/downloads.html
acc-technology.com/
tutorials.beginners.co.uk/index/category/104
pcvoyager.com/dir/database_access.html
comeandread.com/access/
programmingmsaccess.com/Samples/
blueclaw-db.com/ms_access_examples/
kayodeok.btinternet.co.uk/favorites/kbofficeaccess.htm

P.S. Naravno ako neko ima jos korisnih linkova neka postuje.

Pozdrav!!

Dodatak:

Ko se slabo snalazi sa Engleskim jezikom evo par linkova za nas maternji:)

Elitesecurity.org-Access forum

Forum Nove Tehnologije BIH-Access forum

Kompletna Kljiga na Srpskom jeziku:
icentar.com/showthread.php?t=80

Sadrzaj knjige:
01-Sta je baza podataka.
02-Planiranje baze podataka.
03-Pokretanje i napustanje accessa.
04-Upotreba pomoci u accessu.
05-Stvaranje nove baze podataka.
06-Spremanje, zatvaranje i otvaranje baze podataka.
07-Stvaranje tablice uz pomoc table wizarda.
08-Stvaranje tablice bez pomoci carobnjaka.
09-Unosenje promena u tablicu.
10-Stvaranje odnosa izmedju tablica.
11-Unosenje podataka u tablicu.
12-Uredjivanje podataka u tablici.13-Formatiranje tablice.
14-Stvaranje jednostavne forme.
15-Unosenje promena u formu.
16-Stvaranje posebnih polja za unos podataka u formu.
17-Dodavanje slika u formu.
18-Pronalazenje podataka.
19-Sortiranje,indeksiranje i filtriranje podataka.
20-Stvaranje jednostavnog upita.
21-Dizajniranje vlastitog upita.
22-Prilagodjavanje upita.
23-Stvaranje jednostavnog izvestaja.
24-Prilagodjavanje izvestaja.
25-Rad s povezanim tablicama.
26-Stvaranje dijagrama.
27-Upotreba accessa na internetu.
28-PDeljenje baze podataka s drugim korisnicima.
29-Uvoz i izvoz podataka.
30-Sigurnosna pohrana podataka.

snoop: Izdvojio sam ovu temu jer ima korisne informacije za one koji zele da udju u kostac sa Accessom... : )

SQL tutorial by snoop

nobody@mycity.rs (m4rk0) — Tue, 20 Jun 2006 18:02:08 +0100

0. lekcija - baza podataka i SQL jezik - [Link mogu videti samo ulogovani korisnici]
1. lekcija - kreiranje tabele - [Link mogu videti samo ulogovani korisnici]
2. lekcija - Insert - [Link mogu videti samo ulogovani korisnici]
3. lekcija - Select - [Link mogu videti samo ulogovani korisnici]
4. lekcija - Where - [Link mogu videti samo ulogovani korisnici]
5. lekcija - Update - [Link mogu videti samo ulogovani korisnici]
6. lekcija - Delete - [Link mogu videti samo ulogovani korisnici]

A.
Appendix 1 - Advanced SQL-ing - [Link mogu videti samo ulogovani korisnici]

0. lekcija - baza podataka i SQL jezik

Baza podataka sluzi da skladisti zeljene podatke, da te podatke organizuje po tabelama, i da ih zatim jednostavno i brzo dostavi 'klijentu' koji trazi te podatke...

Verovatno se pitate kako sve to funkcionise...

Postoji na jednoj strani server [gde se cuvaju podaci] - i postoji na drugoj strani klijent [koji trazi podatke od servera].

Komunikacija izmedju klijenta i servera se odvija SQL jezikom!
SQL sintaksa je veoma jednostavna, i razumljiva.
Dakle, klijent posalje 'upit' serveru - i server posalje klijentu odgovor - tj. zeljene podatke iz baze.

Evo jednog najprostijeg primera SQL upita [to se takodje zove i SQL query, ili samo query] :




SELECT ime FROM tabela_korisnici WHERE prezime='Stojkovic';

Server ce vratiti podatak klijentu:




Predrag

Tako sve to funkcionise...
Klijent trazi, ili salje, podatke... server obradi zahtev, i posalje odgovor klijentu...

--------

SQL se uglavnom primenjuje u programskim jezicima.
Dakle, program trazi/salje podatke serveru, server obradi zahtev, i vrati rezultat programu.
To je i svrha baza podataka, da brzo i efikasno skladisti podatke i radi sa njima.

U svakom programskom jeziku postoje funkcije/klase/komponente za povezivanje sa SQL bazom.
Ako vam treba pomoc oko povezivanja - napisite ovde u kom programskom jeziku programirate, i koju SQL bazu koristite, pa cemo pokusati da resimo vas problem.

-------

Ja cu da radim po MySQL sintaksi, posto to jedino i poznajem..
SQL sintakse se u principu ne razlikuju mnogo, tako da ce 99% toga raditi na svim SQL bazama.

Ako na svom racunaru nemate ni jednu bazu - instalirajte MySQL [linux korisnici to imaju] - [Link mogu videti samo ulogovani korisnici]
Uputstvo za instalaciju - [Link mogu videti samo ulogovani korisnici]
Bilo je dosta reci o MySQL instalaciji - tako da mozete pogledati ovaj forum [i eventualno PHP forum].
Ako imate problema sa instalacijom, prijavite ih odmah... mada nije neophodno da imate instaliranu bazu... mozete i samo ovako teorijski da ucite, ali je ipak preporucljivo da sve to imate, i sami experimentisete, i sami radite sa bazom podataka [kada dovoljno naucite]...
Pa da posle krenemo sa prvom lekcijom...

-------

O SQL jeziku i sintaksi - u sledecoj lekciji!

--------

Navigation
----------------------------------
prev | next

1. lekcija - kreiranje tabele

1) Organizacija podataka

Baza podataka se sastoji iz [vise] tabela...
Dakle, podaci su u bazi organizovani po tabelama [a jedna baza moze imati mnogo tabela]

Same tabele sadrze podatke... u pitanju su obicne dvodimenzionalne tabele...
Na vrhu su polja [kolone]... (na primer: Ime, Prezime, Godiste...) a na dole se redjaju podaci...

Primer:




tabela1 :


--------------------------------------------


|  Ime       |  Prezime       |  Godiste   |


--------------------------------------------


| Predrag    |  Stojkovic   |  83        |


| Petar      |  Petrovcic     |  84        |


| Jasmina    |  Nikolic       |  80        |


--------------------------------------------

--------------------------------------------------------------

2) Tipovi polja

Polja [kolone] imaju svoj 'tip', tako da se tacno zna koji tip podataka moze da ide u koje polje.
Na primer... u polju 'Godiste' moze da se upise samo broj... ne moze tekst... jer je polje predvidjeno samo za brojcane vrednosti.

Najcesce korisceni tipovi su (MySQL):
INT - za brojeve
REAL - za brojeve sa decimalama
CHAR - za samo jedan karakter
VARCHAR - za vise karaktera (do 255), s tim sto se navede broj karaktera za polje, recimo - VARCHAR(30)
TINYTEXT - za tekst do 256 karaktera
TEXT - za tekst do 65.000 karaktera
BLOB - za 'binarni' sadrzaj [do 65k bajta]...
MEDIUMTEXT, MEDIUMBLOB, BIGTEXT, BIGBLOB - sve isto, samo su polja veca...
DATE - za datume
TIME - za vreme...

Ako bismo hteli da kreiramo onu gore tabelu, iz primera... polja bi bila ovako 'organizovana' :
Ime - bilo bi tipa TINYTEXT, ili eventualno VARCHAR(20) ako bi smo hteli da ustedimo prostor, posto ne postoje imena duza od 20 slova
Prezime - isto kao i za Ime, TINYTEXT, ili VARCHAR(20)
Godiste - tu cemo staviti INT, posto se upisuju samo brojcane vrednosti

Za Access korisnike: umesto INT staviti NUMBER, i umesto TINYTEXT staviti STRING

---------------------------------------------------------------

3) Kreiranje tabele

Kao sto smo rekli u prethodnoj lekciji... sve operacije sa bazom se obavljaju SQL komandama...
Komanda za kreiranje tabele je CREATE TABLE.

SQL query, koji trebamo da posaljemo serveru, da bi kreirali bazu, je :




CREATE TABLE tabela1 (


ime VARCHAR(20),


prezime VARCHAR(20),


godiste INT


);

Server ce naravno poslati odgovor da je tabela "tabela1" uspesno kreirana...

Za one koji zele jos neke sitnice da saznaju (koje vama za sada nisu bitne) :
1) [Link mogu videti samo ulogovani korisnici]
2) [Link mogu videti samo ulogovani korisnici]
3) [Link mogu videti samo ulogovani korisnici]

------------------------------------------------------------

4) Za one kojima je dosadno (i koji trce ispred vremena)

Ovo ispod cemo sve uciti posebno, u sledecim lekcijama...

Tabela se puni na sledeci nacin:




INSERT INTO tabela1 (ime, prezime, godiste) 


VALUES ('Mika', 'Kostic', 80);

Opsirnije: [Link mogu videti samo ulogovani korisnici]

Tabela se cita na sledeci nacin... primeri:




SELECT * FROM tabela1;


SELECT ime FROM tabela1;


SELECT ime, godiste FROM tabela1;


SELECT ime, prezime FROM tabela1;


SELECT ime, prezime FROM tabela1 WHERE godiste>80;

Opsirnije: [Link mogu videti samo ulogovani korisnici]

Napominjem ponovo, ovo su samo primeri, da vam nije dosadno, za one koji zele da pozure sa lekcijama.
Sve cemo ovo posebno objasniti, u sledecim lekcijama.

Navigation
----------------------------------
prev | next

2. lekcija - insert

INSERT je SQL naredba/upit za dodavanje novih zapisa u bazu podataka.
sintaxa INSERT naredbe je sledeca:

INSERT INTO ime_tabele [(spisak_atributa)] VALUES (spisak_vrednosti_atributa);

atribut je ime kolone (u ovoj tabeli, atributi su: ime, prezime i godiste.

INSERT naredba dodaje spisak_vrednosti_atributa u ime_tabele. spisak_atributa je neophodan ako zelite da dodate samo neka polja. ako zelim da dodam samo ime i prezime, ali ne i godiste (pod uslovom da se za polje godiste dozvoljava da bude ne uneseno).
SQL upit:




INSERT INTO tabela1 (ime, prezime) VALUES ('Slobodan','Kasic');

ovaj sql upit ce generisati ovakvu tabelu




tabela1 :


--------------------------------------------


|  Ime       |  Prezime       |  Godiste   |


--------------------------------------------


| Predrag    |  Stojkovic   |  83        |


| Petar      |  Petrovcic     |  84        |


| Jasmina    |  Nikolic       |  80        |


| Slobodan   |  Kasic         |            |


--------------------------------------------

SQL nije casesensitive i nije bitno da li cete napisati InSeRt/INSERT/INSeRt/insert, potpuno je svejedno, ali ja pisem velikim slovima radi preglednosti, nista vise.
za atribute nikada ne stavljajte nesto kao text, string ili neki drugi tip polja, jer moze doci do greske pri izvrsavanju upita. malo je teze pronaci takvu gresku jer se ne nadas da je to problem .ako je tip polja/atributa string/text, u INSERT upitu (a i ostalih upita), morate da stavite ' i ', ako je u pitanju broj, onda je bez '.

Navigation
----------------------------------
prev | next

3. lekcija - select

Select upit sluzi kako bi iz neke tabele 'izvadili' selektovali neki zapis ili vise zapisa po nekom odredjenom

kriterijumu.
sintaxta select upita je sledeca:




SELECT * FROM ime_tabele [WHERE id=13];

znak * znaci da cemo iz tabele ime_tabele da selektujemo sve atribute, a ime_tabele je zapravo ime tabele u kojoj se

nalaze ti selektovani atributi.

ako zelimo da iz tabele selektujemo sve korisnike koji su rodjeni 83 godine upit bi izgledao ovako:




SELECT * FROM tabela1 WHERE Godiste=83;

kao rezultat ovog upita, dobicemo ovakvu tabelu




--------------------------------------------


|  Ime       |  Prezime       |  Godiste   |


--------------------------------------------


| Predrag    |  Stojkovic   |  83        |


--------------------------------------------

ova tabela je virtuelna tabela i nalazi se u memoriji racunara.

bazu cemo azurirati (update jos nismo radili, za dva casa)




UPDATE tabela1 SET Godiste=83 WHERE Prezime='Kasic';

ovaj sql upit ce u vec postojeci zapis, dodati ono prazno poje koje je bilo (Godiste)
cela tabela izgleda ovako:




--------------------------------------------


|  Ime       |  Prezime       |  Godiste   |


--------------------------------------------


| Predrag    |  Stojkovic   |  83        |


| Petar      |  Petrovcic     |  84        |


| Jasmina    |  Nikolic       |  80        |


| Slobodan   |  Kasic         |  83        |


--------------------------------------------

kada se sada izvrsi isti onaj SELECT upit, virtuelna tabela ce biti ovakva:




--------------------------------------------


|  Ime       |  Prezime       |  Godiste   |


--------------------------------------------


| Predrag    |  Stojkovic   |  83        |


| Slobodan   |  Kasic         |  83        |


--------------------------------------------

sa ovakvim rezultatom upita, mozete da radite sta vam je volja. da ga sortirate ili ispisujete negde.

ako zelite da izracunate (izbrojite) koliko zapisa ima u tabeli sledeci sql upit resava to:




SELECT count(*) FROM tabela1;

rezultat upita ce biti broj 4.

postoje i malo komplikovaniji delovi SELECT upita (ugnjezdeni upiti)

hipoteticka situacija:
imate dve tabele. u jednoj spisak CD/DVD, a u drugoj grupa u kojoj isti pripadaju.
tabele ce ovako nekako izgledati:




tabela: cddvd


--------------------------------------------


| Broj       |  Ime           |  Grupa     |


--------------------------------------------


| 1          |  Worms         |  1         |


| 2          |  Flash         |  2         |


| 3          |  Linux         |  3         |


| 4          |  VS.NET        |  4         |


--------------------------------------------




tabela: grupa


-------------------------------


| Broj       |  Ime           |


-------------------------------


| 1          |  Igre          |


| 2          |  Programi      |


| 3          |  OSystems      |


| 4          |  Programiranje |


-------------------------------

ovako realizovana tabela sprecava neke od anomalija (anomalije pri brisanju, dodavanj i azuriranju)

mozgli smo to uraditi i sa jednom tabelom stim sto bi onda u atributu Grupa zapravo bilo ime grupe, ali to nije

dobro. tako se ne radi zbog pomenutih anomalija (o njima kasnije)

ove dve tabele su spojene sa atributima Grupa (iz prve tabele) i Broj (iz druge tabele)




select cddvd.broj,cddvd.ime,grupa.ime from cddvd,grupa where cddvd.broj=grupa.broj;

ovaj sql upit ce vam dati ono sto zelite.
tabela je ovakva




tabela: virtuelana


-----------------------------------------------


| Broj       |  Ime           |  Grupa        |


-----------------------------------------------


| 1          |  Worms         |  Igre         |


| 2          |  Flash         |  Programi     |


| 3          |  Linux         |  OSystems     |


| 4          |  VS.NET        |  Programiranje|


-----------------------------------------------

sve sto vam je potrebno je tu, a jos plus ste izbegli anomalije. malo je sql upit komplikovaniji, ali nije problem.

znaci, ono sto zelite da se prikaze u tabeli, morate navesti posle SELECT-a. kada radite sa dve ili vise tabela,

najbolje je da atribut pisete kao ime_tabele.ime_atributa da ne bi bilo zabune, a i da izbegnete greske, posebno ako

u dve tabele imate isti atribut (kao u mom slucaju Broj).
ovo je nesto sto ja najcesce koristim. ima tu jos ugnjezdenih f-ja. neke ne znam ni sam kako se koriste

npr.




SELECT max(Broj) FROM grupa;

vraca broj 4 posto je on najveci broj u atributu Broj

slucaj sa min(broj), vratice 1, kao najmanji.

Navigation
----------------------------------
prev | next

4. lekcija - Where

Posle malo duze pauze, nastavljam sa zapocetim poslom (za koji, BTW, jos nisam placen ).
Potrudicu se da objasnim sto je moguce bolje.

WHERE je klauzula uslova. Sa WHERE odreduje koje zapise cete brisati, selektovati, azurirati...
Opciona je, ali ako postoji, mora da ide posle FROM some_table naredbe.

Primer 1.0




SELECT * FROM Table1 WHERE id=1;

Ovo prevedeno na obican jezik glasi: Izaberi sva polja iz tabele Table1 gde je id jednako 1.
WHERE mozete da kombinujete sa logickim izrazima tipa AND, OR, NOT.

Primer 1.1 (Selektuje sve zapise iz tabele Table1 gde je id 1 i 4)




SELECT * FROM Table1 WHERE id=1 AND id=4;

Primer 1.1 (Selektuje sve zapise iz tabele Table1 gde je id ili 1 ili 4)




SELECT * FROM Table1 WHERE id=1 OR id=4;

WHERE klauzula moze da sadrzi GROUP BY i ORDER BY klauzule.
GROUP BY ime_atributa za grupisanje po tom atributu

ORDER BY ime_atributa za prikazivanje u opadajucem (DESC) ili rastucem (ASC) redosledu.

WHERE klauzula takodje moze da sadrzi i drugu SELECT klauzulu (ne u MySQLu).
Ono sto je bitno kod ovakvog nacina pisanja SQL upita jeste da u jednom delu SQL upita izjednacite polje sa poljem iz drugog SQL upita (istog tipa) po kojem zelite da povezete te dve tabele.

Primer 1.2




SELECT * FROM Tabela1 WHERE id1=(SELECT id2 FROM Tabela2 WHERE UserName='NekiUser';)

Ovaj SQL upit ne radi nista pametno, ali sam samo hteo da pokazem syntaxu kako se pise.

Isti ovaj rezultat mozete postici na drugi nacin (ako neke baze podataka ne podrzavaju ugnjezdene upite kao mySQL npr.)

Primer 1.3




SELECT * FROM Table1,Table2 WHERE Table1.id1=Table2.id2 AND UserName='NekiUser';

U ovom slucaju morate navesti ime_tabele.ime_atributa kako bi 'rekli' iz koje tabele da uzima podatke. Ovo isto moze i vama pomoci, posebno ako upit ne radi kako treba.
Ako ne zelite da pisete ime_tabele.ime_atributa, onda morate da proverite da ime svakog polja iz obe tabele bude unikatno kako ne bi doslo do gresaka. (Ovo se ne preporucuje)
Rezultat oba ova upita je isti.

Neke baze (MSSQL) kada poredite dva stringa u WHERE klauzuli, 'traze' da umesto = bude klauzula LIKE.

Bilo u slucaju koriscenja ugnjezdenog upita ili SQL upita iz Primera 1.3 kada SQL upit treba da vrati vise zapisa onda se umesto = koristi klauzula IN.
U klauzuli WHERE mozete da kombinujete logicke operacije po ovoj semi:
Argument1 OperatorUporedjivanja Argument2 i tako u nedogled .

WHERE u DELETE

Sama DELETE klauzula ne bi bila ni malo upotrebljiva ako ne bi imali WHERE klauzulu osim u slucaju da zelimo da obrisemo sve zapise iz tabele.
Kada zelite neki odredjeni zapis (ili logicku kombinaciju zapisa) da obrisete iz tabele, u DELETE klauzulu morate da 'ukljucite' WHERE klauzulu.

Primer 1.4




DELETE FROM Table1 WHERE UserName='NekiTamoUser';

Ovaj SQL upit ce obrisati citav jedan zapis iz tabele Table1 gde je atribut UserName = NekiTamoUser.

WHERE u UPDATE

Kao i DELETE, ni UPDATE ne bi bio upotrebljiv bez WHERE, osim ako ne zelimo da jednu promenu preslikamo na sve u tabeli.
Ako zelite da azurirate samo jedan zapis ili logicku kombinaciju vise zapisa koristite WHERE unutar UPDATE klauzule.

Primer 1.5 (Azuriranje zapisa gde je id=14)




UPDATE SET ime_atributa=vrednost_atributa WHERE id=14;

Primer 1.6 (Azuriranje zapisa gde je id=14 i id=10 ukupno dve promene ime_atributa sa vrednost_atributa)




UPDATE SET ime_atributa=vrednost_atributa WHERE id=14 AND id=10;

Mislim da je to sve. Ako sam nesto zaboravio, dopunite me

Navigation
----------------------------------
prev | next

5. lekcija Update

O UPDATEu nema sta puno da se kaze. (bar koliko ja znam ).
UPDATE klauzula sluzi za menjanje vrednosti jednog ili vise zapisa po nekom odredjenom kriterijumu.

Sadrzi WHERE uslov pomocu kojeg se menjaju neki atributi zapisa.




UPDATE tabela SET ime_atributa1=vrednost_atributa1, ime_atributa2=vrednost_atributa2, ime_atributaN=vrednost_atributaN;

Posle spiska atributa cija vrednost treba da se promeni/izmeni, treba da stoji WHERE koji odredjuje koji zapis ce biti UPDATE-ovan.
Ako izostavimo WHERE uslov, svi zapisi u tabeli ce biti isti.




UPDATE tabela SET grupa='industrija koze' WHERE id=14;

Ovaj sql upit ce promeniti vrednost atributa grupa u industrija koze svim zapisima kojima je ID=14.

Navigation
----------------------------------
prev | next

6. lekcija - Delete

Kao i za UPDATE, ni o DELETE nema mnogo stosta da se kaze.
DELETE sluzi za brisanje svih (time se ne brise definicija tabele, nego samo zapisi u njoj) zapisa ili samo selektovanih zapisa pomocu uslova.




DELETE FROM tabela;

Ovaj sql upit brise sve zapise iz tabele.
Da bi ipak obrisali samo zeljeni zapis, treba se dodati uslov WHERE.




DELETE FROM tabela WHERE id=14;

Ovaj sql upit brise sve zapise ciji je ID=14.

Navigation
----------------------------------
prev | Appendix 1

Advanced SQL-ing

Zamislite sledecu situaciju.
Zelite da napravite nesto, da kazemo katalog knjiga (strucna literatura ).
Izmedju ostalog, ta aplikacija treba da sadrzi i ime knjige i grupu u kojoj pripada radi lakseg pronalazenja iste.
Vidjao sam da su neki sve te informacije (ime knjige, grupa, korisnik koji je uzeo knjigu...) dodavali u jednu tabelu. To nije dobro resenje jer se tu javljaju tri osnovne (i jedine) anomalije.

1. Pri dodavanju zapisa
2. Azuriranju zapisa (Update)
3. Brisanju zapisa

Stim sto jos pravite redudantne podatke (bespotrebno ponavljanje zapisa/podataka).

Da obajsnim svaku od anomalija.

1. Anomalija pri dodavanju zapisa:
Uzmimo primer ove nase aplikacije za knjige.
Ako imamo tabelu u kojoj su smesteni korisnici te biblioteke i tabelu u kojoj su smestene knjige.
Radnik koji radi u knjizari, ne moze da doda zapise o nekom korisniku osim ako taj korisnik ne uzme neku knjigu.
Zasto?
Zato sto se to sve nalazi u jednoj tabeli, a zamislite kako bi izgledala ta jedna tabela kada bi pola zapisa bilo prazno i jos bi se i ponavljali neki. Stim sto se pri projektovanju baze, za neka polja stavlja da ne mogu da prime null vrednost. Drugim recima, MORATE da upisete nesto.
Takvo polje bi bilo za ime knjige, grupu. Korisnik koji je uzeo knjigu je opciono.
Kako bi se zapis dodao u bazu, sva tri polja moraju biti popunjena (pored onih ostalih).

Isto to vazi i za knjige. Ne mozemo dodati novu knjigu ako nemamo kome da je iznajmimo.

2. Anomalije pri azuriranju zapisa:
Kada promenimo ime knjige (iz bilo kod razloga) npr. tek posle nekoliko godina smo shvatili da nismo lepo napisali naslov knjige.
Sve te izmene moramo da vrsimo onoliko koliko je neko puta uzimao knjigu sto moze da dovede do greske i samim tim ne validnih podataka.

To isto vazi i za grupe i korisnike......

3. Anomalije pri brisanju zapisa:
Ako nam je neka knjiga slucajno ispala sa mosta i naravno unistena, ljudi u knjizari (pored naplate stete ) moraju i da obrisu knjigu koja je bila prva knjiga u biblioteci staroj nekoliko

vekova .
Da bi obrisali tu knjigu, moraju da brisu onoliko puta koliko je neko iznajmio tu knjigu. Samim tim (brisanjem) gube se informacije o korisnicima koji su uzimali tu knjigu.

Ista stvar je i sa grupama i korisnicima......

'Tri tabele' To the rescue

Ipak, postoji nacin da se resi sve ovo.
U nasem slucaju (knjige, grupe i korisnici) trebamo da napravimo tri tabele.
Jedna tabela za spisak svih knjiga sa svim njenim informacijama (sta god vam padne na pamet).
Tabela sa spiskom svih mogucih grupa (beletristika, kompjuteri, kompjuterska filozofija ...)
I tabela sa spiskom korisnika koji bi trebalo da uzimaju te knjige sa svim njihovim informacijama.
Kontrolni broj, broj dece...

U tabeli za knjige treba da se dodaju jos dva atributa (pored onih sa informacijama za knjige) za grupe i korisnike preko kojih ce se tabela knjige povezivati sa abelom grupe i tabelom

korisnici.

Sve tri tabele imaju atribut ID koji je primarni kljuc. Ime knjige je obavezno polje (ono not null) kao i grupaID dok je korisnikID opciono.




knjige


+----------------------------------------------------------+


|  id  |  ime knjige          |  grupaID    |  korisnikID  |


+----------------------------------------------------------+


|  01  |  kompjuterska fil.   |  01         |              |


|  02  |  tom sojer           |  02         |              |


|  03  |  dig. integr. el.    |  03         |              |


+----------------------------------------------------------+




grupe


+-----------------------------+


|  id  |  ime grupe           |


+-----------------------------+


|  01  |  kompjuteri          |


|  02  |  lektira             |


|  03  |  elektronika         |


+-----------------------------+




korisnici


+----------------------------+


|  id  |  ime korisnika      |


+----------------------------+


|  01  |  Mika               |


|  02  |  Pera               |


|  03  |  Sima               |


+----------------------------+

Tabele izgledaju ovako.
Kada zelimo da dodamo novog korisnika, Sve njegove informacije dodajemo u tabelu korisnici.
Kada zelimo da dodamo grupu, sve informacije o grupi dodajemo u tabelu grupe.
Isto tako i za knjige.

Kada dodje neki korisnik (Mika npr.) i zeli da uzme knjigu 'kompjuterska filozofija', operater zapisuje te podatke u tabelu knjige i to za tu knjigu koju je taj korisnik uzeo.

Tabela izgleda ovako:




knjige


+-------------------------------------------------------+


|  id  |  ime knjige         |  grupaID  |  korisnikID  |


+-------------------------------------------------------+


|  01  |  kompjuterska fil.  |  01       |  01          |


|  02  |  tom sojer          |  02       |              |


|  03  |  dig. integr. el.   |  03       |              |


+-------------------------------------------------------+

Vidimo da je Mika povezan sa knjigom koju je uzeo preko njegovog ID (iz tabele korisnici) i ID iz tabele knjige tako da se zna ko je uzeo koju knjigu.

Kad bi ovo trebali da ispisemo, dobili bismo ne bas razumne podatke (mislim ovo, 01, 03, 10003, 383....).
Za ispisivanje pravih podataka, treba nam malo komplikovaniji SQL upit, ali radi posao.

Teorijski opis SQL upita:
SQL upit treba da selektuje sve iz tabele knjige gde je grupaID=ID id tabele grupe I gde je korisnikID=ID iz tabele korisnici.

Prakticni opis SQL upita:




SELECT * FROM knjige,grupe,korisnici WHERE knjige.grupaID=grupe.ID AND knjige.korisniciID=korisnici.ID;

Posle ovog SQL upita, normalno mozemo da pristupamo poljima i da ih ispisujemo gde treba.
Ako niko nije uzeo ni jednu knjigu, SQL upit nece vratiti ni jedan zapis.

To bi bilo to. Za sada. Ako imate nekih pitanja, slobodno pitajte.

Izvinjavam se zbog neurednosti tabela. Primetio sam tek kada sam postovao ovde, a sada me mrzi da ih ispravljam .
Update: Sredio sam tabele .

Navigation
----------------------------------
prev | ...

Izasao MySQL 5!

nobody@mycity.rs (Peca) — Sun, 06 Nov 2005 19:18:35 +0100

Glavne novine u novoj verziji ove popularne baze podataka su:
Stored procedures - napravite svoje funkcije [konacno!!!]
Triggers - mozete napraviti 'Event' kada se nesto desi [recimo kada se insertuje nesto u tabelu, npr. kad je Godiste<83 da se izvrsi neki event]
Views - kreirate 'prividnu' tabelu koja pokazuje ono sto zelite iz drugih tabela

Zaista impresivno...

[Link mogu videti samo ulogovani korisnici]

MySQL 5.0 is the most ambitious release in MySQL's history. MySQL 5.0 delivers the enterprise features the community has been asking for, including Stored Procedures, Triggers, Views, Information Schema, XA Distributed Transactions, and new Storage Engines. We also added Strict SQL Mode to eliminate some of the �Gotchas�. Plus, MySQL 5.0 builds on our reputation for Reliability, Performance, and Ease of Use.

inace, ugnjezdeni upiti postoje od verzije 4.1
i to veoma mocno odradjeni - [Link mogu videti samo ulogovani korisnici]

sta da kazem, mysql je postao ozbiljna baza podataka...

Index SQL lekcija

nobody@mycity.rs (snoop) — Thu, 14 Apr 2005 00:09:31 +0100

SQL quiz

nobody@mycity.rs (snoop) — Sun, 27 Mar 2005 17:21:29 +0100

ako zelite da radite kviz iz SQL-a... i ovde su, kao i za ASP, pitanja elementarne prirode tako da sam i ovde zavrsio kviz sa 100% ucinkom...

mozete da radite kviz onako 'na suvo' pa posle kada odradimo sve sto je Peca rekao da treba, da probate ponovo i vidite razliku u naucenom znanju...
imate i na doticnom sajtu tutotijale za SQL pa mozete i odatle uciti... kako god zelite

[Link mogu videti samo ulogovani korisnici]

Instalacija PostgreeSQL na Windows-u

nobody@mycity.rs (bobby) — Fri, 03 Dec 2004 04:32:37 +0100

PostgreeSQL za Windows se moze naci u dve varijante: kao native Windows verzija i kao Cygwin verzija. Za one koji neznaju, Cygwin je emulation layer koji emulira POSIX na Windows-u, sto omogucuje lakse prevodjenje i kompajliranje Linux programa na Windowsu.

Native verzija PostgreeSQL-a zahteva instalaciju na NTFS particiji i trenutno logovani user ne sme imati administratorska prava ukoliko se zeli pokrenuti servis.
Cygwin verzija je malo teza za instalaciju, ali je nama vise odgovarala jer smo svi iz tima u kome radim koristili admin prava na svojim racunarima i nije nam nikako odgovaralo bilo sta drugcije.

Instalacija Cygwin verzije PostgreeSQL-a:

Skinuti Cygwin setup fajl sa [Link mogu videti samo ulogovani korisnici]
Odaberite najblizi server i predjite na ekran sa selekcijom paketa. Ovde se obicno svako zbuni: "koji su paketi potrebni?"
BASE paket je obavezan. Pod DATABASE stiklirati PostgreeSQL za instalaciju (moja preporuka je da ne odaberete 8.0 verziju, verzije se biraju tako sto vise puta kliknete na fajl u instaleru). Instaler bi trebao da sam odabere sve ostale potrebne fajlove, medjutim desilo mi se da mi je naknadno bio potreban i paket DEVEL>pcre, tako da i njega selektujte.
Kako skinuti samo potrebne fajlove (kako ne skidati suvisne fajlove):
moj recept bi bio: prvo deselektuj sve, pa selektuj BASE, postgree, pcre i skroz dole postinstall.
Sledeci korak je skidanje fajlova sa interneta i instalacija.
Nakon zavrsetka instalacije potrebno je podesiti sistemske varijable.
Udjite u ControlPanel>System>Advanced>Environment Variables
Pod System Variables pronadjite varijablu PATH i kliknite dugme edit.
Na kraju dodajte (nemojte slucajno obrisati postojece vrednosti, vec je potrebno DODATI) sledece: ";c:\cygwin\bin\;c:\cygwin\usr\sbin" (bez navodnika). Vrednosti su date za default cygwin folder, ukoliko je kod vas putanja drugcija - podesite vrednosti u gornjem izrazu.
Potrebno je napraviti i jednu novu varijablu. Kliknite dugme NEW, ime varijable je: CYGWIN , vrednost: server.
Sada je potrebno restartovati racunar.
Nakon restarta pokrenite Cygwin shell (crno-zelena ikonica).
U shellu kucajte sledece:




cygserver-config                     - ovo ce pri sledecem restartu startovati cygserver koji ce opsluzivati bazu


mkdir /var/pgsql                     - napravimo folder za bazu


mkdir /var/pgsql/data              - napravimo folder za podatke


initdb -D /var/pgsql/data          - inicijalizujmo bazu

Sledi restart. Nakon restarta cemo imati startovan cygserver pa mozemo da startujemo servis. Ulazimo ponovo u cygwin shell i kucamo:
postmaster -D /var/pgsql/data �i &
Time se zavrsava moje kratko upustvo o instaliranju PostgreeSQL-a.
Jedina mana ovog nacina je sto se posle svakog restarta mora startovati servis postmaster komandom kao gore, i jos to da se cygwin shell ne sme zatvarati jer to prekida i servis. Ovo nije veliki problem ukoliko imate poseban racunar koji sluzi samo kao server za bazu i koji se ne restartuje cesto.

EDIT: Zaboravio sam da vam eventualno (ukoliko nemate instalirano) moze zatrebati i sledece:
[Link mogu videti samo ulogovani korisnici] - ODBC drajver
[Link mogu videti samo ulogovani korisnici] - MDAC (meni na XP SP2 nije bio potreban_
[Link mogu videti samo ulogovani korisnici] - ODBC za .NET framework