Temat: Diagram E/R w UML?
Tomasz Kupczyk:Aleksander Olszewski:Kamil Stawiarski:
Wiesz, ja tylko twierdzę, że oprogramowywanie funkcjonalności relacji od nowa w aplikacji bywa bez sensu, bo jest to wymyślanie koła na nowo.
Niby prawda, ale ja na co dzień pracuję z systemem, który ma ponad 6000 tabel w relacyjnej bazie i ... ani jednego integrity contraint nałożonego po stronie RBDMS :) [...]
Ja właściwie się dziwię, że to wszystko działa. Jedyna odpowiedź, która mi się nasuwa, to taka, że nie da się tych 6000 tabel połączyć w schemacie relacyjnym.
Schemat jest relacyjny, nie ma jedynie sprawdzania więzów integralności po stronie RBDMS.
Czyli nie ma pilnowania Foreign Key, sprawdzania Check, a jest Primary, Unique Key i częściowo Null? Czy dobrze powyższe odczytałem?
Zapewne w tabelach zwielokrotniono powtarzają się te same dane.
Też, tam gdzie jest to koniecznie, ale w większości przypadków nie ma redundancji i schemat jest dobrze zaprojektowany - relacyjność jest zachowana.
No i chyba tak powinno się rozwiązywać rzeczywiste problemy. Przynajmniej ja się z takim podejściem zgadzam. ;-)
Podstawowa informacja z baz danych, to taka, że założenie relacji przyśpiesza wykonanie zapytania po kilku tabelach.
Tak, ale indeksy są ważniejsze. Nawet najlepiej zaprojektowany schemat będzie na nic, jak nie masz odpowiednich indeksów.
;-)
Czasem bardziej opłaca się rozbić rozbudowane zapytania na 2 mniejsze.I tu ja nie zgodzę się.
To już raczej akademicki problem. Natomiast w kontekście całej dyskusji istotniejszym wydaje mi się przyczyna, która może spowodować alergię na relacje i w konsekwencji doprowadzić do zaklinania rzeczywistości.
Zgadzając się z poniższym
Jak na razie najszybszym optymalizatorem zapytań jest optymalizator silnika bazodanowego, z prostej przyczyny --- jest napisany w niskopoziomowym języku (jak cały silnik) i działa w ramach tego samego procesu systemowego.
i wiążąc z uwagą Pana Kamila, że oprogramowywanie funkcjonalności relacji od nowa w aplikacji bywa bez sensu, chyba warto zadać sobie pytanie, jakie warunki muszą być spełnione, żeby opłacało się zrezygnować z pewnych funkcjonalności bazy. ;-)
Wszak niskopoziomowo przepisywane są także obiekty, a wbudowywane funkcjonalności, oferujące także manipulację danymi, coraz bardziej zaawansowane. Te obiekty typu ClientDataSet i klasy pochodne, są nie tylko funkcjonalne ale pozwalają bez uszczerbku na wydajności, a może nawet z poprawą wydajności, przetwarzać dane w aplikacji i robi się to podobnie jak na bazie.
W tym kontekście, jeżeli zdecydować się na przetwarzanie danych w CDS, oprogramowywanie funkcjonalności relacji w aplikacji jest nie tyle dublowaniem funkcjonalności bazy, co raczej "zabraniem logiki" z bazy, którą przecież łatwo podejrzeć, przekopiować i użyć w konkurencyjnej aplikacji. Nie sprawdzałem, ale intuicyjnie wydaje się, że jest także działaniem w stronę przyśpeszenia aplikacji, zmniejszenia ruchu w sieci, zmniejszenia obciążenia dysków serwera, .. .
Niniejsze sprowadza więc bazę, niczego jej nie ujmując, do roli inteligentnego kontenera na dane. ;-)
Jak dla mnie, warto zachować w bazie wszystkie te elementy, które pozwalają na szybkie udostępnianie danych np: indeksy, niektóre relacje, a to co wiąże się z przetwarzaniem danych, np: niektóre relacje przenieść do aplikacji.
Przetwarzając dane w takim obiekcie, mamy więc pełnię funkcjonalności bazy. Jednak jeżeli programista "kopnie się", to może on obserwować efekt, że dopóki jest na jakiejś formatce, w aplikacji to wszystkie dane są dostępne, może je dodawać, może usuwać, ale opuszczenie formatki, aplikacji i powrót to .. ogladanie pustego rekordseta. ;-)
Usunięcie kucza obcego w bazie, usuwa tę niedogodność i może być uznane, że wszystkiemu winne są obecne w bazie relacje, constrainty. Prawda oczywiście jest taka, że jest błąd w programie, ale łatwiej go naprawić umieszczając wszystkie dane w jednej tabeli i zrezygnować z kluczy obcych niż prowadzić śledztwo, którego nota bene podejmowanie z góry skazane jest na porażkę jak programista nie do końca jest świadom logiki całości.
Analiza schematu UML nic tu raczej nie pomoże bo tam relacje biznesowe, a schemat encji i relacji zawierać może wiele szczegółów utrudniających analizę problemu. Zresztą trzeba wiedzieć czego się szuka, a to nie zawsze oczywiste. ;-)
Pewnie nie jeden miał pianę na ustach, ja też ;-), ale na szczęście nigdy nie wpadłem na pomysł kwestionowania faktu obecności relacji w naszym życiu. ;-))) Reasumując, paradygmat obiektowy, jak dla mnie, to rozsądna alternatywa dla Query i jak ktoś nie wpadnie na robienie z tabelami w bazie głupot, to wszystkim może jego użycie wyjść na dobre. Ale to nie takie oczywiste. ;-)))
пропозиції роботи
