Article View: pl.comp.lang.delphi
Article #334691Re: Dlaczego w ERP'e MemoryDataSet moim zdaniem jest optymalny
From: wloochacz
Date: Wed, 11 Jan 2012 10:31
Date: Wed, 11 Jan 2012 10:31
140 lines
7777 bytes
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-mailReferences:
<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