Bazy danych - tabele z danymi adresowymi
Dawno, dawno temu, gdy zaczynałem zabawę z programowaniem, jeden trochę starszy znajomy z jakimś już tam doświadczeniem w informatyce powiedział mi, żebym podczas nauki zwrócił uwagę na bazy danych, bo niezależnie, czy będę programował gry, programy użytkowe, czy programy dla firm, większość z nich będzie obsługiwała jakieś bazy z danymi. Niekoniecznie będą to bazy SQL (wówczas niezbyt popularne przynajmniej w Polsce), ale jakieś bazy to będą. W sumie programowanie to przede wszystkim przetwarzanie danych i sygnałów. I jakby nie patrzeć - miał rację.Dziś postanowiłem pobawić się w projektowanie prostej bazy przechowującej informacje o ludziach i ich adresach.
W swoim programistycznym życiu widziałem wiele takich danych, jedne lepiej, inne gorzej przystosowane do tego jak ich używano. Bo w samych bazach danych, to jak to w życiu, który projekt przechowywania danych jest lepszy - to zależy od zastosowania. Dlatego pokażę jak etapami zmieniam projekt tabel, bo moje wymagania się zmieniają.
Przedstawmy problem: potrzebujemy bazy, w której będziemy przechowywali podstawowe dane ludzi i ich adresy - na początku ogólnie. Najprostsze rozwiązanie to po prostu mieć jedną tabelę, w której będziemy te dane gromadzić (rysunek 1).
Zapamiętamy w każdym rekordzie imię, nazwisko, jakiś numer identyfikacyjny (bo zawsze może nam się przydać), adres itp.
Ok nie jest źle. Rozwiązanie proste, czytelne, dane spójne. Ale idźmy dalej. Powiedzmy, że nie wszyscy posiadają tylko 1 adres. Powiedzmy, że mieszkają w jednym miejscu, ale korespondencje chcą by kierować gdzie indziej (powodów może być wiele). Pierwsza myśl, klonujemy pola adresowe w tabeli i gotowe (rysunek 2).
Ale już sam pomysł klonowania pól purystów przyprawia o dreszcze. Dlatego, gdy pojawia nam się w programowaniu pomysł by zrobić copy/paste, to bardziej doświadczonym programistom przychodzi zazwyczaj do głowy, że ten fragment należałoby jednak przekształcić. W sumie można. Rozwiązanie z 2 tabelami, gdzie osobno trzymamy adresy i osobno trzymamy podstawowe informacje o ludziach (rysunek 3).
Doszło nam pole z informacją o typie adresu, żebyśmy mogli sobie wyróżnić, czy jest to miejsce zamieszkania, adres korespondencyjny, czy jeszcze jakiś inny.
Niektórzy ludzie lubią się przeprowadzać. Inni mieszkają przez jakiś czas pod tym samym adresem. Może więc oddzielić sam adres, który jest miejscem na mapie od człowieka w osobnej tabeli. W sumie, czemu nie (rysunek 4)!
Doszła nam tabela wiążąca miejsce z człowiekiem i jak się przeprowadza, to wystarczy tylko zmienić wpis w tabeli roboczej (jeśli już jakiś adres mamy w bazie).
No ale po co się ograniczać. Pomyślmy, że z programu mamy tworzyć jakieś dokumenty. No ok, raport pobiera nam dane i drukujemy. Ale co jeśli zginął nam wydruk i chcemy go odtworzyć z danymi, które były w owym czasie aktualne (np. sprawdzić, czy list wysłany był na właściwy adres korespondencyjny). Da się zrobić (rysunek 5).
Do tabeli z danymi łączącymi adres z osobą dodajmy informacje: od kiedy adres dany jest aktualny i do kiedy.
Da się oczywiście jeszcze bardziej urozmaicić tak prostą, zdawałoby się, operację jak przechowywanie danych o osobach i ich adresach. Który sposób jest lepszy? W zasadzie zależy do czego nam jest on potrzebny. Pomijając rysunek 2 (ze względów estetycznych oraz faktu, że jeśli któryś typ adresu będzie występował sporadycznie - spowoduje, ze będziemy mieli w pamięci bazy wiele pól nadmiarowych pustych), każda postać w pewnych zastosowaniach może być lepsza od pozostałych.
Zapewne wymyślicie jeszcze wiele innych postaci wygodnych w konkretnych zastosowaniach. Ale to już pozostawiam Państwu.
Kaczuś
bazy danych programowanie projektowanie