Temat: Diagram E/R w UML?

Spójność danych powinna trzymać baza na poziomie constraint'ów a nie aplikacja w swojej obiektowej formie

kto tak twierdzi ?

Każdy, kto ma jakiekolwiek pojęcie o enterprise'owych serwerach bazodanowych.

...

- jest to niezwykle istotne z punktu widzenia wydajności.

czego ? systemu, zespołu produkcyjnego, czy zespołu rozwijającego system ?

Systemu.

Proponuje pewne ćwiczenie:
Załóżmy, że dzięki ww. optymalizacjom użytkownik oszczędza jedną minutę dziennie (przez jedną minutę pracuje zamiast czekać na odpowiedź systemu).

Zadanie: oszacować czas, po jakim optymalizacja się zwróci (zaoszczędzony czas), przy założeniu, że jej implementacja opóźniła wdrożenie systemu o tydzień.

... takie 'optymalizacje' bardziej szkodzą niż pomagają.

Temat: Diagram E/R w UML?

Jakub Wojt:

Spójność danych powinna trzymać baza na poziomie constraint'ów a nie aplikacja w swojej obiektowej formie

kto tak twierdzi ?

Każdy, kto ma jakiekolwiek pojęcie o enterprise'owych serwerach bazodanowych.

...

- jest to niezwykle istotne z punktu widzenia wydajności.

czego ? systemu, zespołu produkcyjnego, czy zespołu rozwijającego system ?

Systemu.

Proponuje pewne ćwiczenie:
Załóżmy, że dzięki ww. optymalizacjom użytkownik oszczędza jedną minutę dziennie (przez jedną minutę pracuje zamiast czekać na odpowiedź systemu).

Zadanie: oszacować czas, po jakim optymalizacja się zwróci (zaoszczędzony czas), przy założeniu, że jej implementacja opóźniła wdrożenie systemu o tydzień.

... takie 'optymalizacje' bardziej szkodzą niż pomagają.

Nie zgodziliby się z Tobą ludzie, którzy płacą mi za optymalizowanie serwerów bazodanowych. I nie chodzi tu o jedną minutę dziennie ale o zysk na raporcie z 20min. do 1sek. Gdyby Twoje podejście miało odzwierciedlenie w realnym świecie to musiałbym się przerzuć na wypasanie owiec zamiast prowadzić audyty wydajnościowe, optymalizacje i szkolenia z tej tematyki.

Temat: Diagram E/R w UML?

Kamil Stawiarski:

Jakub Wojt:

Spójność danych powinna trzymać baza na poziomie constraint'ów a nie aplikacja w swojej obiektowej formie

kto tak twierdzi ?

Każdy, kto ma jakiekolwiek pojęcie o enterprise'owych serwerach bazodanowych.

jeżeli baza danych jest "kluczem" całego "relacyjnego" systemu to tak, w przeciwnym wypadku 100% logiki i spójności tkwi w logice systemu, a baza to tylko stos prostych tabel.

- jest to niezwykle istotne z punktu widzenia wydajności.

czego ? systemu, zespołu produkcyjnego, czy zespołu rozwijającego system ?

Systemu.

Przy czym zaznaczam po raz kolejny - mówię o bazie danych jako pojedynczym repozytorium systemu.

chcesz mnie przekonać, że wydajność to kilometrowe zapytania SQL'owe? Bo wyraportowanie byle faktury wymaga jej sklejenia z kilkunastu tabel? Ciekawe sąd się wzięły proste jak drut modele danych do hurtowni...

Temat: Diagram E/R w UML?

Jarek Żeliński:

jeżeli baza danych jest "kluczem" całego "relacyjnego" systemu to tak, w przeciwnym wypadku 100% logiki i spójności tkwi w logice systemu, a baza to tylko stos prostych tabel.

Tu się zgadzamy.

- jest to niezwykle istotne z punktu widzenia wydajności.

czego ? systemu, zespołu produkcyjnego, czy zespołu rozwijającego system ?

Systemu.

Przy czym zaznaczam po raz kolejny - mówię o bazie danych jako pojedynczym repozytorium systemu.

chcesz mnie przekonać, że wydajność to kilometrowe zapytania SQL'owe? Bo wyraportowanie byle faktury wymaga jej sklejenia z kilkunastu tabel? Ciekawe sąd się wzięły proste jak drut modele danych do hurtowni...

Nie rozumiem skąd wziąłeś te "kilometrowe zapytania".

Dla aplikacji OLTP mamy normalizację, dla OLAP denormalizację w schematach gwiazdy co wynika z dopasowania schematu bazy do zapotrzebowań biznesowych. Ale bez względu na rodzaj projektowanej bazy zawsze istnieje pojęcie więzów integralności, partycjonowania i indeksowania.

Kilometrowe zapytania są zazwyczaj wynikiem nieznajomości dialektu SQL danego serwera bazodanowego - np. funkcji analitycznych lub modelowania SQL.Kamil Stawiarski edytował(a) ten post dnia 03.11.11 o godzinie 14:26

Temat: Diagram E/R w UML?

Czy to znaczy, że istnienie tych dwu światów przeczy możliwości rozszerzenia UML, tak by możliwe było modelowanie danych i nie doczekamy się standaryzacji tegoż np. w UML ver. X.Y ? Poza Amblerem są jeszcze inne propozycje (http://www.jeckle.de/files/RationalUML-RDB-Profile.pdf oraz nawiązanie do tego profilu: http://www.sparxsystems.com/resources/uml_datamodel.html) bazujące jednak na diagramie klas, chociaż nazwanym diagramem modelu danych i zapewne posiadające podobne wady.

obserwuję raczej trend całkowitego oddzielenia logiki obiektowego systemu od tego jak są utrwalane obiekty... UML zawiera diagram czynności, który po "sprofilowaniu" może posłużyć do modelowania procesów ale to bez sensu skoro mamy notację BPMN znacznie lepszą do tego celu, ale to się nazywa "syndrom młotkowego": jak ktoś ma tylko młotek wszystko kojarzy z gwoździem...

Nie wiem czy dobrze rozumiem, ale to argumenty na to, że rzeczy które da się zrobić w modelu obiektowym nie da się zrobić w relacyjnym?

tak

Argument o weryfikacji bardzo dobry. Rozumiem, że taki profil powinien być zdefiniowany formalnie, a to co zostało zaprezentowane przez Amblera/Rational to jedynie propozycje notacji?

tak myślę

Temat: Diagram E/R w UML?

Kamil Stawiarski:

chcesz mnie przekonać, że wydajność to kilometrowe zapytania SQL'owe? Bo wyraportowanie byle faktury wymaga jej sklejenia z kilkunastu tabel? Ciekawe sąd się wzięły proste jak drut modele danych do hurtowni...

Nie rozumiem skąd wziąłeś te "kilometrowe zapytania".

z dokumentacji z projektów i implementacji mapowania ORM na bazy relacyjne...

Dla aplikacji OLTP mamy normalizację,

jeżeli zakładamy model relacyjny i implementację funckcyjną

dla OLAP denormalizację w schematach gwiazdy co wynika z dopasowania schematu bazy do zapotrzebowań biznesowych.

to wynika raczej z tego, ze inaczej się nie da :), nie znam wymagania funkcjonalnego o nazwie: dane muszą być składowane w bazie relacyjnej znormalizowanej". RDMBS to implementacja utrwalania danych.

Ale bez względu na rodzaj projektowanej bazy zawsze istnieje pojęcie więzów integralności, partycjonowania i indeksowania.

gdzie to masz w obiektowym modelu dziedziny? Tu mamy tylko asercje i ograniczenia.

Kilometrowe zapytania są zazwyczaj wynikiem nieznajomości dialektu SQL danego serwera bazodanowego - np. funkcji analitycznych lub modelowania SQL.

ile znaków będzie miło zapytanie SQL do znormalizowanej bazy z fakturami by wykonać raport sprzedaży z podziałem na miesiące, kontrahentów i osoby wystawiające faktury?

Ile znaków będzie miało zapytanie generujące deklarację VAT7?

Temat: Diagram E/R w UML?

Jarek Żeliński:

Kilometrowe zapytania są zazwyczaj wynikiem nieznajomości dialektu SQL danego serwera bazodanowego - np. funkcji analitycznych lub modelowania SQL.

ile znaków będzie miło zapytanie SQL do znormalizowanej bazy z fakturami by wykonać raport sprzedaży z podziałem na miesiące, kontrahentów i osoby wystawiające faktury?

Ile znaków będzie miało zapytanie generujące deklarację VAT7?

Jeżeli dobrze Cię rozumiem, to według Ciebie baza powinna być jedną tabelką albo najlepiej cofnijmy się do ery plików płaskich?
A ile znaków będzie miał kod programu generującego VAT7? Ile znaków będzie miał program obiektowy, badający średnią sprzedaż podkategorii produktów w podziale na kwartały, prognozujący również sprzedaż kwartalną na najbliższy rok przy zadanych trendach wzrostu? Albo chociażby ile znaków będzie miał program liczący średnią kroczącą, jeżeli nie zamierzasz do tego stosować SQL'a?

Temat: Diagram E/R w UML?

Jeżeli dobrze Cię rozumiem, to według Ciebie baza powinna być jedną tabelką albo najlepiej cofnijmy się do ery plików płaskich?

nie, wg. nie tylko mnie na bazach danych świat się nie kończy :)

A ile znaków będzie miał kod programu generującego VAT7? Ile znaków będzie miał program obiektowy, badający średnią sprzedaż podkategorii produktów w podziale na kwartały, prognozujący również sprzedaż kwartalną na najbliższy rok przy zadanych trendach wzrostu? Albo chociażby ile znaków będzie miał program liczący średnią kroczącą, jeżeli nie zamierzasz do tego stosować SQL'a?

kod obiektowy, poprawnie zaprojektowany, będzie miał tę przyjemna cechę, że wprowadzanie nawet dużych zmian do funkcjonalności nie będzie rewolucją a ewolucją... po drugie użytkownika i mnie nie interesuje baza danych a owa faktura czy deklaracja VAT i zapewniam Cię, że kod realizujący odczytanie historycznej faktury może być naście razy prostszy niż SQL odtwarzający tę fakturę z bazy radzącej sobie z historią zmian adresów kontrahentów, numerów indeksowych produktów i takich tam drobiazgów....

Temat: Diagram E/R w UML?

Jakub Wojt:
Ok. Mój ostatni post w tym temacie. Nie będę walczyć z wiatrakami.

Jeśli ktoś robi model obiektowy funkcjonalności to powinien dostarczyć mi kompletny model obiektowy. W UML są wszystkie potrzebne rodzaje relacji. Jeśli ktoś nie potrafi zrobić modelu obiektowego w UML i posiłkuje się 'modelem danych' to niech się podszkoli albo znajdzie sobie inne zajęcie.

Jeśli ma być - obiektowo to nich będzie obiektowo ale od początku do końca. Jeśli ma być relacyjnie - niech będzie relacyjnie ale w całości.

'Model danych' sugeruje architektowi sposób przechowywania stanu modelu;
Relacyjna baza danych to jest jedyna metoda przechowywania danych. Są inne: np. bazy obiektowe, xml itd...

Znaczy się NIE JEST JEDYNA rozumiem, że to chochlik

Stąd moja prośba - niech analityk nie wchodzi w kompetencje architekta i nie narzuca pewnych technicznych rozwiązań.

No i wreszcie powiedziałeś coś mądrego!!!!! BRAWO!!! Analityk wymagań ma Ci opisać jak z punktu widzenia klienta widziane będą klasy, obiekty. To nawet nie musi mieć nic wspólnego z obiektami w implementacji, bo na potrzeby np optymalizacji działania ORM można to zamodelować inaczej - pod warunkiem zachowania izomorficzności i homomorficzności czyli działania w sposób opisany w analizie w aspektach istotnych dla projektu:)

Temat: Diagram E/R w UML?

Stąd moja prośba - niech analityk nie wchodzi w kompetencje architekta i nie narzuca pewnych technicznych rozwiązań.

technicznych...

No i wreszcie powiedziałeś coś mądrego!!!!! BRAWO!!! Analityk wymagań ma Ci opisać jak z punktu widzenia klienta widziane będą klasy, obiekty. To nawet nie musi mieć nic wspólnego z obiektami w implementacji, bo na potrzeby np optymalizacji działania ORM można to zamodelować inaczej - pod warunkiem zachowania izomorficzności i homomorficzności czyli działania w sposób opisany w analizie w aspektach istotnych dla projektu:)

ale przyznasz Mateusz, że jak analityk napisze "diagramem klas" logikę faktury w postaci agregatu z jego cechami to zmiana tego nie jest dobrym pomysłem (nie licząc faktycznie dodatków implementacyjnych)...

po drugie ORM jako bezpośrednie mapowanie obiektowej dziedziny na relacyjny model nie ma za bardzo sensu w rozumieniu jakichś "zaawansowanych" mapowań, w zasadzie sam mechanizm ORM (np. hibernate) staje się zbędny...

Temat: Diagram E/R w UML?

@Kamil i Jarek
rozmawiacie na dwa różne tematy, każdy z Was ma rację i zarazem jej niema

@Kamil
W aplikacjach biznesowych w wielu zastosowaniach relacyjne bazy danych wprowadzają istotne problemy. Ponieważ coraz więcej systemów jest obiektowych, a dane przechowujemy relacyjnie to godzimy się na pewne kompromisy. Albo kosztem normalizacji dane są przechowywane w sposób bardziej przyjazny obiektowości, albo kosztem narzutów na mapowanie dane są lepiej normalizowane.
Wynika z tego, że czasem np. FV lepiej przechowywać jako XML czy to na dysku czy w blobie.

@Jarek
Jak będziesz rozważał sens normalizacji i optymalizacji RDBMS na potrzeby aplikacji CRM posiadającej ca 1000 rekordów/transakcję to rzeczywiście jest to idiotyzm, ale w dużych systemach robi się raporty na joinowanych tabelach w których KAŻDA ma setki milionów rekordów.
Uwierz, że optymalizacja ma sens i w nosie z całą obiektowością, jeśli dzięki optymalizacji bazy raport zamiast generować się 20 minut generuje się w sekundę.

Pozostaje prosta decyzja biznesowa:
Koszt optymalizacji bazy: 1 mln EUR
Średni koszt modyfikacji danego modułu: 100 000 EUR
Narzut na modyfikację po optymalizacji - 30%, więc ok 30 000 EUR
Częstotliwość modyfikacji raz na kwartał
TCO miesięczne dla 1 roku z optymalizacją jest droższe o : 1mln EUR + 4*30 000 = 1 120 000 EUR

Koszt Rbh osoby czekającej na raport: 100 EUR
Czas generowania raportu przed optymalizacją: 20 min
Koszt raportu przed optymalizacją= 33,34 EUR

Czas generowania raportu po optymalizacji: 1 sek
Koszt raportu po optymalizacji = 0,03 EUR

oszczędność na raporcie = 33,31 EUR

granica opłacalności = 1 120 000 EUR/ 33,31 EUR = 33 623 raporty rocznie

oczywiście zakładając, że dostarczając więcej raportów przetwarzam ich więcej - ale to tylko kwestia odpowiedniej parametryzacji

UWAGA OGÓLNA
---------------------
Większość podejść inżynieryjnych ma swoje zalety i wady. Należy je analizować pod kątem konkretnej aplikacji (w sensie zastosowania, a nie oprogramowania) w biznesie z uwzględnieniem zmian KPI, TCO, ROI/NPV oraz RYZYKA.
Głupotą jest twierdzić, że bazy relacyjne są złe czy niepotrzebne.
Równie wielką głupota jest twierdzić, że normalizacja i optymalizacja baz jest zawsze potrzebna i uzasadniona.

Temat: Diagram E/R w UML?

ja tylko staram się zwracać uwagę na to, że relacyjny system składowania to jedna z możliwych metod implementacji utrwalania, i tu rację masz Mateusz,

ja niejako "walczę" z tezą, ze "baza SQL jest lepsza bo tak" bo raz tak a raz nie.... (mam tu na myśli zastosowanie konkretnego motora relacyjnej bazy do uzyskania jakiejś tam wydajności) ale czym innym jest świadome użycie motora Oracle czy DB2 w celu szybkiego przemiatania milionów rekordów a czym innym jest stosowanie na siłę relacyjnego modelu tylko po to by go użyć i znormalizować - są inne metody do wyboru (albo dlatego, że nie nie pojmuje obiektowego paradygmatu).

nawiązując do ER vs. UML (diagram klas) nie widzę żadnego sensu tworzenia kulawych profili dla UML w celu poprawnego zamodelowania danych w modelu relacyjnym, skoro jest dedykowane narzędzie jakim jest ERD. Niestety widuje takie potworki i potem słyszę najgłupsze tłumaczenie: bo mamy pakiet CASE UML coś tam i nie wydamy np. 100USD na plugin do ERD tylko opiszemy te dane w UML, albo nie wydamy 120USD na plugin BPMN tylko pomęczymy się i zrobimy potworka czyli model procesów z pomocą diagramu aktywności, to jest właśnie syndrom młotkowego.

Zabawa w profile i kontynuowanie niestandardowych metod pracy kosztuje znacznie więcej niż owe 100 czy 200 USD....

Temat: Diagram E/R w UML?

Jarek Żeliński:

Stąd moja prośba - niech analityk nie wchodzi w kompetencje architekta i nie narzuca pewnych technicznych rozwiązań.

technicznych...

pytanie co uznajemy za rozwiązanie techniczne:) wpadaj na piwo, Grzesiek mi ostatnio suszy głowę w tym temacie:)

No i wreszcie powiedziałeś coś mądrego!!!!! BRAWO!!! Analityk wymagań ma Ci opisać jak z punktu widzenia klienta widziane będą klasy, obiekty. To nawet nie musi mieć nic wspólnego z obiektami w implementacji, bo na potrzeby np optymalizacji działania ORM można to zamodelować inaczej - pod warunkiem zachowania izomorficzności i homomorficzności czyli działania w sposób opisany w analizie w aspektach istotnych dla projektu:)

ale przyznasz Mateusz, że jak analityk napisze "diagramem klas" logikę faktury w postaci agregatu z jego cechami to zmiana tego nie jest dobrym pomysłem (nie licząc faktycznie dodatków implementacyjnych)...

no jeśli zachowuje izomorfizm i homomorfizm to mogę sobie zmieniać jak chcę - bo wszystkie cechy muszę zachować;
Dla przykładu analityk w dokumentacji wymagań w ten sposób przedstawia FV:



Ponieważ z punktu widzenia księgowego ma wszystko czego mu potrzeba. (pomijam czy ma, bo to akurat jakiś roboczy fragment diagramu i akurat wszystkiego nie ma:P )

Projektant/Architekt mając na uwadze ograniczenia oraz inne wymagania (np. sposób użycia obiektu faktura w innych miejscach systemu) podejmuje decyzję projektową, że zaimplementuje fakturę następująco:




Nie realizuje więc on dokładnie koncepcji analityka, ale spełnia jego wymagania z dokłądnością do izo- i homo- morfizmu. Si?

Idąc dalej tym tropem na powyższym brakuje m.in. informacji o wartości podatku VAT dla poszczególnych stawek. Rolą analityka jest pokazać, że takie dane potrzebne są w systemie.

Rolą projektanta/architekta zdecydować czy będą przechowywane, czy wyliczane z pozycji.

po drugie ORM jako bezpośrednie mapowanie obiektowej dziedziny na relacyjny model nie ma za bardzo sensu w rozumieniu jakichś "zaawansowanych" mapowań, w zasadzie sam mechanizm ORM (np. hibernate) staje się zbędny...

Nie wnikam, bo to dla mnie za nisko:PMateusz Kurleto edytował(a) ten post dnia 03.11.11 o godzinie 20:57

Temat: Diagram E/R w UML?

po pierwsze zawsze projekt będzie kwestią "gustu i estetyki" podobnie jak projekt łazienki w domku :),

co do zasady: atrybut obiektu to także obiekt :)

oba diagramy: jeżeli założę, że faktura jest tworzona z pomocą fabryki z obiektów składowych drugi model wydaje się być "naturalniejszy" i chyba od razu bym taki zrobił.

osobna kwestią jest to jaką klasę obciążyć odpowiedzialnością za wiedzę o stawkach VAT, ja bym raczej proponował model, w którym produkty mają kody (atrybut) np. EKD (jakiś trwały klasyfikator), a stawka VAT była by wstawiana do faktury dopiero w momencie jej tworzenia na bazie aktualnego stanu prawa (aktualny VAT na bazie EKD produktu), wtedy zmiana VAT z 22 na 23 % była by banalnie prosta: zmiana jednego kawałka Fabryki faktur (do wielu np. stawek wzorzec strategia) towary w magazynie nietknięte w systemie.... od strony dziedziny systemu: VAT to element prawa a nie cecha produktu :)) tak więc gust i "sztuka" :)

P.S.
Rozważ to w kwestii wiadomego projektu jaki robimy ;)Jarek Żeliński edytował(a) ten post dnia 03.11.11 o godzinie 21:17

Temat: Diagram E/R w UML?

Jarek Żeliński:
ja niejako "walczę" z tezą, ze "baza SQL jest lepsza bo tak" bo raz tak a raz nie.... (mam tu na myśli zastosowanie konkretnego motora relacyjnej bazy do uzyskania jakiejś tam wydajności) ale czym innym jest świadome użycie motora Oracle czy DB2 w celu szybkiego przemiatania milionów rekordów a czym innym jest stosowanie na siłę relacyjnego modelu tylko po to by go użyć i znormalizować - są inne metody do wyboru (albo dlatego, że nie nie pojmuje obiektowego paradygmatu).

Ależ masz rację w 100%! Ja natomiast mówię, że skoro jest już baza relacyjna to traktowanie jej tylko i wyłącznie jako płaski kontener na dane będzie w wielu przypadkach prowadziło do zakleszczeń i problemów wydajnościowych.

zapewniam Cię, że kod realizujący odczytanie historycznej faktury może być naście razy prostszy niż SQL
odtwarzający tę fakturę z bazy radzącej sobie z historią zmian adresów kontrahentów, numerów indeksowych
produktów i takich tam drobiazgów....

To już zależy od wykorzystywanego schematu bazy a przede wszystkim od silnika - jeżeli historia zmian adresów kontrahentów jest zaimplementowana z użyciem Oracle Flashback Tablespace to zapytanie retrospektywne będzie wiele razy prostsze niż kod w dowolnym języku programowania 3G.Kamil Stawiarski edytował(a) ten post dnia 03.11.11 o godzinie 23:55

Temat: Diagram E/R w UML?

Kamil Stawiarski:
Ja natomiast mówię, że skoro jest już baza relacyjna to traktowanie jej tylko i wyłącznie jako płaski kontener na dane będzie w wielu przypadkach prowadziło do zakleszczeń i problemów wydajnościowych.

nie znam tych przypadków ;) polecam to:
http://en.wikipedia.org/wiki/Active_record_pattern

i warto zawsze dodawać czy pisząć "baza relacyjna" mamy na myśli model relacyjny czy motor relacyjny :) bo to zupełnie różne rzeczy. Z motorami nie dyskutuję, z modelami nie raz tak ;)

zapewniam Cię, że kod realizujący odczytanie historycznej faktury może być naście razy prostszy niż SQL
odtwarzający tę fakturę z bazy radzącej sobie z historią zmian adresów kontrahentów, numerów indeksowych
produktów i takich tam drobiazgów....

To już zależy od wykorzystywanego schematu bazy

to zależy od projektu: prosty obiekt z fakturą "twardą" (niemodyfikowalne, proste redundantne dane, faktura jako plik XML, inne), to "linijka" kodu i natychmiastowy odczyt, do tego żadnego problemu z historia np. adresów bo ten adres jest tam na żywca wpisany więc nie żadnego słownikowania, jak w hurtowni danych.

ale podkreślam tu wkraczamy w styl projektowania a nie w "jedynie słuszne zasady".

to zapytanie retrospektywne będzie wiele razy prostsze niż kod w dowolnym języku programowania 3G.

patrz wyżej...

Temat: Diagram E/R w UML?

Jarek Żeliński:
to zależy od projektu: prosty obiekt z fakturą "twardą" (niemodyfikowalne, proste redundantne dane, faktura jako plik XML, inne), to "linijka" kodu i natychmiastowy odczyt, do tego żadnego problemu z historia np. adresów bo ten adres jest tam na żywca wpisany więc nie żadnego słownikowania, jak w hurtowni danych.

Nie chcę się "wymądrzać", ale jeżeli chodzi o "historie" np. faktur, to przecież każdy system wystawiający FV, zgodny z Ustawą o Rachunkowości, musi spełniać zasadę "historii", czyli musi przechowywać dane w sposób historyczny (inna historia, że to często przeczy wielu zasadą "wydajnego", "zgodnego ze sztuką projektowania", "zgodnego z najnowszymi trendami programistycznymi" idt, itp. sposobu pisania Aplikacji). Tylko, że najważniejsze w tym wszystkim jest to, aby produkt spełniał swoje zadanie, jeśli robi to szybko i sprawnie to jeszcze lepiej.

Temat: Diagram E/R w UML?

ROMAN WILK:

Jarek Żeliński:
to zależy od projektu: prosty obiekt z fakturą "twardą" (niemodyfikowalne, proste redundantne dane, faktura jako plik XML, inne), to "linijka" kodu i natychmiastowy odczyt, do tego żadnego problemu z historia np. adresów bo ten adres jest tam na żywca wpisany więc nie żadnego słownikowania, jak w hurtowni danych.

Nie chcę się "wymądrzać", ale jeżeli chodzi o "historie" np. faktur, to przecież każdy system wystawiający FV, zgodny z Ustawą o Rachunkowości, musi spełniać zasadę "historii", czyli musi przechowywać dane w sposób historyczny (inna historia, że to często przeczy wielu zasadą "wydajnego", "zgodnego ze sztuką projektowania", "zgodnego z najnowszymi trendami programistycznymi" idt, itp. sposobu pisania Aplikacji). Tylko, że najważniejsze w tym wszystkim jest to, aby produkt spełniał swoje zadanie, jeśli robi to szybko i sprawnie to jeszcze lepiej.

to wszystko prawda ale dodajmy do tego jakim kosztem zostanie to wymaganie zaimplementowania (opracowanie, testowanie, pielęgnacja) i jaki będzie koszt konserwacji i rozwoju systemu.

w zasadzie gotowy system spełniający dane wymagania to "czarna skrzynka" dla użytkownika, problem w tym, że koszty mogą być różne, do tego wielu zapomina o jednej rzeczy" koszt rozwoju i integracji. Prosty przykład:

- jakim kosztem w oby wersjach wykonany zostanie interfejs pozwalający na import faktur wystawionych w innym systemie np. nowym CRMie? (i czy w ogóle będzie to możliwe...)

- jakim kosztem oddzielimy podsystem magazynowy od podsystemu FK wdrażając nowy system logistyczny... (i czy będzie to możliwe)
- ...

zgadzam się z tym, że efekt końcowy może być "taki sam" ale obserwuje oferty firm integratorskich od lat i rozrzut ofert w odpowiedzi na te same wymagania bywa kilkukrotny... a ja wyznaję zasadę rynkową: system ma spełniać wymagania przy optymalnych kosztach a jednym z wymagań ZAWSZE jest u mnie możliwość wprowadzania zmian i rozszerzeń oraz możliwość integracji z innymi systemami, to jest system MUSI mieć API pozwalające na dostęp do obiektów dziedziny systemu i nie tylko do odczytu. Po trzecie zabraniam (w swoich projektach ;)) integracji poprzez współdzielenie danych.

moje doświadczenie mówi, że problemem większości projektów IT jest nie tyle dostarczenie produktu (bo też) a wprowadzanie zmian do niego i integrowanie z innymiJarek Żeliński edytował(a) ten post dnia 04.11.11 o godzinie 08:17

Temat: Diagram E/R w UML?

Jarek Żeliński:

moje doświadczenie mówi, że problemem większości projektów IT jest nie tyle dostarczenie produktu (bo też) a wprowadzanie zmian do niego i integrowanie z innymi

Jak już dawno, dawno temu pisałem, mam zupełnie odmienny pogląd od Twojego, raczej moim zdaniem firmą zależy na ujednoliceniu niż różnicowaniu posiadnaych rozwiązań (szczególnie myślę o systemach ERP, jedna baza danych (bynajmniej jeśli chodzi o producenta tej bazy) na OnLine), jeden dostawca, jedna SLA, nie ma rozmywania odpowiedzialności w przypadku problemów z Aplikacją.

Ps.
Nie mam zamiaru rozwijać tego tematu :)

Temat: Diagram E/R w UML?

ROMAN WILK:

Jarek Żeliński:
moje doświadczenie mówi, że problemem większości projektów IT jest nie tyle dostarczenie produktu (bo też) a wprowadzanie zmian do niego i integrowanie z innymi

Jak już dawno, dawno temu pisałem, mam zupełnie odmienny pogląd od Twojego, raczej moim zdaniem firmą zależy na ujednoliceniu niż różnicowaniu posiadnaych rozwiązań (szczególnie myślę o systemach ERP, jedna baza danych (bynajmniej jeśli chodzi o producenta tej bazy) na OnLine), jeden dostawca, jedna SLA, nie ma rozmywania odpowiedzialności w przypadku problemów z Aplikacją.

to zawsze bezie temat dyskusyjny, i nie widzę tu "jedynie słusznego rozwiązania". Z rynku na jakim mam okazje funkcjonować wiem, ze nie spotykam firmy, którą da się obsłużyć jednym zintegrowanym ERP (wczoraj byłem w banku, łącznie PONAD STO APLIKACJI). Każda większa firma lub urząd obsługuje swoje obszary specyficznym dla obszaru działania podsystemem.

Nie znam firmy, nawet malutkiej, która miała by mini ERP, który zastępuje MS/OO Office...

Ps.
Nie mam zamiaru rozwijać tego tematu :)

bo to nie ma sensu, każdy ma swój rynek i do niego się dopasowuje, np. takie cloud computing (pomijam tu marketingowy bełkot) to nic innego jak integracja na poziomie API i współdziałanie.Jarek Żeliński edytował(a) ten post dnia 04.11.11 o godzinie 09:22