Temat: Diagram E/R w UML?

Kamil Stawiarski:

Jarek Żeliński:

Kamil Stawiarski:
Ok. Próbując zrozumieć dalej - załóżmy, że masz jako silnik na dane Oracle'a - masz tam wtedy zaimplementowany jeden schemat, w którym trzymasz jedną płaską tabelę?

nie

Ale mając wiele tabel, nie łączysz ich żadnymi więzami integralności,tak?

nie, nie łączę bo nie raz nie ma to sensu lub uzasadnienia: jeżeli mam w jednym podsystemie tabelę Klient a w drugim tabele Faktura to NIP łączy je logicznie ale nie fizycznie w systemie bo nie raz nie mam możliwości lub chęci, z perspektywy złożonego systemu faktury i kontrahenci są rozdzielnymi "obszarami". Mogę bez problemu skojarzyć fakturę z kontrahentem na bazie numery NIP i logikę te obsłuży aplikacja niezależnie od tego czy Klient to dane z innego systemu (np. CRM) czy własny komponent. W takim przypadku w dowolnym momencie zamieniam własny komponent zewnętrznym systemem CRM i nie mam problemy z "rozpinaniem" relacyjnej bazy... bo nie mam relacji...

Temat: Diagram E/R w UML?

Marek Kubiś:

Jarek Żeliński:

Marek Kubiś:

To system nie przechowuje tej samej wartości w jednym miejscu i nie wie, że dwie różne rzeczy to te same rzeczy (jeżeli są te same) i nie sporządzi jednego łącznego raportu. ;-(

zapewniam, że sporządzi...

Oczywiście! ale bzdurny. ;-(

gratuluję oceny czegoś czego Pan nie widział...

Aha .. :-( A czy mogę mieć prośbę aby nie sugerował Pan, że powiedziałem coś czego nie powiedziałem? :-(

na jakiej wiec podstawie napisał Pan "bzdurny"?

Temat: Diagram E/R w UML?

Jarek Żeliński:
nie, nie łączę bo nie raz nie ma to sensu lub uzasadnienia: jeżeli mam w jednym podsystemie tabelę Klient a w drugim tabele Faktura to NIP łączy je logicznie ale nie fizycznie w systemie bo nie raz nie mam możliwości lub chęci, z perspektywy złożonego systemu faktury i kontrahenci są rozdzielnymi "obszarami". Mogę bez problemu skojarzyć fakturę z kontrahentem na bazie numery NIP i logikę te obsłuży aplikacja niezależnie od tego czy Klient to dane z innego systemu (np. CRM) czy własny komponent. W takim przypadku w dowolnym momencie zamieniam własny komponent zewnętrznym systemem CRM i nie mam problemy z "rozpinaniem" relacyjnej bazy... bo nie mam relacji...

Jarek, już miałem dać sobie spokój, ale jak to przeczytałem to o mało nie spadłem z fotela (a cholera jutro gram w turnieju w Warszawie i muszę być sprawny). W takim razie co się dzieje z "rozpinaną relacją" jeśli klient ma 10 fili i wszystkie oddziały oczywiście mają ten sam NIP, ale dane nagłówkowe itd. dla każdego oddziału są inne, a dodatkowo klient (mam na myśli Twojego klienta, czyli tego który na "systemie nie relacyjnym" opartym na nie releacji po NIP) chce mieś obroty każdego z oddziałów na oddzielnej analityce ?

pozdrawiam

Temat: Diagram E/R w UML?

Jarek Żeliński:

Kamil Stawiarski:

Jarek Żeliński:

Kamil Stawiarski:
Ok. Próbując zrozumieć dalej - załóżmy, że masz jako silnik na dane Oracle'a - masz tam wtedy zaimplementowany jeden schemat, w którym trzymasz jedną płaską tabelę?

nie

Ale mając wiele tabel, nie łączysz ich żadnymi więzami integralności,tak?

nie, nie łączę bo nie raz nie ma to sensu lub uzasadnienia: jeżeli mam w jednym podsystemie tabelę Klient a w drugim tabele Faktura to NIP łączy je logicznie ale nie fizycznie w systemie bo nie raz nie mam możliwości lub chęci, z perspektywy złożonego systemu faktury i kontrahenci są rozdzielnymi "obszarami". Mogę bez problemu skojarzyć fakturę z kontrahentem na bazie numery NIP i logikę te obsłuży aplikacja niezależnie od tego czy Klient to dane z innego systemu (np. CRM) czy własny komponent. W takim przypadku w dowolnym momencie zamieniam własny komponent zewnętrznym systemem CRM i nie mam problemy z "rozpinaniem" relacyjnej bazy... bo nie mam relacji...

Czyli podsumowując: nie masz nic przeciwko "konglomeratowi prostych agregatów" ale w ramach tychże nie uznajesz pojęcia fizycznej relacji między tabelami a zamiast tego realizujesz jej funkcjonalność na nowo w systemie, tak?

Temat: Diagram E/R w UML?

Jarek Żeliński:

Marek Kubiś:

Jarek Żeliński:

Marek Kubiś:

To system nie przechowuje tej samej wartości w jednym miejscu i nie wie, że dwie różne rzeczy to te same rzeczy (jeżeli są te same) i nie sporządzi jednego łącznego raportu. ;-(

zapewniam, że sporządzi...

Oczywiście! ale bzdurny. ;-(

gratuluję oceny czegoś czego Pan nie widział...

Aha .. :-( A czy mogę mieć prośbę aby nie sugerował Pan, że powiedziałem coś czego nie powiedziałem? :-(

na jakiej wiec podstawie napisał Pan "bzdurny"?

Bo "nie jednemu psu Burek na imię" więc systemowi (nieważne gdzie, czy w bazie, czy w aplikacji) należy wskazać (relacja), które pola tabel (różne rzeczy) zawierają te same dane (to te same rzeczy) i dodatkowo należy zadbać o jednoznaczność tej identyfikacji (constraint Unique).

Jak tego się nie zapewni to pytając o Jana Kowalskiego zwrotnie uzyska się informacje o wszystkich Janach Kowalskich jacy tylko zostali zarejestrowani w systemie, lub o pierszym, lub o ostatnim, lub o poprzednim, lub o następnym, lub dowolnym innym i to być może za każdym razem przy powtórzeniu zapytania o innym.

Jarek Żeliński:
jeżeli mam w jednym podsystemie tabelę Klient a w drugim tabele Faktura to NIP łączy je logicznie ale nie fizycznie

ROMAN WILK:
W takim razie co się dzieje z "rozpinaną relacją" jeśli klient ma 10 fili i wszystkie oddziały oczywiście mają ten sam NIP, ale dane nagłówkowe itd. dla każdego oddziału są inne, a dodatkowo klient ..

;-)))

No cóż, Pan Jarek w życiu nie przyzna się, że popełnił błąd, palnął głupotę, i brnie, i brnie, i zakłada relacje twierdząc że to nie relacje, .. i brnie, i brnie, .., że teraz to już nie widamo co powiedzieć, w kontekście tych jego całkiem przyzwoitych zleceń. ;-(

To ja już dam sobie spokój. ;-)

Temat: Diagram E/R w UML?

Marek Kubiś:
Bo "nie jednemu psu Burek na imię" więc systemowi (nieważne gdzie, czy w bazie, czy w aplikacji) należy wskazać (relacja), które pola tabel (różne rzeczy) zawierają te same dane (to te same rzeczy) i dodatkowo należy zadbać o jednoznaczność tej identyfikacji (constraint Unique).

skoro nie potrafi Pan inaczej...

No cóż, Pan Jarek w życiu nie przyzna się, że popełnił błąd, palnął głupotę, i brnie, i brnie, i zakłada relacje twierdząc że to nie relacje, .. i brnie, i brnie, .., że teraz to już nie widamo co powiedzieć, w kontekście tych jego całkiem przyzwoitych zleceń. ;-(

jaką relacja zakłada Pan na dane pomiędzy dwoma rozłącznymi systemami i w jakiej bazie? Kto tu brnie :) ??

Temat: Diagram E/R w UML?

ROMAN WILK:
W takim razie co się dzieje z "rozpinaną relacją" jeśli klient ma 10 fili i wszystkie oddziały oczywiście mają ten sam NIP, ale dane nagłówkowe itd. dla każdego oddziału są inne, a dodatkowo klient (mam na myśli Twojego klienta, czyli tego który na "systemie nie relacyjnym" opartym na nie releacji po NIP) chce mieś obroty każdego z oddziałów na oddzielnej analityce ?

Ja nie rozpinam żadnej relacji, co Wy z tymi relacjami, można ich nie mieć... na prawdę uważacie, że bez jednej relacyjnej bazy nic nie da się zrobić, cóż... pisze jak wół, że nie używam (zawsze) jednego relacyjnego modelu danych dla całego systemu a Wy stale to pomijacie...Jarek Żeliński edytował(a) ten post dnia 12.11.11 o godzinie 00:36

Temat: Diagram E/R w UML?

Kamil Stawiarski:
Czyli podsumowując: nie masz nic przeciwko "konglomeratowi prostych agregatów" ale w ramach tychże nie uznajesz pojęcia fizycznej relacji między tabelami a zamiast tego realizujesz jej funkcjonalność na nowo w systemie, tak?

W ramach agregatu możliwe jest (jak ma to uzasadnienie projektowe a nie zawsze ma) użycie prostego relacyjnego modelu. Logika kojarzenia między sobą różnych agregatów może być opisana tylko w aplikacji. Wtedy łatwo, bez uszczerbku dla systemu, rozdzielić takie agregaty na osobne podsystemy.

Temat: Diagram E/R w UML?

Jarek Żeliński:

Marek Kubiś:
Bo "nie jednemu psu Burek na imię" więc systemowi ..

skoro nie potrafi Pan inaczej...

No cóż, Pan Jarek w życiu nie przyzna się, że popełnił błąd, palnął głupotę, i brnie, i brnie, i zakłada relacje twierdząc że to nie relacje, .. i brnie, i brnie, .., że teraz to już nie widamo co powiedzieć, w kontekście tych jego całkiem przyzwoitych zleceń. ;-(

jaką relacja zakłada Pan na dane pomiędzy dwoma rozłącznymi systemami i w jakiej bazie? Kto tu brnie :) ??

Dziękuję za rozmowę.

Temat: Diagram E/R w UML?

Marek Kubiś:

Jarek Żeliński:

Marek Kubiś:
Bo "nie jednemu psu Burek na imię" więc systemowi ..

skoro nie potrafi Pan inaczej...

No cóż, Pan Jarek w życiu nie przyzna się, że popełnił błąd, palnął głupotę, i brnie, i brnie, i zakłada relacje twierdząc że to nie relacje, .. i brnie, i brnie, .., że teraz to już nie widamo co powiedzieć, w kontekście tych jego całkiem przyzwoitych zleceń. ;-(

jaką relacja zakłada Pan na dane pomiędzy dwoma rozłącznymi systemami i w jakiej bazie? Kto tu brnie :) ??

Dziękuję za rozmowę.

Ja także...

Temat: Diagram E/R w UML?

Jarek Żeliński:

Kamil Stawiarski:
Czyli podsumowując: nie masz nic przeciwko "konglomeratowi prostych agregatów" ale w ramach tychże nie uznajesz pojęcia fizycznej relacji między tabelami a zamiast tego realizujesz jej funkcjonalność na nowo w systemie, tak?

W ramach agregatu możliwe jest (jak ma to uzasadnienie projektowe a nie zawsze ma) użycie prostego relacyjnego modelu. Logika kojarzenia między sobą różnych agregatów może być opisana tylko w aplikacji. Wtedy łatwo, bez uszczerbku dla systemu, rozdzielić takie agregaty na osobne podsystemy.

Jarku, ale nadal będzie relacją ;)
Przecież relacja nie jest pojęciem, odnoszącym się tylko i wyłacznie do mechanizmów zapewnianych przez silnik bazy danych. Relacja między dwoma zbiorami oznacza, ni mniej ni więcej, sposób powiązania danych z jednego z bioru z danymi z drugiego zbioru. I nie ma tutaj znaczenia, czy te zbiory są tabelami, czy może jeden jest plikiem txt na innym systemie a drugi datasetem udostępnianym przez webserwis. Nie ma też znaczenia, gdzie ta relacja jest realizowana: czy w silniku bazodanowym, czy w kodzie aplikacji - to nadal TA SAMA relacja. Relacja mówi, w jaki sposób kojarzymy konkretne dane, a nie, gdzie to się odbywa i jak te dane są reprezentowane.
To tyle ;)

Temat: Diagram E/R w UML?

Piotr Głudkowski:
Jarku, ale nadal będzie relacją ;)

owszem ale jak wiemy jest relacja logiczna (związek logiczny) pomiędzy mną a moim świadectwem maturalnym w mojej dawnej średniej szkole i jest relacja "fizyczna" (więzy itp...) w relacyjnej bazie danych dajmy na to zawierającej moje dane w tym oceny z matury.

Przecież relacja nie jest pojęciem, odnoszącym się tylko i wyłacznie do mechanizmów zapewnianych przez silnik bazy danych.

wiem, jak wyżej, ale dlatego należy się precyzyjnie wyrażać by nie zagubić tej różnicy, dlatego używam odrębnie pojęcie "związek logiczny" albo "asocjacja" i "relacja" bo to nie jest to samo.

Nie ma też znaczenia, gdzie ta relacja jest realizowana: czy w silniku bazodanowym, czy w kodzie aplikacji - to nadal TA SAMA relacja. Relacja mówi, w jaki sposób kojarzymy konkretne dane, a nie, gdzie to się odbywa i jak te dane są reprezentowane.

To wszystko prawda do momentu gdy nie pada słowo "zapytanie SQL" itp. ... bo ono działa wyłącznie na relacjach w relacyjnej bazie danych.

Albo się mylę albo nie, ale dla wielu tu ludzi pojęcia "relacja" na diagramie ERD i związek logiczny (tez rodzaj relacji) na modelu np. taksonomii (diagram klas UML) jako "asocjacja", są utożsamiane co jest ogromnym błędem. Nie przypadkiem pojęcia "relacja" w modelu relacyjnym i "asocjacja" w modelu obiektowym to zupełnie odrębne pojęcia. Jeżeli ktoś "nie rozumie" tej różnicy (a ona jest) to co ja mam powiedzieć?

W modelu obiektowym istnieje związek logiczny pomiędzy obiektami połączonymi związkiem "use" w celu wyszukania np. mojego ŚwiadectwaMaturalnego w zasobach SzkołyPodstawowej. Odbywa się to z pomocą odwołania się do stosownej operacji udostępnianej przez SzkołęPodstawą. W modelu relacyjnym to świadectwo było raportem z relacyjnej bazy danych zawierającej dane i moje i tej szkoły. Różnica jest OGROMNA. Między innymi dlatego, że w modelu obiektowym JarekŻeliński (lub inny obiekt) wyśle komunikat do SzkołaPodstawowa by poprosić o ŚwiadectwaMaturalne. JarekŻelińśki i SzkołaPodstawowa mogą być obiektami z dwóch odrębnych systemów mających odrębne repozytoria danych. Mamy tu jakiś związek logiczny (relacje logiczną) ale nie ma żadnej "relacji" w rozumieniu modelu ERD.

Temat: Diagram E/R w UML?

Jarek Żeliński:

To wszystko prawda do momentu gdy nie pada słowo "zapytanie SQL" itp. ... bo ono działa wyłącznie na relacjach w relacyjnej bazie danych.

Ale zdajesz sobie sprawę, że jeśli Twoja aplikacja obiektowa korzysta z silnika RDBMS to prędzej czy później wygeneruje jakiegoś SQL'a? :)

Temat: Diagram E/R w UML?

Kamil Stawiarski:

Jarek Żeliński:

To wszystko prawda do momentu gdy nie pada słowo "zapytanie SQL" itp. ... bo ono działa wyłącznie na relacjach w relacyjnej bazie danych.

Ale zdajesz sobie sprawę, że jeśli Twoja aplikacja obiektowa korzysta z silnika RDBMS to prędzej czy później wygeneruje jakiegoś SQL'a? :)

ale ja tego nigdy nie negowałem (nie raz zalecam), ale zdajesz sobie sprawę z tego że ten motor SQL zarządza (tu) dość luźno (lub wcale) nie powiązanymi tablicami a nie jednym wielkim, wspólnym dla całego "systemu" zestawem danych w modelu relacyjnym w trzeciej postaci normalnej... czasami mam zarzut, że "te dane bez aplikacji są bez sensu", po pierwsze maja głęboki sens, po drugie "przykro mi", że nie da się tam grzebać z pominięciem tej aplikacji jakimiś SLQ'owymi zapytaniami co nie raz paradoksalnie pomaga a nie szkodzi...Jarek Żeliński edytował(a) ten post dnia 12.11.11 o godzinie 12:19

Temat: Diagram E/R w UML?

Jarek Żeliński:

Kamil Stawiarski:

Jarek Żeliński:

To wszystko prawda do momentu gdy nie pada słowo "zapytanie SQL" itp. ... bo ono działa wyłącznie na relacjach w relacyjnej bazie danych.

Ale zdajesz sobie sprawę, że jeśli Twoja aplikacja obiektowa korzysta z silnika RDBMS to prędzej czy później wygeneruje jakiegoś SQL'a? :)

ale ja tego nigdy nie negowałem (nie raz zalecam), ale zdajesz sobie sprawę z tego że ten motor SQL zarządza (tu) dość luźno (lub wcale) nie powiązanymi tablicami a nie jednym wielkim, wspólnym dla całego "systemu" zestawem danych w modelu relacyjnym w trzeciej postaci normalnej... czasami mam zarzut, że "te dane bez aplikacji są bez sensu", po pierwsze maja głęboki sens, po drugie "przykro mi", że nie da się tam grzebać z pominięciem tej aplikacji jakimiś SLQ'owymi zapytaniami co nie raz paradoksalnie pomaga a nie szkodzi...

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. Rozumiem, że jedna duża relacyjna baza dla złożonego systemu nie jest wyjściem optymalnym ale nie wydaje mi się, żeby popadanie w skrajności było dobrym rozwiązaniem. Kiedy aplikacja realizuje relację z użyciem wielu "pętli" i "ifów" zamiast wykorzystać gotowe mechanizmy to skutkuje to nadmiernym ruchem sieciowym, nadmiernym operacjami IO i w ogólności zwolnieniem wydajności systemu co w wielu przypadkach jest niedopuszczalne. Bo nie zgadzam się, że wydajność nie ma znaczenia a wszystko można ogarnąć dokładając więcej ram'u, lepsze dyski czy więcej CPU... A jeśli nie korzystasz z funkcjonalności, które zapewnia Ci silnik RDBMS no po co go wogóle stosować :)

Temat: Diagram E/R w UML?

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 :) Schema trzymana jest po stronie serwera aplikacji i śmiga to wszystko bardzo dobrze. Zastanawiam się, co byśmy osiągnęli, definiując teraz kilkanaście tysięcy (lekko licząc) constraintów? Czy wydajność by wzrosła? A może wręcz przeciwnie, bo przecież sprawdzanie więzów integralności po stronie RBDMS też nie jest za darmo.

A jeśli nie korzystasz z funkcjonalności, które zapewnia Ci silnik RDBMS no po co go wogóle stosować :)

Pytanie, czy musisz korzystać ze wszystkiego, co fabryka dała?

Temat: Diagram E/R w UML?

Tomasz K.:

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 :) Schema trzymana jest po stronie serwera aplikacji i śmiga to wszystko bardzo dobrze. Zastanawiam się, co byśmy osiągnęli, definiując teraz kilkanaście tysięcy (lekko licząc) constraintów? Czy wydajność by wzrosła? A może wręcz przeciwnie, bo przecież sprawdzanie więzów integralności po stronie RBDMS też nie jest za darmo.

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. Zapewne w tabelach zwielokrotniono powtarzają się te same dane. Dalej mogę założyć, że zapewne nikt nawet nie rozrysował tego wszystkiego, a tabele pojawiały się ad hoc rok po roku.

Podstawowa informacja z baz danych, to taka, że założenie relacji przyśpiesza wykonanie zapytania po kilku tabelach. Fakt jest taki, że zapytanie do 2 tabel z osobna sumarycznie jest wolniejsze niż jedno zapytanie z JOINem.

A jeśli nie korzystasz z funkcjonalności, które zapewnia Ci silnik RDBMS no po co go wogóle stosować :)

Pytanie, czy musisz korzystać ze wszystkiego, co fabryka dała?

Nie, nie trzeba korzystać ze wszystkiego co fabryka dała. Ale nie ma sensu kupować Ferrari do jazdy na zakupy do supermarketów: bo na pierwszym progu zwalniającym zerwiemy miskę olejową.

Temat: Diagram E/R w UML?

Aleksander Olszewski:

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.

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.

Dalej mogę założyć, że zapewne nikt nawet nie rozrysował tego wszystkiego

Pudło.

a tabele pojawiały się ad hoc rok po roku.

Może nie ad hoc, ale pojawiały się, jak w każdym większym systemie.

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.

Fakt jest taki, że zapytanie do 2 tabel z osobna sumarycznie jest wolniejsze niż jedno zapytanie z JOINem.

Tak, ale już JOIN 10 tabel niekoniecznie. Czasem bardziej opłaca się rozbić rozbudowane zapytania na 2 mniejsze.

Temat: Diagram E/R w UML?

Tomasz K.:
...
Tak, ale już JOIN 10 tabel niekoniecznie. Czasem bardziej opłaca się rozbić rozbudowane zapytania na 2 mniejsze.

I tu ja nie zgodzę się. Owszem, są nieliczne przypadki, gdy rzeczywiście zdarza się sytuacja patowa i jakimś układzie bez zmiany struktury nie da rady wydobyć danych szybciej niż poprzez odpytanie w kilku zapytaniach, ale jednak w znakomitej większości przypadków wszystko rozbija się o umiejętne złożenie zapytania i jak najszybsze zawężenie puli wyników, nie mówiąc o tym, że trzeba wiedzieć czym się różni HAVING od WHERE. 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.

Temat: Diagram E/R w UML?

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.

nikt tu nie wymyśla oprogramowania relacji na nowo, rzecz w tym, że nie raz proste relacje ERD są zbyt proste i paradoksalnie pisanie funkcji operujących na tych danych jest trudniejsze niż oprogramowanie ich w aplikacji. Typowym przykładem są złożone zależności związane z obsługa historii zmian czy wymaganie modyfikacji logiki danych w czasie.

Kiedy aplikacja realizuje relację z użyciem wielu "pętli" i "ifów"

nie prawda

Bo nie zgadzam się, że wydajność nie ma znaczenia a wszystko można ogarnąć dokładając więcej ram'u, lepsze dyski czy więcej CPU... A jeśli nie korzystasz z funkcjonalności, które zapewnia Ci silnik RDBMS no po co go wogóle stosować :)

bo jest fajnym narzędziem do zarządzania nawet pojedynczymi tabelami :), po drugie coraz częściej bywa, że wartość oprogramowania leży w jego podatności na zmiany a niestety jeden system relacyjnych danych "pod aplikacją" nie ułatwia tego...