Relacyjne bazy danych to nic strasznego!!!
autor:Roman Korczy艅ski
Kiepsko zaprojektowana baza danych to najcz臋艣ciej spotykany b艂膮d programist贸w, kt贸rzy dopiero zaczynaj膮 swoj膮 przygod臋 z 艂膮czeniem PHP i MySQL. W poni偶szym artykule przedstawi臋 bardzo prosty przyk艂ad relacji, oraz korzy艣ci jakie p艂yn膮 ze stosowania relayjnego modelu bazy.
C贸偶 to takiego s膮 te relacje. Ot贸偶 w kilki s艂owach (a nie chc臋 si臋 na ten temat rozpisywac) s膮 to po艂膮czenia pomi臋dzy tabelami bazy oparte o unikatowy klucz. Po艂膮czenie takie (relacja) pozwala zatem odwo艂ac si臋 zapytaniem SQL do p贸l dw贸ch r贸偶nych tabel w oparciu o klucze. Aby bardziej zobrazowac t膮 ci臋偶k膮 do zrozumienia kwesti臋 poni偶ej przedstawiam model relacyjny bazy sk艂adaj膮cej si臋 jedynie z dw贸ch tabel: klienci, oraz adresy.
Tak wygl膮da sk艂adnia SQL tworz膮ca obie tabele. Dodanie do nich przyk艂adowych danych pozostawiam Tobie:
CREATE TABLE `klienci` (`id` INT (3) UNSIGNED DEFAULT '0' NOT NULL AUTO_INCREMENT, `imie` CHAR (12) DEFAULT '0', `nazwisko` CHAR (25) DEFAULT '0', `e-mail` CHAR (25) DEFAULT '0', PRIMARY KEY(`id`), UNIQUE(`id`), INDEX(`id`))
CREATE TABLE `adresy` (`id` INT (3) UNSIGNED DEFAULT '0' NOT NULL AUTO_INCREMENT, `ulica` CHAR (30) DEFAULT '0', `miejscowosc` CHAR (30) DEFAULT '0', `kod` CHAR (6) DEFAULT '0', PRIMARY KEY(`id`), UNIQUE(`id`), INDEX(`id`))
Najistotniejsze pola w tych tabelach to pola "id" b臋d膮ce kluczami. Poni偶ej w艂a艣ciwo艣ci klucza, kt贸re uzna艂em za niezb臋dne:
飩 `id` INT (3) ca艂kowity
飩 NOT NULL nie brzybieraj膮cy warto艣ci pustej
飩 AUTO_INCREMENT samo zwi臋kszaj膮cy
飩 PRIMARY KEY(`id`) kluczowy
飩 UNIQUE(`id`) unikalny
飩 INDEX(`id`) indeksowalny
Przy nie stosowaniu relacji nasza jedna tabela zawiera艂aby pola :imie, nazwisko, email, ulica, miejscowosc i kod. Jest to co prawda prostsze rozwi膮zanie i z powodzeniem stosuje si臋 gdy mamy do czynienia z niewielk膮 baz膮. Dobrym nawykiem jest jednak stosowac relacje jako metod臋 optymalizacji bazy. I tak przyk艂adowa relacja pomi臋dzy kluczami id tabel : klienci i adresy pozwala na odwo艂anie si臋 jednym zapytaniem SQL do p贸l obu tabel. 艁atwo sobie wyobrazic co dzieje si臋 gdy mamy baz臋 np. towar贸w, z kt贸rych ka偶da grupa towar贸w ma osobne w艂a艣ciwo艣ci. Powstaje tabela o bardzo wielu polach, lub odwo艂ywanie si臋 do tabel w艂a艣ciwo艣ci jest bardzo k艂opotliwe. Kiedy do艂o偶ymny do tego wi臋cej ni偶 100000 rekord贸w to system zaczyna nabierac na wadze i traci efektywno艣c.
Sk艂adnia SQL zapytania SELECT dla tabel po艂膮czonych relacj膮 wygl膮da nast臋puj膮co:
$zapytanie = "SELECT * from klienci INNER JOIN adresy ON klienci.id=adresy.id";
$wykonaj = mysql_query ($zapytanie);
if (!$wykonaj)
{
echo "
B艂膮d zapytania->$zapytanie";}
else
{
$wiersz = mysql_fetch_array($wykonaj);
echo $wiersz[imie];
echo $wiersz[miejscowosc];
}
Po wi臋cej informacji odsy艂am do manuala MySQL , gdzie opisane s膮 dok艂adnie relacje left join, right join, use index itd.
Mam tylko nadziej臋, 偶e relacje nie s膮 ju偶 dla Ciebie czarn膮 magi膮. Nale偶y jednak pami臋tac o normalizacji bazy danych. Usuni臋cie rekordu z tabeli klienci musi byc powi膮zane z usuni臋ciem odpowiadaj膮cego rekordu w tabeli adresy. Taka sama sytuacja ma miejsce w przypadku modyfikacji danych.