W dniu 2014-04-18 19:38, wloochacz pisze:
W dniu 2014-04-18 15:18, Zgr pisze:
(...)
Przy bardziej obciążonych lub większych.
True, ale z tego co piszesz, to narzut Optimu może być znaczny na bazę
danych - a tu więcej RAMu i szybkie dyski się kłaniają.
Ale 32GiB to nie powinno być problemem... Tyle, że ja kompletnie nie mam
pojecia jak Optima współpracuję z bazą danych.
Powiem tak - miałem kiedyś firmę, która na Windows Server 2000 32bit z
SQL Serverem 2000 obsługiwała ok. 120-140 klientów.
Wielkość bazy - ok. 40 GiB.
I to działało nawet nieźle; dlatego jak widzę co poniektóre wymagania w
stylu "najwydajniej Optima pracuje na komputerze z procesorem CoreI7 z 4
GB RAM lub więcej" to się pytam - WTF?
Aktualne wymagania Optimy (tylko klient), to Win XP SP2, 1GB RAM.
Jeśli na stanowisku ma być Optima + SQL Express, to pasuje 2 GB RAM.
Procesor - może być Celeron, ale wtedy czeka się dłuuugo na odpowiedź ;)
Na stanowiska u klientów kładę poleasingowe C2D z zegarem powyżej 2GHz
(najczęściej Delle) i pracują bezproblemowo.
(...)
Dawny CDN, teraz Comarch, system Optima.
System ponoć nieźle napisany, dość dobrze zoptymalizowany. Większość
operacji SQL wykonywana na serwerze.
Optima?
Jeśli tu:
http://blog.alpol.net.pl/2011/10/jak-przyspieszyc-comarch-optima-2010/
piszą prawdę, to ja dziękuję za takie "optymalizacje".
Źle trafiłeś.
Akurat Optima w werski 2010 zastąpiła wersję 17.x.
Optima do wersji 17 włącznie była napisana w Clarionie.
Wersja 2010 - to pierwsza wersja napisana w dotNecie.
Niestety, z różnych względów większość operacji była liczona na
klientach, stąd też sporo rzeczy działało nawet kilkadziesiąt(!) razy
wolniej, niż w wersjach Clarionowych.
Później następowała optymalizacja, tak, że kilka lat później wersja
2012.x już zaczęła "doganiać" szybkością wersję 17.
Teraz jest v. 2014.3.
Tak informacyjnie:
Kilkanaście lat temu grupa programistów odeszła z ówczesnego CDN-u i
założyła swoją firmę - Soneta (system Enova).
Od początku zaczęli pisać oprogramowanie w dotNecie.
I tutaj widać, co potrafi dobry programista:
Enova potrzebuje Windowsa 98, IE6, .NETFramw. 2, pracuje na MSDE lub
MySQL. Jest porównywalna funkcjonalnie z Optimą. Jej instalacja trwa
kilkadziesiąt sekund.
Natomiast Optima pisana przez zdecydowanie większy sztab ludzi (ale
generalnie ludzi młodych, po studiach) - wymagania ma o niebo większe.
Powiedzmy sobie szczerze - Optima to dość prosty system
handlowo-magazynowy. Zalecanie maszyny z Core I3/5/7 do takiego czegoś
to... maskara jakaś ;-)
Tak, jak pisałem, rzeczywiste wymagania nie są aż tak duże.
Jedyna rzecz, co obciąża, to serwer analiz (kostka Olapowa), drugi
(zewnętrzny) program.
Optimy (i Enovy) nie nazwałbym "prostym" programem - potrafi sporo
więcej niż różne Wf-Magi czy Symfonie.
Dzięki sprawdzaniu spójności na poziomie samej bazy (np. Triggery) -
ciężko jest "zepsuć" bazę, nawet gmerając bezpośrednio w danych.
Bardzo konfigurowalne systemy, możliwość prostego dopisywania własnych
funkcji w SQL, VB, C++, itp. Silnik raportów Crystal - można wrzucać
własne, oprócz tego prosty Genrap, gdzie nawet "blądynka" (błąd
zamierzony) dowolnej płci potrafi przerobić istniejący wydruk wg.
własnych potrzeb. Doskonała integracja z systemami sprzedaży on-line, z
płatnościami - jak się potrafi, to można naprawdę b. wiele ustawić pod
klienta.
A jak jest za mało - można zmigrować pod ERP np. Comarch XL.
Są firmy, które mają po 40 ludków siedzących na jednym starym ML 350 G3
i jakoś to wyrabia.
Problem zaczyna się przy "dużych" bazach danych, mających po kilka
milionów rekordów w największych tabelach - wtedy macierz nie wyrabia z
wydajnością.
Tabel jest blisko 400, sporo kluczy i indeksów, bardzo dużo triggerów.
Samo dopisanie pozycji do faktury (z poziomu Optimy) generuje
kilkadziesiąt procedur (?) - m.in. sprawdzanie rezerwacji, sprawdzanie
stanów magazynowych, sprawdzanie płatności, rabatów, itd, itd.
Aż z ciekawości sprawdziłem:
Comarch Optima - 350 tabel
Comarch XL w jakiejś starszej wersji - 469 tabel
Enova - 326
Wapro - 435
Subiekt - 570
Ale to jeszcze o niczym nie świadczy.
Widziałem (nie pamiętam, gdzie) pola typu DECIMAL(15,2) używane do
przechowywania flagi, gdzie wystarczyłoby pole SMALLINT.
Podobnie, można "przytkać" bazę wrzucając dane binarne, typu PDF czy JPG.
Subiekt potrafi "zgubić" rekordy. Potrafi czasem sprzedać towar, którego
nie ma na stanie.
Wapro znów potrafi mieć problemy ze spójnością rozrachunków.
Na szczęście takie rzeczy nie zdarzają się w CDN-ie (Comarch).
Zastanów się - naprawdę sądzisz, że to jest dobrze napisane?
Znam taki system, który też "wszystkie operacje wykonywał na serwerze".
Jakiekolwiek pierdnięcie - wywoływana była SP, która wołałe następne SP
i tak w kółko Macieju...
Efekt? jedna wielka KUPA!
Akurat tam architekt systemu zapomniał, że baza SQL jest zorientowana na
przetwarzanie ZBIORÓW danych, a nie pojedynczych wierszy...
No ale co zrobić - taki będziesz miał system, to muszisz z nim żyć.
No właśnie.
Czasami (mówię z praktyki) lepiej się sprawdzi prostszy system, ale z
dobrym wsparciem producenta i z dobrą dokumentacją programistyczną niż
"kombajn" ERP, w którym "coś się samo dzieje" i nikt, włącznie z
producentem, nie wie o co chodzi.
Już paru klientów migrowałem z różnych "wynalazków" m.in. na systemy
CDN, więc chyba nie są to czcze wymysły ;)
A przetwarzanie wierszy (i gadanie o kursorach) to chyba domena
programistów, zaczynających od Clippera ;)
Chociaż ja też do tej pory nie odróżniam indeksu od klucza w SQL.
Czy chodzi o to, że klucz "leci" po kilku polach?
(...)
--
Pozdrawiam.
Adam
|