Baza danych z setkami tabel - dozwolona konstrukcja?

Witam,
chciałbym się zapytać czy baza danych zawierająca setki (a nawet tysiące tabel) ma prawo egzystować ? tzn, czy taka baza jest w ogóle dozwolona i zachowuje się jak "normalna" baza danych --> nie przejawia żadnych anomalii ?

Pozdrawiam,
Michał

tak, tak, nie

Jeśli to nie są tabele typu:
user_0001, user_0002, user_0003
to na wszystkie pytania odpowiedź brzmi TAK (ciche założenie, że to nie MySQL)

U nas w systemie jest ok 1000 tabel i co trochę dochodzą nowe. Jeżeli wszystko jest udokumentowane to nie ma problemu.

A jakie liczba tabel ma w ogóle znaczenie?

Jeżeli system ma jasno wydzielone komponenty (np. dzieli się na system bilingowy, CRM, hurtownię danych), to nie należy wszystkie wrzucać do jednej bazy.
Najlepiej od razu przypisać każdemu podsystemowi oddzielną bazę (albo jeszcze lepiej serwer). Podsystemy powinny łączyć się między sobą przez jasno zdefiniowane interfejsy (np. procedury składowane, koniecznie z dokumentacją).
Takie rozwiązanie bardzo ułatwia późniejszy podział odpowiedzialności oraz administrację bazami (robienie backupu, problem wydajnościowy jednego systemu nie zakłóca pracy innych systemów, itp.).
Zbyt duża liczba tabel sprawia też problemy przy pisaniu zapytań. Dłużej zajmuje odnalezienie odpowiedniej tabeli, niezależnie od IDE (toad, SQL Server Management Studio).

__krzysiek85 napisał(a):

Najlepiej od razu przypisać każdemu podsystemowi oddzielną bazę (albo jeszcze lepiej serwer). Podsystemy powinny łączyć się między sobą przez jasno zdefiniowane interfejsy (np. procedury składowane, koniecznie z dokumentacją).
Takie rozwiązanie bardzo ułatwia późniejszy podział odpowiedzialności oraz administrację bazami (robienie backupu, problem wydajnościowy jednego systemu nie zakłóca pracy innych systemów, itp.).

A co z danymi wspólnymi dla różnych modułów systemu (np. użytkownicy, klienci, lokalizacje geograficzne)? Tworzymy jakąś oddzielną bazę na dane wspólne, z której korzystają wszystkie moduły, czy może jest jakiś zestaw tabel ze wspólnymi danymi, które są replikowane między bazami?

1. Większy problem z ogranięciem bardzo dużej bazy mają ludzie a nie SZBD. To samo jest z bardzo rozbudowanym projektem (kodem). Jak masz już kilkadziesiąt osobnych bibliotek etc. to bez dobrej dokumentacji (o czym już wspominano) też jest ciężko. Czy tylko liczba tabel będzie duża, czy także danych w każdej tabeli będzie dużo (w milionach czy dziesiątkach milionów rekordów)?
2. Przy bardzo dużej bazie należy na etapie projektowym bardzo dobrze zastanowić nad efektywnym wykorzystaniem funkcji konkretnego SZBD. m.in. baza danych może być w więcej niż jednym pliku fizycznym. Optymalne użycie typów danych, także specyficznych dla danej bazy danych, itd.
3. Należy dobrać odpowiednią warstwę sprzętową dla takiej bazy. To że baza jest duża nie oznacza że także jej obciążenie będzie duże.

Poza tym często na poziomie bazy dąży się do unifikacji pewnych obiektów (czyli nie mamy osobnych table na PIES i KOT, tylko mamy ZWIERZE albo SSAK).
Przy tak dużek bazie danych na pewno pojawisię problem redundancji danych. Potrzeba denormalizacji pewnych tabel, czy nieużywania relacji (kluczy obcych, constraint'ów).

Osobiście nie mogę sobie wyobrazić co miłaby robić tak gigantyczna baza (liczba tabel liczona w tysiącach). Jak już wspomniano raczj robi się mniejsze bazy (systemy/podsystemy) i komunikacja między nimi następuje przez jakąś warstwę kodu (usługa, biblioteka warsty dostępu do danych, czy przez warstwę logiki biznesowej).
Chyba dalsze rozważania będą mocno akademickie :)

Ja utrzymuję bazę danych z ponad 1000 tabel i ok 2000 procedur. Nie jest to sprawa prosta, ale zachowując higienę wszystko można. Działa całkiem sprawnie a u klientów rośnie w setki GB. Kwestia dobrego pisania, indeksów i żeby wiedzieć co się robi ( że np. na coalesce się indeks nie założy albo, że można przejść dziedzinę 1 raz a nie n razy ;p )

Na Coalesce nie założy się indeksu? Co ty za bazy używasz??

BEGIN TRANSACTION;
CREATE TEMP TABLE osoby
(
id bigserial NOT NULL PRIMARY KEY,
imie varchar(20) NULL,
nazwisko varchar(20) NOT NULL,
pesel varchar(11) NOT NULL UNIQUE
)
ON COMMIT DROP;
INSERT INTO osoby(imie, nazwisko, pesel) VALUES('Marcin', 'M', '11111111111');
INSERT INTO osoby(nazwisko, pesel) VALUES('M', '2222222222');

CREATE INDEX ON osoby (Coalesce(imie, ''));

@serge a ile programistów gmera przy tej bazie i jak wygląda dokumentacja?
Bo raczej z mojego doświadczenia wynika, że jak nie ma kogoś kto panuje cały czas nad spójnością (tutaj) architekruty bazy i nie leje po rączkach leniwych i tępych programistów to po 2-3 latach masz masakrę a nie bazę :)

Osób co piszą nowe procedury i struktury jest koło 30. Mamy dwie bazy - emisyjną i roboczą. Nakładamy zmiana na roboczą i jest potem 5 osób które przeglądają zmiany wykonane przez pracowników i decydują czy przenosić na emisyjną, czy do poprawy czy do przeprojektowania na spotkaniu. Odpowiednia kontrola i fajne prowadzenie projektu i da się ogarniać taką baze.

Ha! No i jasne solidne code review!!!
Chociaż pseudo PM'y itp i tak pewnie nie czytają tego forum, więc po co ja się jaram.
Ale jak wspomnę jak wygląda code review w wielu corpo, to się nóż w kieszeni otwiera :/

Niby sposoby na utrzymanie higieny dużych systemów nie są szczególnie wydumane, ale niestety dla różnych menago bez wykształcenia IT to dalej ciężkie do zrozumienia że code review to nie tępe gapienie się w literki, że testy to coś więcej niż klikanie tu i tam, że taniej przesunąć release date o 2 tyg. niż później robić hotfixy na produkcji...

Sorry, musiałem się wypłakać.

kazzy napisał(a):

Chociaż pseudo PM'y itp i tak pewnie nie czytają tego forum, więc po co ja się jaram.

PMy pewnie maja swoje fora, na ktorych dyskutuja :)

kazzy napisał(a):

Niby sposoby na utrzymanie higieny dużych systemów nie są szczególnie wydumane, ale niestety dla różnych menago bez wykształcenia IT to dalej ciężkie do zrozumienia że code review to nie tępe gapienie się w literki, że testy to coś więcej niż klikanie tu i tam, że taniej przesunąć release date o 2 tyg. niż później robić hotfixy na produkcji...

Przede wszystkim programista i PM to dwa rozne stanowiska a co za tym idzie patrza z innej perspektywy i maja inne priorytety. Dla Ciebie kluczowa role moze odgrywac jakosc tworzonego kodu, a dla PM termin oddania poszczegolnych funkcjonalnosci bo od tego w duzej mierze zalezy jak bedzie postrzegany przez pracodawce. Jest tutaj niestety pewien konflikt interesow. Niekoniecznie musi tak byc (co nie znaczy, ze tak nie jest :)), ze PM czegos tam nie rozumie - po prostu moze miec inne priorytety i jezeli bedzie rozliczany ze swojej pracy glownie na podstawie terminow to bedzie staral sie dbac o terminy (kosztem czegos innego).

Nie wiem tez na jakiej podstawie twierdzisz, ze przesuniecie release o 2 tygodnie bedzie tansze. Byc moze masz jakies podstawy, zeby tak twierdzic, ale jezeli twierdzisz tak na podstawie zalozenia, ze programisci straca wiecej czasu to moze to byc niepoprawne zalozenie.

kazzy napisał(a):

Sorry, musiałem się wypłakać.

Nie ma sprawy :)