🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: pl.comp.lang.delphi
Article #334691

Re: Dlaczego w ERP'e MemoryDataSet moim zdaniem jest optymalny

#334691
From: wloochacz
Date: Wed, 11 Jan 2012 10:31
140 lines
7777 bytes
W dniu 2012-01-11 07:04, Roman Wilk pisze:
> Witam,
> ponieważ wlochacz, jest bardzo ciekawy dlaczego (a noc dluga byla i w
> chwilach relaxu, cos tam napisalem), dlatego ponizej podaje kilka
> zasadniczych powodow, dla ktorych moim zdaniem przyjeta przeze mnie
> filozofia w moim projekcie jest optymalna (wlochacz to material do
> przemyslen dla Ciebie :-))
Dzięki!

> Projekt to klasa Aplikacji ERP/MRP/CRM
>
>     (wymieniam tylko to co powinno pozwolic Ci zrozumiec dlaczego dane
> pobrane lokalnie jest optymalnie trzymac w MemoryDataSet,
Wymieniłeś, to prawda ale niestety dalej nie bardzo rozumiem dlaczego 
tak... Ale o tym dalej.

>     oczywiscie dane sa pobierane automatycznie w oparciu o relacje
> zdefiniowane w DM na TIBTable.
O!
Zaskoczyłeś mnie, czyli mam rozumieć że taki DM wygląda coś jak to?
http://www.miramar.com.pl/download/dFLEX/HorrorDataModule.png
Uprzedzając pytania - obrazek znalazłem w sieci...

> Poza tym w takim rozwiazaniu podmiana
>     bazy danych nie jest duzym problemem, co tez na pewnym etapie
> tworzenia projektu bylo brane pod uwage)
Jasne; a tak z ciekawości, na jakich bazach działa Twoja aplikacja u 
klientów poza Firebirdem?

> 1. Funkcjonalnosci :
/ciach/

> 3. Ksiega handlowa - full wypas, srodki trwale, platnosci
> elektroniczne, automatyczne wyliczenie roznic kursowych (dla ludzi
> kodujacych ERP'y, zmora,
>     szczegolnie kompensowanie tych transakcji)
Wszystko powyższe nie ma nic wspólnego dlaczego oparłeś to na CDSach, to 
ogólny zares funkcjonalności - dla nas w tej dyskusji bez znaczenia.
Innymi słowy - to wszystko powyższe można zrealizować na 100 różnych 
sposobów, a ten który wybrałeś nie gwarantuje tego iż to zadziała 
poprawnie lub lepiej niż inne...

> 1. Sorotwanie zawartosci dokumentu (potrzebne utworzenie indeksow,
> czesto dynamicznie i ponumerowanie pozycji dokumentu zgodnie z nowym
> porzadkiem)
Każdy, powtarzam, każdy nowoczesny DataSet potrafi sortować, filtrować, 
agregować i co tam jeszcze chcesz po stronie klienta.
A jak nie potrafi, to można go podpiąć od kontrolki która potrafi - np. 
Developer Express Quantum Grid.

> 2. Agregowanie zawartosci dokumentu (sumowanie po indeks, EAN, cena,
> ilosc, ewentualnie innych definiowalnych kryteriach)
Jak wyżej.

> 3. Komentowanie pozycji dokumentow (pola blob), sumy posrednie
> bezposrednio w widoku dokumentu .... (czyli suma np. po x- pozycjach)
Jak wyżej.

> 4. Pelna walidacja kompletnej postaci danych (zaokraglenia, wartosci w
> walucie, sprawdzenie zgodnosci dekretu WN/MA.
>     Z tego powodu dokumenty zazwyczaj (jedyne sluszne rozwiazanie) sa
> sumowame w podstawach stawek podatku VAT (od netto lub od brutto)).
> Dokument w walucie, dodatkowo
>     musi byc przeliczony do postaci odpowiadajacej zasadzie "wydruk
> musi sie zamykac w walucie dokumentu", co oznacza przeliczenie PLN na
> walute (jezeli masz rabaty
>     rabat do cen w pozycjach to sytuacja sie dodatkowo komplikuje (kurs
> to liczba #.0000, wynik to liczba #.00), z czego ponownie z waluty na
> PLN, aby zaksiegowac w PLN)
Jak wyżej; tak sobie myślę, że jakbyś nie potrzebował 
filtrowania/sortowania w DataSecie po stronie klienta to mógłbyś to 
zrealizować na czystym IBX tylko i wyłącznie wykorzystując CachedUpdates...
Natomiast gdybyś wykorzystał FIBPLusy zamiast IBX to miałbyś to co masz 
(i znacznie więcej) bez konieczności pakowania wszystkiego do CDSa.
No, ale w takim przypadku nie da się wykorzystać innej bazy danych -0 za 
to szybkość obsługi danych wzrosła by znacznie.
Jak znacznie? W pewnych przypadkach pewnie i kilkadziesiąt razy...

> 5. Obsluga transakcji (pelna kontrola atomowosci transakcji w ujeciu
> Firebird'a, czyli transakcji wspolbieznych)
A tego nie rozumiem - co takiego ma CDS, że zapewnia kontrolę atomowości 
transakcji?
Myślałem, że każda transakcja jest atomowa - z definicji.

> 6. Pelna transparentnosc Aplikacji w stosunku do bazy danych (oznacza
> n-edycji tego samego dokumentu, w tym samym czasie, z obsluga
> ewentualnych wyjatkow transakcyjnych)
Hmm... niezupełnie rozumiem.
Znaczy, co - że można edytować ten sam dokument w tym samym czasie przez 
wielu różnych użytkowników?
I co to dokładnie znaczy "z obsługą ewentualnych wyjątków transakcyjnych"?
Jak mogłoby być inaczej, skoro masz podejście optymistyczne do 
blokowania zasobów; jeśli by było bez obsługi błędów to ten program by 
po prostu nie działał.
Tak czy siak - co to ma wspólnego z CDSem?

> 7. Obsluga mozliwie najmniejszej liczby komponentow TTransaction (tzn.
> model jednej globalnej transakcji w obrebie calej Aplikacji)
To też nie ma nic wspólnego z CDSem, IMHO.
To jest opis Twojej architektury app - a co do najmniejszej liczby 
komponentów TIBTransaction to... Opinie są różne :)
Ja np. nie mam żadnego komponentu typu transaction, ale transakcji jako 
takich odpalonych równocześnie jest zazwyczaj ok. kilku do max kilkunastu.

> 8. Kontrola FIFO / LIFO na okreslony dzien
Ekstra - ale co to ma wspólnego z CDSem?!

> 9. Baza danych w tym modelu, nie wie co jest w edycji, jest tylko i
> wylacznie uzywana do skladowania danych i ich raportowania
Nie jestem przekonany do słuszności takiego modelu.
Jak łączysz dane pochodzące z wielu tabel, skoro używasz prostego 
mapowania tabela -> DataSet?

> 10. Wygodna obsluga laczenia dokumentow w jeden dokument (np. FV do n
> Wz)
Nie rozumiem co to zdanie oznacza, a co za tym idzie - dlaczego tu się 
znalazło.

> 11. W modelu opartym na lokalnym przechowywaniu zawartosci kazdego
> dokumnetu (kazdego obiektu biznesowego projektu), bardzo prosto
> zbudowac API Aplikacji,
>      po prostu tworzysz obiekt nie pokazujac go uzytkownikowi i
> wywolujesz zdarzenia tak jak by uzytkownik obrabial go. Masz zachowana
> kontrole integralnosci
>      danych i spojnosc kodu w obsludze tego typu operacji. Memory
> DataSet'y zawsze maja opcje zapisu / odczytu z pliku ... (np. XML)
Nie wiem gdzie byłeś przez ostatnie kilka lat, ale takie same możliwości 
mają "normalne" DataSet'y w każdej porządnej bibliotece bazodanowej.
Wróć - możliwości mają dużo większe i są kilkadziesiąt razy szybsze bez 
niepotrzebnego narzutu na dodatkowy kod, np. taki AnyDAC.

I teraz dalej pozostaje aktualne pytanie, dlaczego to zrobiłeś w ten sposób.
Rozumiem że to działa, ale wybacz - dla mnie to nie wygląda na zbyt 
wygodny system pobierania i obrabiania danych...
Wygląda to tak, jakbyś do tej pory znał i korzystał tylko z IBXów, żeby 
było ciekawiej do obsługi Firebirda z którym to IBX nie działają, że tak 
powiem, ze wsparciem producenta...

-- 
wloochacz
Technical Details
Message-ID: <jejoea$3d6$1@inews.gazeta.pl>
Path: mbox-mo1.pugleaf.net!news-archive.icm.edu.pl!news.gazeta.pl!not-for-mail
References: <d6b9cb32-993a-470f-949f-9f6587ff0c86@m20g2000vbf.googlegroups.com>

Show Full Headers
Complete Article Headers
Path: mbox-mo1.pugleaf.net!news-archive.icm.edu.pl!news.gazeta.pl!not-for-mail
From: wloochacz <wloochacz@nospam.nie.gmail.com>
Newsgroups: pl.comp.lang.delphi
Subject: Re: Dlaczego w ERP'e MemoryDataSet moim zdaniem jest optymalny
Date: Wed, 11 Jan 2012 11:31:33 +0100
Organization: "Portal Gazeta.pl -> http://www.gazeta.pl"
Lines: 140
Message-ID: <jejoea$3d6$1@inews.gazeta.pl>
References: <d6b9cb32-993a-470f-949f-9f6587ff0c86@m20g2000vbf.googlegroups.com>
NNTP-Posting-Host: mainframe.rene.com.pl
Mime-Version: 1.0
X-Trace: inews.gazeta.pl 1326277898 3494 193.239.124.200 (11 Jan 2012 10:31:38 GMT)
X-Complaints-To: usenet@agora.pl
NNTP-Posting-Date: Wed, 11 Jan 2012 10:31:38 +0000 (UTC)
X-User: wloochacz
In-Reply-To: <d6b9cb32-993a-470f-949f-9f6587ff0c86@m20g2000vbf.googlegroups.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit