Relacyjne簔y趎ych to nic strasznego


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, ora
z adresy.

0x01 graphic



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 ta
bela 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.



Wyszukiwarka

Podobne podstrony:
Christie Agatha Morderstwo to nic trudnego
To nic, PIOSENKI DLA GIMNAZJUM
Christie Agatha Morderstwo to nic trudnego
To by艂o strasze
Dokument,Krzysztof Jackowski o roku 2012 鈥 to b臋dzie straszny rok!
Manipulacje polskich aborcjonist贸w to nic nowego
To nic kiedy p艂yn膮 艂zy Sasha Strunin
Sasha Strunin To nic, kiedy p艂yn膮 艂zy
Christie Agatha Nadinspektor Battle 04 Morderstwo to nic trudnego
1939 Morderstwo to nic trudnego
Christie Agatha Morderstwo to nic trudnego
Morderstwo to nic trudnego

wi臋cej podobnych podstron