Ok, mowiac “logiczna” to rozumiem osobny schemat bazy/osobna instancje bazy, a w Management Studio to porpostu kolejny lisc drzewa

Dla mnie w jezyku polskim brak okreslenia “server baz danych” jako ze potocznie sie mowi: zainstalujemy baze danych maja na mysli DB Server, nastepnie sie mowi: “utworzy sie baze danych” i ma sie na mysli stworzenie instancji bazy danych o okreslonym schemacie.

Roznica pomiedzy Database Server a Database w polskim jezyku nie istnieje, to znaczy istnieje, ale w 95% ludzie wykorzystuja slowo Baza Danych zamiennie.

Wiec rasumujac, zrozumialem Twoj “logiczny magazyn dancych” jako kolejna database – ha nie uzylem polskiego slowa!

Wytlumaczylem o co mi chodzilo?

Gutek

Co masz na myśli mówiąc o datkowej pracy w przypadku większej liczny logicznych magazynów danych? Jeśli to tylko kilka tabelek w tej samej bazie to nie powinno być z tym większych problemów od strony IT stuff

“rozwiązania rodem z OLAP…” – zgadzam się:)

“największą poprawę…” – OK, znowu się wyraziłem zbyt czarno-biało

“podobnie asynchroniczna komunikacja” – miałem na myśli fakt, że można ją symulować synchronicznie, więc nie wiąże się z dodatkowym nakładem pracy.

“To zależy” — doookładnie. Wszystko zależy. Celem mojego posta było pokazanie, że sposób zaprojektowania bazy danych też zależy i nie koniecznie jest to 3cia forma normalna.

pracowalem z roznymi systemiami czasami nawet nie tylko serwer bazodanowy byl inny (Object DB, XML DB, Oracle, DB2 – jedna aplikacja dane w wyzej wymienionych serwerach bazodanowych) dla kazdej instancji bazy danych ale takze dane roznily sie struktura jak i przeznaczeniem.

Dla przykladu na MS interview mialem zaprojektowac system ktory domyslnie wspiera jednego uzytkownika a po godzinie rozmowy mial juz wpsierac 100 milionow uzytkownikow w rozporszonym systemie itp itd – wiem, przyklad duzego rozwiazania a nie malego, ale to pokazuje, ze wszystko jest zalezne.

dla prostego systemu przechowujacego CV kilku osob nie tworzylbym kilku instancji baz o roznych schematach, bo nie widze w tym sensu. ale na przyklad przy systemie fakturowania i obslugi wielu klientow juz bym sie zastanawial.

Dodatkowo, wiele “logicznych magazynow danych” oczywisice ze moze szkodzic – glupi przyklad, maintenance. Wprowadzenie poprawek itp. wiec to nie jest tak ze dodamy sobie klase i jest spoko – oj nie, tutaj wchodzi dodatkowa praca.

“rozwiązania rodem z OLAP (denormalizacja i schemat gwiazdy) są przydatne także w prostszych zastosowaniach” – nie we wszystkich, zmienilbym na moga byc przydatne a nie sa.

“największą poprawę wydajności systemu bazodanowego można uzyskać na poziomie modelu, a nie samej bazy danych” – zakladajac ze schemat/model zostal zwalony, bo jezeli jest dobry to juz niekoniecznie. Choc i widzialem przyklady gdzie fatalny schemat bazy danych dostawal maksymalnego kopa po pewnych zmianach serwerowych i konfiguracyjnych.

“podobnie asynchroniczna komunikacja” – znow zalezy od tego co z czym ma sie komunikowac, na jakiej zasadzie i od czego jest to uzaleznione.

ale sie rozpisalem ale tak jak na poczatku napisal: To zalezy

Gutek

Dziękujemy za publikację – Trackback z dotnetomaniak.pl…