Temat: Diagram E/R w UML?

Krzysztof Bokiej:
Po pierwsze, przykład był po to, żeby Ci udowodnić, że normalizacja to szybszy zapis. Bo zupełnie bezpodstawnie to kwestionowałeś. Chociaż pewnie i tak nigdy tego nie sprawdzisz w praktyce ;-)

kwestionuję tylko to, że "normalizacja jest jedynie słuszna"..

Powtórzę. Jak się zdecydowałeś na repozytorium w postaci bazy danych, to korzystaj z dobrodziejstw tej bazy danych. A nie wymyślaj koło na nowo.

po pierwsze pojęcia "baza danych" i "relacyjny system zarządzania danymi" to nie to samo.

po drugie mnie jako projektanta interesuje postawienie wymagań i wybór rozwiązania spełniającego je minimalnym kosztem a nie szukanie na siłę zastosowania dla jakiegoś relacyjnego systemu (motora) zarządzania danymi... (syndrom młotkowego) i tu tkwi różnica pomiędzy mną i wieloma tu,

jeżeli projektuję system jako kilka odrębnych i niezależnych podsystemów czy modułów to relacyjny system można sobie wsadzić w .... dane są wymieniane poprzez interfejsy i kojarzone rzeczywistymi atrybutami (takimi jak PESEL, NIP, czy np. Imię, Nazwisko i imię ojca, i inne.) każdy z tym komponentów mogę niezależnie wstawić i usunąć z systemu, zamienić z innym komponentem bez uszczerbku dla reszty.

Jeżeli jeden system zapyta drugi o numer zamówienia i nie znajdzie, to nie widzę żadnej tragedii w odpowiedzi "nie znaleziono"... natomiast próba postawienia systemu składającego się z niezależnych komponentów na jednej relacyjnej bazie danych przeczy całemu projektowi, to jest niezależności tych komponentów. I wole operować całą logiką na poziomie aplikacji i utrwalać wyłącznie proste dane (np. rzeczony wzorzec active record) bo jestem niezależny od systemu utrwalania.

Na koniec przykłady w rodzaju "a miliony rekordów na raz" to po pierwsze bardzo rzadkie przypadki po drugie jak wystąpią to implementuje się je jako hurtownie lub podobne wydzielone składy danych.... nie raz faktycznie na relacyjnych motorach danych ale to inna bajka...

ale odbiegamy od tematu: powtórzę więc: modelowanie danych w UML jest bez sensu skoro mamy ERD.

Temat: Diagram E/R w UML?

Jarek Żeliński:

Procesor? Procesor przy więzach ma akurat mało do roboty. Głównym problemem tu jest I/O, czyli dyski. Oczywiście tylko w przypadkach zapisu/aktualizacji/usuwania. Brak odpowiedniego indeksowania drastycznie pogarsza sprawę.

może nie był to faktycznie najlepszy argument :), ja po protu staram się zwrócić uwagę na fakt, że wymagania funkcjonalne i niefukcjolane to odrębne rzeczy, logika biznesowa dotyczy funkcjonalności a wydajność jakości. Tak więc logika tkwi w modelu dziedziny a reszta w implementacji repozytorium.... łączenie bazy danych i logiki biznesowej to łamanie bardzo przydatnej izolacji logiki od systemu utrwalania.

Oczywiście z perspektywy projektanta BD to pudełko na dane. Nikt chyba nie twierdzi, że BD sama w sobie realizuje jakieś funkcjonalności. To czego zdaje się nie chcesz uznać lub stoisz na stanowisku, że nie potrzebujesz, to jest to, że BD dostarcza mechanizmów utrzymujących porządek w tych danych. Podstawa to transakcyjność, a dopełnienie to więzy integralności. Plus oczywiście cała masa rzeczy związanych z administracją, czyli ochrona przed nieuprawnionym dostępem, kopie zapasowe itd.
Nie wszędzie i nie za wszelką cenę te mechanizmy są potrzebne, ale jakoś się tak składa, że zdecydowana większość chce je mieć i uznaje za ważne.

do tego system ma być wystarczająco dobry a nie najlepszy ... dlatego stosowanie baz relacyjnych itp. "bo tak" uważam za szkodliwe tym bardziej, ze ich zalety to tylko pewne specyficzne sytuacje, w szczególności właśnie normalizacja i wszelkie "więzy" to obecnie raczej kula ubogi niż pomoc....

A później przychodzą ludzie od hurtowni danych i mówią: "O kur.., ale burdel w danych" i liczą sobie odpowiednio więcej za czyszczenie danych i obsługę tych przypadków, gdzie ktoś nie miał kuli u nogi.
Co do więzów to można je sprawdzać na końcu transakcji, więc ta kula to nie taka wielka znowu. Pewnie, że można synchronizować dostęp i dbać o spójność w aplikacji, ale to tak jak KB zauważył wymyślanie koła na nowo. Zaś gadki szmatki o tym, że ewentualne błędy w aplikacji na testach się wykryje, to tylko o śmiech mnie przyprawiają. Kilka projektów w życiu widziałem :).

Temat: Diagram E/R w UML?

Jarek Żeliński:
zastanawiam się, dlaczego skrzętnie pomijane są odpowiedzi na pytania jak relacyjny model radzi sobie z:

Bo może zadajesz je nieprecyzyjnie i nie wprost :)?

- podzieleniem systemu na dwie części

Podsystemy?

- cloud computing czyli system jako niezależne komponenty

A co ma jakakolwiek baza/repozytorium na dane do tego? I z jakiej strony na to patrzysz? Dostawcy chmury, czy klienta?

- łatwa zmiana modelu dziedziny pracującego systemu

Dodanie kolumn/tabel jest wg mnie łatwe.

- ...

Tego pytania to już kompletnie nie rozumiem :).

Temat: Diagram E/R w UML?

Jarek Żeliński:
kwestionuję tylko to, że "normalizacja jest jedynie słuszna"..

To już chyba Kimball przewalczył :).

po pierwsze pojęcia "baza danych" i "relacyjny system zarządzania danymi" to nie to samo.

Jest 2011 rok... chyba wszyscy utożsamiają ze sobą te dwa terminy.

po drugie mnie jako projektanta interesuje postawienie wymagań i wybór rozwiązania spełniającego je minimalnym kosztem a nie szukanie na siłę zastosowania dla jakiegoś relacyjnego systemu (motora) zarządzania danymi... (syndrom młotkowego) i tu tkwi różnica pomiędzy mną i wieloma tu,

Git, też bym nie chciał, żeby ktoś ładował logi Apache'a do BD.

jeżeli projektuję system jako kilka odrębnych i niezależnych podsystemów czy modułów to relacyjny system można sobie wsadzić w .... dane są wymieniane poprzez interfejsy i kojarzone rzeczywistymi atrybutami (takimi jak PESEL, NIP, czy np. Imię, Nazwisko i imię ojca, i inne.) każdy z tym komponentów mogę niezależnie wstawić i usunąć z systemu, zamienić z innym komponentem bez uszczerbku dla reszty.

Nikt chyba nie komunikuje ze sobą bezpośrednio baz danych różnych systemów.

Jeżeli jeden system zapyta drugi o numer zamówienia i nie znajdzie, to nie widzę żadnej tragedii w odpowiedzi "nie znaleziono"...

Nie wiem za czym ten argument przemawia... Jak nie ma, to nie ma :).

natomiast próba postawienia systemu składającego się z niezależnych komponentów na jednej relacyjnej bazie danych przeczy całemu projektowi, to jest niezależności tych komponentów. I wole operować całą logiką na poziomie aplikacji i utrwalać wyłącznie proste dane (np. rzeczony wzorzec active record) bo jestem niezależny od systemu utrwalania.

W życiu nie widziałem współdzielenia jednej bazy przed różne systemy. Wiele instancji dla wielu systemów owszem, ale to nic innego jak wirtualizacja.
Nikt chyba nie naciska na kodowanie aplikacji z użyciem poleceń SQL, tudzież PL/SQL, czy innego języka specyficznego dla konkretnego produktu bazodanowego. "Przykrycie" bazy danych jakąś biblioteką może być z uszczerbkiem dla wydajności, ale to można nadrobić odpowiednimi strukturami fizycznymi na bazie. Partycjonianie/indeksy/tuning parametrów/statystki bazy i inne ficzersy sprawią, że będzie hulało.

Na koniec przykłady w rodzaju "a miliony rekordów na raz" to po pierwsze bardzo rzadkie przypadki po drugie jak wystąpią to implementuje się je jako hurtownie lub podobne wydzielone składy danych.... nie raz faktycznie na relacyjnych motorach danych ale to inna bajka...

Racja, systemy OLTP są po to, żeby pracować na pojedynczych rekordach.
Ewentualnie w grę wchodzi wyszukiwanie, ale to tylko po to, żeby szybko znaleźć te pojedyncze.

ale odbiegamy od tematu: powtórzę więc: modelowanie danych w UML jest bez sensu skoro mamy ERD.

Zgadzam się.

Temat: Diagram E/R w UML?

Łukasz Kurowski:
A później przychodzą ludzie od hurtowni danych i mówią: "O kur.., ale burdel w danych" i liczą sobie odpowiednio więcej za czyszczenie danych i obsługę tych przypadków, gdzie ktoś nie miał kuli u nogi.

to dotyczy często sytuacji, w której ktoś podejmuje się "wyciągania" danych wprost z tablic nie mając pojęcia o logice tych danych, prościej jest poprosić dostawcę oprogramowania by napisał interfejs, który właściwe dane udostępni w postaci żądanej przez "ludzi od hurtowni"... (o ile taki interfejs już nie istnieje). Grzebanie w "cudzych" tablicach nie jest dobrym pomysłem al nie raz jest łamaniem licencji...

Co do więzów to można je sprawdzać na końcu transakcji, więc ta kula to nie taka wielka znowu. Pewnie, że można synchronizować dostęp i dbać o spójność w aplikacji, ale to tak jak KB zauważył wymyślanie koła na nowo.

nie, bo nie widzę niczego złego w implementacji całej logiki oprogramowania w aplikacji i nie ja jeden...

Zaś gadki szmatki o tym, że ewentualne błędy w aplikacji na testach się wykryje, to tylko o śmiech mnie przyprawiają. Kilka projektów w życiu widziałem :).

a czym się różni zły plan test od złego mechanizmu kontroli w bazie??

Nie Ty jeden masz za sobą jakieś projekty, jak jednak spełnić wymaganie by "oprogramowanie współpracowało z dowolna bazą danych SQL" a wymaganie takie ma jak najbardziej sens.

Temat: Diagram E/R w UML?

Łukasz Kurowski:

po pierwsze pojęcia "baza danych" i "relacyjny system zarządzania danymi" to nie to samo.

Jest 2011 rok... chyba wszyscy utożsamiają ze sobą te dwa terminy.

szkoda, i mów za siebie ... bazy mamy i relacyjne i nierelacyjne...

jeżeli projektuję system jako kilka odrębnych i niezależnych podsystemów czy modułów to relacyjny system można sobie wsadzić w .... dane są wymieniane poprzez interfejsy i kojarzone rzeczywistymi atrybutami (takimi jak PESEL, NIP, czy np. Imię, Nazwisko i imię ojca, i inne.) każdy z tym komponentów mogę niezależnie wstawić i usunąć z systemu, zamienić z innym komponentem bez uszczerbku dla reszty.

Nikt chyba nie komunikuje ze sobą bezpośrednio baz danych różnych systemów.

zacytuję Twoje słowa: "niejeden taki projekt widziałem"... po drugie opisałem sytuację gdy "system jest całkowicie zintegrowany pracując na jednej relacyjnej bazie danych" ...

Jeżeli jeden system zapyta drugi o numer zamówienia i nie znajdzie, to nie widzę żadnej tragedii w odpowiedzi "nie znaleziono"...

Nie wiem za czym ten argument przemawia... Jak nie ma, to nie ma :).

było to tu kwestionowane...

natomiast próba postawienia systemu składającego się z niezależnych komponentów na jednej relacyjnej bazie danych przeczy całemu projektowi, to jest niezależności tych komponentów. I wole operować całą logiką na poziomie aplikacji i utrwalać wyłącznie proste dane (np. rzeczony wzorzec active record) bo jestem niezależny od systemu utrwalania.

W życiu nie widziałem współdzielenia jednej bazy przed różne systemy. Wiele instancji dla wielu systemów owszem, ale to nic innego jak wirtualizacja.

a jak sądzisz jak są zbudowane "konfigurowalne wielomodułowe systemy ERP, w których moduły można sobie dobrać" otóż nie raz na prawdę można sobie dobrać pod warunkiem, że prawie wszystkie ze szczególnym uwzględnieniem modułu finansowego.

Nikt chyba nie naciska na kodowanie aplikacji z użyciem poleceń SQL, tudzież PL/SQL, czy innego języka specyficznego dla konkretnego produktu bazodanowego.

Z litości dla ich producentów nie podam tu nazw kilku "czołowych dostawców systemów ERP"...

Temat: Diagram E/R w UML?

Jarek Żeliński:
to dotyczy często sytuacji, w której ktoś podejmuje się "wyciągania" danych wprost z tablic nie mając pojęcia o logice tych danych, prościej jest poprosić dostawcę oprogramowania by napisał interfejs, który właściwe dane udostępni w postaci żądanej przez "ludzi od hurtowni"... (o ile taki interfejs już nie istnieje). Grzebanie w "cudzych" tablicach nie jest dobrym pomysłem al nie raz jest łamaniem licencji...

To dotyczy, niestety, obu sytuacji... Co do grzebania, często wykonuje się replikację zawartości baz i wtedy grzebać w tabelach trzeba.

nie, bo nie widzę niczego złego w implementacji całej logiki oprogramowania w aplikacji i nie ja jeden...

Obsługujesz transakcyjność w aplikacji? Co do więzów, to ta kula u nogi jak je określiłeś, wytyka błędy w działaniu aplikacji.

a czym się różni zły plan test od złego mechanizmu kontroli w bazie??

Czym się różni poprawny test plan od poprawnego mechanizmu kontroli? Pierwszy wykonuje człowiek dla kilku przypadków, co może być za mało, żeby wykryć, że jest coś nie tak, drugi wykonuje algorytm bazy danych dla każdego przypadku.

Nie Ty jeden masz za sobą jakieś projekty, jak jednak spełnić wymaganie by "oprogramowanie współpracowało z dowolna bazą danych SQL" a wymaganie takie ma jak najbardziej sens.

Jak napisałem gdzie indziej... Ja nie mam nic przeciwko przykryciu dialektów SQL jakąś biblioteką. Dobrze jak ta biblioteka umożliwia korzystanie z natywnego dla bazy dialektu SQL, ale to wykorzystanie też należy przykryć. Przepisanie tego na inny dialekt jest wtedy relatywnie łatwe.

Temat: Diagram E/R w UML?

Jarek Żeliński:
szkoda, i mów za siebie ... bazy mamy i relacyjne i nierelacyjne...

Może nie drążmy konwencji słownych. Zrób eksperyment i zapytaj na jakimś forum o bazy danych, których ludzie używają. Okaże się, że mówię za więcej niż 99% osób.

zacytuję Twoje słowa: "niejeden taki projekt widziałem"... po drugie opisałem sytuację gdy "system jest całkowicie zintegrowany pracując na jednej relacyjnej bazie danych" ...

Te projekty i implementacje, które widziałem nie pracowały na jednej instancji. Poza tym to nie jest cytat z mojej wypowiedzi. Jak już cytujesz to dosłownie i najlepiej z kontekstem.

było to tu kwestionowane...

Jak nie ma zamówienia dla klienta to ok, jak nie ma klienta dla zamówienia to nie jest ok. Nie wiem co konkretnie było kwestionowane.

a jak sądzisz jak są zbudowane "konfigurowalne wielomodułowe systemy ERP, w których moduły można sobie dobrać" otóż nie raz na prawdę można sobie dobrać pod warunkiem, że prawie wszystkie ze szczególnym uwzględnieniem modułu finansowego.

Tak naprawdę to jeden system z możliwością dobrania funkcjonalności. Marketingowe zagrywki i tyle.

Nikt chyba nie naciska na kodowanie aplikacji z użyciem poleceń SQL, tudzież PL/SQL, czy innego języka specyficznego dla konkretnego produktu bazodanowego.

Z litości dla ich producentów nie podam tu nazw kilku "czołowych dostawców systemów ERP"...

Miałem na myśli nowe systemy. Jak piszesz ERP od zera, to pisanie go tylko na jeden silnik bazodanowy znacznie ogranicza ilość potencjalnych nabywców. Jeśli ktoś popełnił taki system w PL/SQL, to tylko pozostaje współczuć. Ileś lat temu w czasach aplikacji typu "gruby klient", to mogło mieć uzasadnienie w bezpieczeństwie. Procedury pisane na bazie były jedną z metod ochrony przed modyfikacją logiki aplikacji przez hakerskie ataki.Łukasz Kurowski edytował(a) ten post dnia 05.11.11 o godzinie 20:19

Temat: Diagram E/R w UML?

Łukasz Kurowski:

nie, bo nie widzę niczego złego w implementacji całej logiki oprogramowania w aplikacji i nie ja jeden...

Obsługujesz transakcyjność w aplikacji? Co do więzów, to ta kula u nogi jak je określiłeś, wytyka błędy w działaniu aplikacji.

Generalnie dobrą praktyką jest implementacja całości logiki w aplikacji, tyle, że nie zawsze się da. W zasadzie prawie nigdy się nie da. Powody są proste:
- łatwa i wydajna obsługa transakcyjności
- wydajność

Nie Ty jeden masz za sobą jakieś projekty, jak jednak spełnić wymaganie by "oprogramowanie współpracowało z dowolna bazą danych SQL" a wymaganie takie ma jak najbardziej sens.

Jak napisałem gdzie indziej... Ja nie mam nic przeciwko przykryciu dialektów SQL jakąś biblioteką. Dobrze jak ta biblioteka umożliwia korzystanie z natywnego dla bazy dialektu SQL, ale to wykorzystanie też należy przykryć. Przepisanie tego na inny dialekt jest wtedy relatywnie łatwe.

Ta biblioteka łączy się z narzutem, odwrotnie proporcjonalnym do jakości jej projektu i kodu.

Odnośnie tematu wątku - też uważam, że UML jako narzędzie do modelowania E/R to bardzo nietrafiony pomysł. O ile jeszcze klasa jako model tabeli jest strawna, choć nie do końca poprawna, to nie widzę możliwości poprawnego modelowania więzów i zależności funkcyjnych w UML. Przecież paradygmat obiektowy to co innego niż paradygmat relacyjny, a różnice są na tyle duże, że ciężko wyobrazić sobie wspólne narzędzie dla nich.

Temat: Diagram E/R w UML?

Łukasz Kurowski:
Obsługujesz transakcyjność w aplikacji?

http://martinfowler.com/eaaCatalog/transactionScript.html

Temat: Diagram E/R w UML?

Łukasz Kurowski:
Może nie drążmy konwencji słownych. Zrób eksperyment i zapytaj na jakimś forum o bazy danych, których ludzie używają. Okaże się, że mówię za więcej niż 99% osób.

osobiście wyrosłem z rozstrzygania problemów projektowych przez aklamację

Nikt chyba nie naciska na kodowanie aplikacji z użyciem poleceń SQL, tudzież PL/SQL, czy innego języka specyficznego dla konkretnego produktu bazodanowego.

Z litości dla ich producentów nie podam tu nazw kilku "czołowych dostawców systemów ERP"...

Miałem na myśli nowe systemy. Jak piszesz ERP od zera, to pisanie go tylko na jeden silnik bazodanowy znacznie ogranicza ilość potencjalnych nabywców.

nie projektuję "ERP od zera bo to bez sensu :)"

Jeśli ktoś popełnił taki system w PL/SQL, to tylko pozostaje współczuć.

współczujesz właśnie kilku liderom rynku :), którzy popełnili swoje ERP w w dużej części w procedurach wbudowanych we Oracle...

Temat: Diagram E/R w UML?

a tak przy okazji, zdajecie sobie sprawę, ze oprogramowanie biznesowe można napisać be żadnej bazy w sensie motoru RDBMS/relacyjnej na zwykłych plikach? Pomijam wydajność w pewnych sytuacjach ale zapewniam że da się...

Temat: Diagram E/R w UML?

Chce Wam się jeszcze? :)

Fakt 1. Baza danych zawiera dane, a nic do tego nikomu jak są przechowywane ;) I nie musi to się odpytywać SQL-em.

Fakt 2. Można użyć stereotypu <<table>> na diagramie klas. Albo zrobić hybrydę ERD + UML/CD. To co, zamykamy temat, czy dalej będziecie się przekomarzać, kto ma większą bazę danych? ;)

Fakt 3. http://martinfowler.com/eaaCatalog/transactionScript.html - Martin Fowler przedstawił ten wzorzec w PoEAA. Nadaje się do prostych akcji na serwerze, na pewno nie do systemów klasy ERP. Obsługa transakcji to osobna sprawa. Oczywiście w aplikacji też transakcje są obsługiwane, w razie potrzeby. To nie jest jakiś byt typowy dla bazy danych. Inna sprawa to dobry dobór warstwy/miejsca w którym kontrola, czy obecność transakcji jest wymagana.

Widać, że jesteście wysokiej klasy specjalistami, ale mam miejscami wrażenie, że nie wiem już o czym dyskutujecie i sami też nieco chyba się plączecie w zeznaniach ;) Dlatego napisałem.

Temat: Diagram E/R w UML?

Jakub Fila:
Generalnie dobrą praktyką jest implementacja całości logiki w aplikacji, tyle, że nie zawsze się da. W zasadzie prawie nigdy się nie da. Powody są proste:
- łatwa i wydajna obsługa transakcyjności
- wydajność

Plus ryzyko popełnienia błędu.

Ta biblioteka łączy się z narzutem, odwrotnie proporcjonalnym do jakości jej projektu i kodu.

Coś za coś. Lepsza przenośność kodu pomiędzy bazami, albo brak narzutu.

Temat: Diagram E/R w UML?

Jarek Żeliński:
osobiście wyrosłem z rozstrzygania problemów projektowych przez aklamację

Na spotkaniach przeróżnych mówisz re-la-cy-jne bazy danych :)? Chciałbym to zobaczyć... ech, sorka, oczywiście usłyszeć.

nie projektuję "ERP od zera bo to bez sensu :)"

W miejsce ERP wstaw cokolwiek innego ;).

współczujesz właśnie kilku liderom rynku :), którzy popełnili swoje ERP w w dużej części w procedurach wbudowanych we Oracle...

W latach kiedy oni startowali serwery były pewnie porównywalne z obecnymi desktopami :). Zapewne kombinowali jak się dało.

Temat: Diagram E/R w UML?

Jarek Żeliński:

Łukasz Kurowski:
Obsługujesz transakcyjność w aplikacji?

http://martinfowler.com/eaaCatalog/transactionScript.html

Hmm? Czyli tak? Jak tak, to gratuluję jaj ;). Ogólnie ryzykowna sprawa, ale oczywiście się da jak najbardziej. Na studiach się bawiło w takie tematy, ale na profesjonalnym rynku zdaje się nikt, bez znaczącego podbicia stawki nie pójdzie na to.

Temat: Diagram E/R w UML?

Łukasz K.:
Widać, że jesteście wysokiej klasy specjalistami, ale mam miejscami wrażenie, że nie wiem już o czym dyskutujecie i sami też nieco chyba się plączecie w zeznaniach ;) Dlatego napisałem.

Nie dziwię Ci się, wystarczy popatrzeć na tytuł wątku i na tematy na które zeszło ;).

Temat: Diagram E/R w UML?

Obsługujesz transakcyjność w aplikacji?

http://martinfowler.com/eaaCatalog/transactionScript.html

Hmm? Czyli tak? Jak tak, to gratuluję jaj ;). Ogólnie ryzykowna sprawa, ale oczywiście się da jak najbardziej. Na studiach się bawiło w takie tematy, ale na profesjonalnym rynku zdaje się nikt, bez znaczącego podbicia stawki nie pójdzie na to.

ja tam tylko sprzątam ale warto zauważyć dwie rzeczy: dorobek autorów tych wzorców i fakt, że tak się jednak z powodzeniem robi... jeżeli ktoś nie zna tego (lub innych) wzorców projektowych, to ... o czym to świadczy? Chyba o tym, że być może doskonale zna inne technologie ale o obiektowych nie ma pojęcia...

a zapewniam, że obsługa transakcji to nie tylko motory baz danych (mimo, że ktoś niczego innego nie zna):
http://www.simple-talk.com/dotnet/.net-framework/.net-...

przyjemną cechą metod obiektowych jest to, że motor SQL jest tam "jakimś dodatkiem, możliwą metoda utrwalania", cała logiki jest skupiona w jednym miejscu (w aplikacji) i metoda utrwalania danych mogę wymienić na dowolną: na początku rozwoju korzystać z systemu plików, później przesiąść się na jakieś szybsze narzędzia (w tym bazy SQL ale tu służą raczej za system zarządzania tablicami ale jako motor relacyjny).

Warto się wiec zastanowić dlaczego:
- metody obiektowe tworzenia oprogramowania wygrywają ze strukturalnymi
- dostawcy system ERP (tam jest dużo transakcji i nie tylko) "wynoszą" logikę z baz danych do kodu...

jeżeli ktoś mimo to uważa, że świat IT się cofa w rozwoju to jego sprawa...

co mamy na myśli pisząc "rynek profesjonalny"? Bo dla mnie są to między innymi refaktoryzowane najnowsze system ERP, CRM itp. zapewniam, że ta refaktoryzacja nie przenosi logiki systemów do motorów baz danych a dokładnie odwrotnie...

wygląda mi na to, że nie jeden specjalista od baz SQL (nie neguję ich poziomu wiedzy) cierpi na syndrom młotkowego zamykając się w tej technologii, z drugiej strony nie ma w tym nic złego do czasu gdy ktoś mający nawet w małym palcu bazy SQL nie wygłasza opinii o czymś z czym ma mało do czynienia lub w cale....

dla mnie na szczęście motory SQlowe to jedna z iluś tam technologii z jakimi mam do czynienie i mam porównanie...Jarek Żeliński edytował(a) ten post dnia 06.11.11 o godzinie 08:16

Temat: Diagram E/R w UML?

Łukasz Kurowski:

Jarek Żeliński:
osobiście wyrosłem z rozstrzygania problemów projektowych przez aklamację

Na spotkaniach przeróżnych mówisz re-la-cy-jne bazy danych :)? Chciałbym to zobaczyć... ech, sorka, oczywiście usłyszeć.

z przykrością muszę zauważyć, że tak właśnie jest: posługuje się precyzyjnie tymi pojęciami, gdyż brak tej precyzji jest zmorą nie tylko wielu dokumentacji wymagań... wyobraź sobie, że w specyfikacji posługujesz się "swobodnie" pojęciem "bazy danych", jak sądzisz co dostaniesz w ofercie na tak opisany system? To sie nazywa "komunikacja" albo jakość przekazu (jak kto woli).

nie projektuję "ERP od zera bo to bez sensu :)"

W miejsce ERP wstaw cokolwiek innego ;).

to jest ważne, bo czym innym jest projektowanie brakujących funkcjonalności istniejących ERP/CRM itp. czy dedykowanych podsystemów a czym innym odkrywanie koła na nowo czego akurat raczej nie robię...

współczujesz właśnie kilku liderom rynku :), którzy popełnili swoje ERP w w dużej części w procedurach wbudowanych we Oracle...

W latach kiedy oni startowali serwery były pewnie porównywalne z obecnymi desktopami :). Zapewne kombinowali jak się dało.

nie dalej jak kilka miesięcy temu jeden z nich zachwalał swój "nowoczesny system" w mojej obecności...Jarek Żeliński edytował(a) ten post dnia 06.11.11 o godzinie 10:58

Temat: Diagram E/R w UML?

Jarek Żeliński:
po pierwsze pojęcia "baza danych" i "relacyjny system zarządzania danymi" to nie to samo.

po drugie mnie jako projektanta interesuje postawienie wymagań i wybór rozwiązania spełniającego je minimalnym kosztem a nie szukanie na siłę zastosowania dla jakiegoś relacyjnego systemu (motora) zarządzania danymi... (syndrom młotkowego) i tu tkwi różnica pomiędzy mną i wieloma tu,

Tak jak napisałem wcześniej. Wybieraj do swoich systemów takie repozytoria jakie uważasz za najlepsze. Co nie zmienia faktu, że musisz zadbać o spójność przechowywanych przez system danych i ją kontrolować. To obniża wydajność, ale jest bardzo pożyteczną sprawą. Cały czas nie rozumiem, dlaczego by nie stosować więzów integralności na rdbms, skoro wybrałeś go jako repozytorium dla swojego systemu/modułu.

A jak ktoś uważa, że kontrola spójności mu nie potrzebna, to się prędzej, czy później na tym przejedzie. Bo wyobraźnia użytkowników końcowych przerasta wyobraźnię zaszytą w każdym scenariuszu testowym.

jeżeli projektuję system jako kilka odrębnych i niezależnych podsystemów czy modułów to relacyjny system można sobie wsadzić w .... dane są wymieniane poprzez interfejsy i kojarzone rzeczywistymi atrybutami (takimi jak PESEL, NIP, czy np. Imię, Nazwisko i imię ojca, i inne.) każdy z tym komponentów mogę niezależnie wstawić i usunąć z systemu, zamienić z innym komponentem bez uszczerbku dla reszty.

Ale dlaczego nie kontrolować spójności danych pojedynczego modułu postawionego na rdbms w tym rdbms? Bo jak się okazuje to wiele systemów ma problem spójności na poziomie modułu. Nie mówiąc już jakie jaja się dzieję przy próbach integracji danych z kilku systemów/modułów...

Jeżeli jeden system zapyta drugi o numer zamówienia i nie znajdzie, to nie widzę żadnej tragedii w odpowiedzi "nie znaleziono"...

A ja widzę. Bo skąd się ten numer zamówienia na fakturze wziął? System go sobie wymyślił? Klasyczny brak spójności...

natomiast próba postawienia systemu składającego się z niezależnych komponentów na jednej relacyjnej bazie danych przeczy całemu projektowi, to jest niezależności tych komponentów. I wole operować całą logiką na poziomie ł
aplikacji i utrwalać wyłącznie proste dane (np. rzeczony wzorzec active record) bo jestem niezależny od systemu utrwalania.

Ale kto tu mówi o całej logice. Ja mówię o stosowaniu więzów integralności na rdbms. Bo to praktycznie żaden wysiłek, a wiele korzyści może przynieść.

Na koniec przykłady w rodzaju "a miliony rekordów na raz" to po pierwsze bardzo rzadkie przypadki

Ile to razy sam Ci musiałem o tym przypominać? ;-)

jak jednak spełnić wymaganie by "oprogramowanie współpracowało z dowolna bazą danych SQL" a wymaganie takie ma jak najbardziej sens.

Oczywiście, że ma sens. Ale co ma do tego stosowanie constraintów na rdbms? Przecież jak się będziesz chciał przenieść na inny rdbms to i tak ktoś Ci musi repozytorium tam zainstalować - w sensie utworzyć struktury. Potem przemigrować dane historyczne jak jest taka potrzeba. A klucz obcy, czy wymóg unikalności to literalnie po jednej dodatkowej linijce kodu na tabelę. I do tego takie podstawowe typy więzów masz na każdym rdbms. Więc w czym tu jest problem?

Coraz więcej jest systemów działających na wielu rdbms. Ale zawsze przemigrowanie się to jakiś wysiłek i utrzymanie kilku podstawowych więzów to żaden dodatkowy problem. Tym bardziej, że to dostawca systemu Ci pewnie wszystkie skrypty instalacyjne dostarczy.