Zastosowanie tabel słownikowych

Witam!
Jestem osobą początkującą w tej dziedzinie, dlatego chciałbym prosić was o pomoc w wyjaśnieniu kilku kwestii. Mianowicie jakie jest zastosowanie i kiedy używać tabel słownikowych, czy tabele te biorą udział w relacjach pomiędzy innymi tabelami?
pozdrawiam

Wyobraź sobie że przechowujesz w bazie adresy klientów i masz tam miasto i nazwę ulicy. Jeśli nie masz miasta i ulicy w słowniku to może się okazać że u jednego klienta będzie to napisane z dużej litery, u drugiego z małej, u jednego bez polsków znaków u innego ze znakami itd. W efekcie w bazie jedna i ta sama ulica będzie wpisana na 20 różnych sposobów. Teraz wyobraź sobie że nazwa ulicy się zmieniła. Klientów masz milion.
Pytanie: ile czasu zajmie ci zmiana w bazie tych wszystkich adresów na poprawne (tzn podmiana starej nazwy ulicy na nową)?
A teraz ile czasu by to zajęło gdyby Klient w bazie miał tylko ID ze słownika gdzie byłoby miasto i ulica? Otóż w tym przypadku zmodyfikowałbyś jedynie wpis w słowniku ze starej nazy ulicy na nową.

Dziękuje za odpowiedź, super przykład :) pozdrawiam

Piękny przykład na znormalizowaną bazę danych, tylko zupełnie nieprzydatny w przypadku realnego systemu. Po co przechowywać ulicę w osobnej tabeli? Żeby to łączyć z tabela słownikową przy każdym wyświetleniu? I analogicznie w przypadku miejscowości, kodu pocztowego nr domu itd.? Bo przecież wszystkie w/w informacje mogą się powtórzyć. Oczywiście można w bazie trzymać całą bazę danych terytorialnych (a więc powiązania województwo->Powiat->Gmina->Kod pocztowy->Miejscowość->Ulica->Nr domu/mieszkania), tyle że przy większości zastosowań ilość danych na bazę terytorialną przekroczy rozmiar danych biznesowych.
Jest sens? Moim zdaniem nie bardzo... No chyba, że klientów faktycznie będzie zylion - to wtedy tak. Tyle, zę wtedy cały taki system ciut inaczej się projektuje.
A i tak uważam, że lepszym pomysłem jest już dedykowana usługa (np. REST), która serwuje tego typu informacje dla aplikacji. No, ale do tego trzeba mieć jakiś serwer ogólnie dostępny itd.

Tabel słownikowych używam do takich rzeczy jak;

1. Statusu dokumentów
2. Rodzaje/typy obiektów, które służą do segmentacji danych (typ towaru - produkt, opakowanie, usługa, itd.).
3. I wszystkie podobne byty jak wyżej...
   Nie traktuję jako słownik takich danych jak dane adresowe, kategorie kontrahenta/towaru, itd. Ogólnie rzecz biorąc - dane, które są niezbędne z punktu widzenia logiki aplikacji to jest słownik. Dane, którymi w całości zarządza użytkownik i które nie są bezpośrednio odwzorowane w logice programu - to nie jest słownik w moim rozumieniu.

Czy tabele słownikowe powinny brać udział w relacjach? Moim zdaniem nie powinny, bo to tylko niepotrzebny narzut na bazę. Zauważ, że pozycji w słowniku (takim słowniku, jak go opisałem czym jest) jest raptem kilka (no może kilkanaście) a więc selektywność takich danych w kolumnie konkretnej tabeli też jest niska. A niska selektywność stawia pod znakiem zapytania sens zakładania indeksu na takiej kolumnie.
Całym słownikiem (u mnie) zarządza aplikacja, a sama tabela słownikowa z punktu widzenia bazy danych, jest tylko składowiskiem danych dla słowników bez żadnej logiki i relacji z pozostałymi tabelami.

wloochacz napisał(a):

(..)
Całym słownikiem (u mnie) zarządza aplikacja, a sama tabela słownikowa z punktu widzenia bazy danych, jest tylko składowiskiem danych dla słowników bez żadnej logiki i relacji z pozostałymi tabelami.

Kompletnie, całkowicie "luźna" tabela, bez żadnego powiązania? Dopuszczasz (przykładowo), że błąd w aplikacji spowoduje wpisanie do jakiejś tabeli nieistniejącego w tabeli słownikowej ID?

wloochacz napisał(a):

Piękny przykład na znormalizowaną bazę danych, tylko zupełnie nieprzydatny w przypadku realnego systemu. Po co przechowywać ulicę w osobnej tabeli? Żeby to łączyć z tabela słownikową przy każdym wyświetleniu? I analogicznie w przypadku miejscowości, kodu pocztowego nr domu itd.? Bo przecież wszystkie w/w informacje mogą się powtórzyć. Oczywiście można w bazie trzymać całą bazę danych terytorialnych (a więc powiązania województwo->Powiat->Gmina->Kod pocztowy->Miejscowość->Ulica->Nr domu/mieszkania), tyle że przy większości zastosowań ilość danych na bazę terytorialną przekroczy rozmiar danych biznesowych.
Jest sens? Moim zdaniem nie bardzo...

Masz ograniczone spojrzenie do tego co robiłeś i mylisz się bardzo. Serwis REST fajnie, ale skąd ten serwis ma brać dane? Przeszukiwanie plików xml? Słabe. Poza tym przy masowym wprowadzaniu danych, wpisuje się kod pocztowy i dane adresowe muszą się pokazywać w przeciągu sekundy. Kolejny przykład, to gdy musisz przeprowadzać analizy na podstawie danych lokalizacyjnych i nie masz kodu pocztowego. To czy jest sens czy nie zależy od danego systemu

fourfour napisał(a):

wloochacz napisał(a):

(..)
Całym słownikiem (u mnie) zarządza aplikacja, a sama tabela słownikowa z punktu widzenia bazy danych, jest tylko składowiskiem danych dla słowników bez żadnej logiki i relacji z pozostałymi tabelami.

Kompletnie, całkowicie "luźna" tabela, bez żadnego powiązania?

Tak, całkowicie luźna.

Dopuszczasz (przykładowo), że błąd w aplikacji spowoduje wpisanie do jakiejś tabeli nieistniejącego w tabeli słownikowej ID?

I tak i nie; po prostu nie posługuje się ID z tabeli słownikowej, tylko wartością słownika - można rzec, wartością typu wyliczeniowego dla konkretnego słownika.

Sarrus napisał(a):

wloochacz napisał(a):

Piękny przykład na znormalizowaną bazę danych, tylko zupełnie nieprzydatny w przypadku realnego systemu. Po co przechowywać ulicę w osobnej tabeli? Żeby to łączyć z tabela słownikową przy każdym wyświetleniu? I analogicznie w przypadku miejscowości, kodu pocztowego nr domu itd.? Bo przecież wszystkie w/w informacje mogą się powtórzyć. Oczywiście można w bazie trzymać całą bazę danych terytorialnych (a więc powiązania województwo->Powiat->Gmina->Kod pocztowy->Miejscowość->Ulica->Nr domu/mieszkania), tyle że przy większości zastosowań ilość danych na bazę terytorialną przekroczy rozmiar danych biznesowych.
Jest sens? Moim zdaniem nie bardzo...

Masz ograniczone spojrzenie do tego co robiłeś i mylisz się bardzo.

W którym miejscu mam ograniczone spojrzenie i bardzo się mylę?

Serwis REST fajnie, ale skąd ten serwis ma brać dane? Przeszukiwanie plików xml? Słabe.

W tej chwili, to nieistotne skąd ma pobierać dane. Istotne, że ma serwować dane.
Czy XML jest słaby? Zależy jak się go używa (i za pomocą czego - nie uważam, żeby np. Terradata była słaba) i do czego - nie zawsze jest słaby. Ale powiedzmy, że bazą danych dla takiej usługi może być np. SQLite. Lepiej?

Poza tym przy masowym wprowadzaniu danych, wpisuje się kod pocztowy i dane adresowe muszą się pokazywać w przeciągu sekundy.

Przy masowaym wprowadzaniu danych nic się nikomu nie pokazuje, bo przecież aplikacja działa w trybie wsadowym - prawda?
Dwa - w takim przypadku używam dynamicznego keszowania takiego słownika, ale to naprawdę nie ten temat...

Kolejny przykład, to gdy musisz przeprowadzać analizy na podstawie danych lokalizacyjnych i nie masz kodu pocztowego. To czy jest sens czy nie zależy od danego systemu

I dokładnie to napisałem, a więc nie ma jednego złotego środka na wszystko.

wloochacz napisał(a):

Masz ograniczone spojrzenie do tego co robiłeś i mylisz się bardzo.

W którym miejscu mam ograniczone spojrzenie i bardzo się mylę?
Chodziło mi o to, że są przypadki gdzie sens jest.

Serwis REST fajnie, ale skąd ten serwis ma brać dane? Przeszukiwanie plików xml? Słabe.

W tej chwili, to nieistotne skąd ma pobierać dane. Istotne, że ma serwować dane.
Czy XML jest słaby? Zależy jak się go używa (i za pomocą czego - nie uważam, żeby np. Terradata była słaba) i do czego - nie zawsze jest słaby. Ale powiedzmy, że bazą danych dla takiej usługi może być np. SQLite. Lepiej?
Zjadłem snickersa - lepiej ;)

Poza tym przy masowym wprowadzaniu danych, wpisuje się kod pocztowy i dane adresowe muszą się pokazywać w przeciągu sekundy.
Przy masowaym wprowadzaniu danych nic się nikomu nie pokazuje, bo przecież aplikacja działa w trybie wsadowym - prawda?
Chodziło mi o takie systemy, gdzie siedzi ileś klepaczy i wklepuje dane z kuponów w tempie 100 na godzinę.

Kolejny przykład, to gdy musisz przeprowadzać analizy na podstawie danych lokalizacyjnych i nie masz kodu pocztowego. To czy jest sens czy nie zależy od danego systemu

I dokładnie to napisałem, a więc nie ma jednego złotego środka na wszystko.

Nie zauważyłem tego, ale cieszę się że się jednak zgadzamy :)

Sarrus napisał(a):

wloochacz napisał(a):

Masz ograniczone spojrzenie do tego co robiłeś i mylisz się bardzo.

W którym miejscu mam ograniczone spojrzenie i bardzo się mylę?
Chodziło mi o to, że są przypadki gdzie sens jest.

Zauważ, że opisałem jak ja rozumiem słownik i dlaczego w moim rozumieniu słownika nie ma to sensu.

Serwis REST fajnie, ale skąd ten serwis ma brać dane? Przeszukiwanie plików xml? Słabe.

W tej chwili, to nieistotne skąd ma pobierać dane. Istotne, że ma serwować dane.
Czy XML jest słaby? Zależy jak się go używa (i za pomocą czego - nie uważam, żeby np. Terradata była słaba) i do czego - nie zawsze jest słaby. Ale powiedzmy, że bazą danych dla takiej usługi może być np. SQLite. Lepiej?
Zjadłem snickersa - lepiej ;)

Poza tym przy masowym wprowadzaniu danych, wpisuje się kod pocztowy i dane adresowe muszą się pokazywać w przeciągu sekundy.
Przy masowaym wprowadzaniu danych nic się nikomu nie pokazuje, bo przecież aplikacja działa w trybie wsadowym - prawda?
Chodziło mi o takie systemy, gdzie siedzi ileś klepaczy i wklepuje dane z kuponów w tempie 100 na godzinę.

Ale to nie jest masowe wprowadzanie danych, tylko po prostu wprowadzanie danych przez użytkowników za pomocą interfejsu aplikacji. Taka normalna praca z programem...

Kolejny przykład, to gdy musisz przeprowadzać analizy na podstawie danych lokalizacyjnych i nie masz kodu pocztowego. To czy jest sens czy nie zależy od danego systemu

I dokładnie to napisałem, a więc nie ma jednego złotego środka na wszystko.

Nie zauważyłem tego, ale cieszę się że się jednak zgadzamy :)

Żeby była jasność - uważam, że nie zawsze najlepszym rozwiązaniem w realnym systemie jest normalizaja bazy danych, czy tez twarde trzymanie się np. trzeciej postaci normalnej w każdym przypadku.

wloochacz napisał(a):

Piękny przykład na znormalizowaną bazę danych, tylko zupełnie nieprzydatny w przypadku realnego systemu.

W której szkole tak powiedzieli?

Po co przechowywać ulicę w osobnej tabeli? Żeby to łączyć z tabela słownikową przy każdym wyświetleniu? I analogicznie w przypadku miejscowości, kodu pocztowego nr domu itd.?

Żeby mieć realne dane. Niektórzy ludzie lubią mieć w swoich bazach wartości rzeczywiste, a nie losowe.

wloochacz napisał(a):

Oczywiście można w bazie trzymać całą bazę danych terytorialnych (a więc powiązania województwo->Powiat->Gmina->Kod pocztowy->Miejscowość->Ulica->Nr domu/mieszkania)

Kod pocztowy wiąże się z ulicą, a nie z miejscowością. Hierarchię struktury administracyjnej można trzymać w jednej tabeli, kody pocztowe oraz ulice w drugiej.

tyle że przy większości zastosowań ilość danych na bazę terytorialną przekroczy rozmiar danych biznesowych.

No i? Cała Polska to chyba i tak mniej niż 50 MB.

Tabel słownikowych używam do takich rzeczy jak;

Statusu dokumentów
Rodzaje/typy obiektów, które służą do segmentacji danych (typ towaru - produkt, opakowanie, usługa, itd.).
I wszystkie podobne byty jak wyżej...

Nie traktuję jako słownik takich danych jak dane adresowe, kategorie kontrahenta/towaru, itd. Ogólnie rzecz biorąc - dane, które są niezbędne z punktu widzenia logiki aplikacji to jest słownik. Dane, którymi w całości zarządza użytkownik i które nie są bezpośrednio odwzorowane w logice programu - to nie jest słownik w moim rozumieniu.

Słownik to dane populowane, które są niezmieniane przez użytkownika. Pod tę definicję podchodzą zarówno rzeczy, które wymieniłeś, jak i dane adresowe.

Czy tabele słownikowe powinny brać udział w relacjach?

Tabele nie biorą udziału w relacjach tylko nimi są.

Moim zdaniem nie powinny, bo to tylko niepotrzebny narzut na bazę.

Napisał człowiek, który chce dane adresowe zwracać z usługi restowej zamiast lokalnej bazy danych.

Całym słownikiem (u mnie) zarządza aplikacja, a sama tabela słownikowa z punktu widzenia bazy danych, jest tylko składowiskiem danych dla słowników bez żadnej logiki i relacji z pozostałymi tabelami.

Tja, właśnie poprawiam aplikację ludzi o takim podejściu. No bo po co komu integralność referencyjna, przecież to tylko debilny narzut na wydajność. A, że potem pojawią się jakieś rekordy-widmo, to przecież żaden problem, bo autora przecież wtedy już nie będzie przy swoim genialnym wytworze.

Wyobraź sobie, że ludzie często nie są aż tacy głupi, żeby chcieć wprowadzać niepoprawne dane do aplikacji, co dotyczy także nieistniejących miast, ulic i kodów pocztowych. Umieszczenie w aplikacji realnej bazy danych terytorialnych, znacząco im to ułatwia. Zwłaszcza, jeśli aplikacja posiada też funkcję podpowiadania i wyszukiwania.
Jeśli danych biznesowych ma być mniej niż adresowych, to nie ma się co przejmować narzutem na złączenia. Bez sensu jest optymalizować problemy wydajnościowe, których nie ma i przy naszych założeniach nie będzie.
A jeśli zakładamy lub stwierdzimy w rzeczywistym przypadku, że są, to zawsze można odkładać kopię danych adresowych w tabeli biznesowej albo użyć widoków zmaterializowanych. Tylko to nie znaczy, że nie ma sensu od początku trzymać sensownej struktury słownika adresów w bazie.

Jak by ktoś był ciekaw jak wygląda spis terytorialny udostępniony przez gus: http://www.stat.gov.pl/broker/access/index.jspa
Ale niestety nie ma integracji danych z kodami pocztowymi, które można kupić od poczty polskiej ale nie są do końca zgodne z TERYT'em . ;)

Piękny przykład na znormalizowaną bazę danych, tylko zupełnie nieprzydatny w przypadku realnego systemu.

A co masz pod haslem realny system. Chciał bym ja zobaczyc jak system zarządzania NFZ, czy Policją, czy Google byl bez słownioków. Ty sobie wyobrażasz jak baza by zaczęła puchnąć po 2 miesiącach musieli by kupowac nowe dyski zeby dane zbierać.