Liczba słowników w bazie danych i nazewnictwo tabel

Co to słownik każdy wie, więc chyba nie trzeba tłumaczyć. Pytanie moje - ile ich powinno być? Trochę mnie wkurza, gdy w systemie jest np. 30 konkretnych tabel przechowujących dane z dziedziny problemu, a każda z nich ma po 3 słowniki. Trudno potem się ogarnąć na pierwszy rzut oka.
Spotkałem się z rozwiązaniem, w którym w bazie była jedna tabela słownikowa z dodatkową kolumną określającą typ słownika. Po stronie aplikacji zaś była klasa, która umożliwiała obsługę różnych słowników wg ich typu.
Myślę, że takie rozwiązanie ma pewną wadę, bo w momencie gdy trzeba jakiś słownik rozbudować, to niestety trzeba go wówczas wydzielić do osobnej tabeli. Trudniej też się czyta dane w takiej bazie przez narzędzia do zarządzania. Za to porządek jakby większy. :)
A Wy stosujecie takie rozwiązania?

I czy w ogóle ułatwiacie sobie jakoś zarządzanie tabelami w bazie, np. nadając im jakieś prefiksy, chociażby inny dla słowników, inny dla tabel administracyjnych, inny dla tych z dziedziny problemu, a inny dla tych od relacji n:n?

co do tabel słownikowych to preferuję wersję jeden słownik jedna tabela. Mam je na tyle różne, że pakowanie tego do jednej tabeli nie zdało by egzaminu
co do prefiksów to przedrostek tabeli określa jaką funkcję pełnią / do jakiego modułu należą

Ja z kolei wolę jedną tabelę do przechowywania danych.
Zakładam na taki słownik dwa primary key'e - jeden na kolumnę określającą typ, drugi na kolumnę zawierają ID w danym typie. Jedyna uciążliwość jest taka, że w powiązanych tabelach trzeba podawać dwa FK'ye, ale za to dzięki temu bardzo łatwo identyfikuje się rekordy i nie ma problemu z rozbudową - dodanie nowego słownika implikuje jedynie konieczność zwiększenia licznika typu.

Prefiksów tabelom nie nadaję, częsciej robię to dla kolumn. Czemu - raczej z przyzwyczajania i łatwiejszej jak dla mnie w takim przypadku pracy np w ORM'ach

Też mnie kiedyś wkurzała duża ilość tabelek słownikowych, ale jak popatrzyłem na zapytania w których do jednej tabeli jest joinowana druga kilka razy z różnymi aliasami to jednak wolę dużo słowników :)

pzdr.

Ja, jak Misiek. Jeden słownik, jedna tabela. W jednym słowniku mam tylko jedno pole, w drugim: 4. Poza tym takie podejście jest chyba dużo łatwiejsze i szybsze. Nie stosuję żadnych prefixów, ani suffiksów w nazwach tabel. Natomiast widoki nazywam z prefiksem: "V_", a funkcje tabelaryczne rozpoczynają się od słowa "Get".

Sufiksy i prefiksy stosuję natomiast zawsze przy nazewnictwie modułów w aplikacji.

To się podepnę, możecie trochę dokładniej opisać budowę słowników na jednej tabeli bo nie do końca rozumiem ?

Ja akurat stosuję jedną tabelę - tam gdzie jest możliwe do przewidzenia że to wystarczy. W tej tabeli mam tak czy siak kilka dodatkowych pól (int, str, float) - w niektórych słownikach jest taka potrzeba. Tabela jest prosta jak budowa cepa

SLOWNIK
ID INT PK
NAZWA VARCHAR(80)
IDTYPU INT
...
tutaj te dodatki
oraz informacje, kto dodał zmodyfikował ...

Jak w jednej tabeli mam kilka pól słownikowych to nie ma z tym żadnego problemu.

SELECT
T.*,
S1.NAZWA AS TYP,
S2.NAZWA AS RODZAJ,
S3.NAZWA AS COŚTAM
FROM TABELA T
LEFT JOIN SLOWNIK S1 ON S1.ID=T.IDTYPU
LEFT JOIN SLOWNIK S2 ON S2.ID=T.IDRODZAJU
LEFT JOIN SLOWNIK S3 ON S3.ID=T.IDCOSTAMA

b

Dzięki, przyda się

b0bik napisał(a)

Ja akurat stosuję jedną tabelę - tam gdzie jest możliwe do przewidzenia że to wystarczy. W tej tabeli mam tak czy siak kilka dodatkowych pól (int, str, float) - w niektórych słownikach jest taka potrzeba. Tabela jest prosta jak budowa cepa

SLOWNIK
ID INT PK
NAZWA VARCHAR(80)
IDTYPU INT
...
tutaj te dodatki
oraz informacje, kto dodał zmodyfikował ...

Jak w jednej tabeli mam kilka pól słownikowych to nie ma z tym żadnego problemu.

SELECT
T.*,
S1.NAZWA AS TYP,
S2.NAZWA AS RODZAJ,
S3.NAZWA AS COŚTAM
FROM TABELA T
LEFT JOIN SLOWNIK S1 ON S1.ID=T.IDTYPU
LEFT JOIN SLOWNIK S2 ON S2.ID=T.IDRODZAJU
LEFT JOIN SLOWNIK S3 ON S3.ID=T.IDCOSTAMA

b

Robienie OUTER JOIN ( w tym przypadku LEFT JOIN) jest niewydajne. Czy zakładasz ze słwonika może nie być? Jezeli może być null to sobie sprawdz (... or xxx is null)

ja czesto stosuje "jedna tabele" dla wielu slownikow, przy zalozeniu ze slownik to para klucz-wartosc
jesli slownik staje sie bardziej skomplikowany (wiecej pol, potrzebne pola innych typow niz znakowe) przenosze go do osobnej tabeli, ale najczesciej te rzeczy wychodza na etapie projektowania lub bardzo wczesnej implementacji

jesli chodzi o wydajnosc, joinowanie takiej tabeli etc. to nigdy nie mialem tam wiecej niz kilka tysiecy wpisow, wiec bez przesady, baza radzi sobie w mgnieniu oka
fakt ze zapytania staja sie bardzie skomplikowane, ale jak zlapiesz schemat pisania takich procedur to nic trudnego

tabela Dictionaries
Id
Name

tabela DictionariesValues
Id
DictId
Key
Value
Order (nie zawsze)

raz potrzebowalem, aby wartosci byly wielojezykowe

tabela Dictionaries
Id
Name

tabela DictionariesValues
Id
DictId
Key
Order (nie zawsze)

tabela DictionariesValuesLangs
Id
DictKeyId
LangId
Value

oczywiscie jesli potrzebowalem ogladac te wpisy z poziomu "konsoli" to czesto mialem juz przygotowane zapytanie, gdzie tylko wstawialem sobie jaki slownik, ewentualnie w jakim jezyku i tyle
i to jest istotna kwestia, ze tworzac baze danych o skomplikowanej konstrukcji, warto miec troche takich procedur pomagajacych monitorowac dane, ktore rozbite sa w wielu tabelach i jakos powiazane, bo za kazdym razem pisanie z lapy takich zapytan jest baaardzo meczace

MarekOraclePoznan napisał(a)

Robienie OUTER JOIN ( w tym przypadku LEFT JOIN) jest niewydajne. Czy zakładasz ze słwonika może nie być? Jezeli może być null to sobie sprawdz (... or xxx is null)

No generalnie tak, choć to zależy od sytuacji, ale w większości przypadków zakładam że słownika może nie być.

MarekOraclePoznan napisał(a)

Jezeli może być null to sobie sprawdz (... or xxx is null)

Nie rozumiem, możesz rozjaśnić ?

b