W dniu 2014-04-19 13:46, Adam pisze:
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.
Zależy która Symfonia i który WF-MAG - akurat ten ostatni działa bardzo
ładnie (w sensie - wydajnie), mam wrażenie, że ładniej od Enovy i Optimy.
Ale ja tam się nie znam, zazwyczaj mam styczność z trochę większymi
systemami...
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.
OKiej - to ja mam pytanie :-)
Mam potrzebę integracji swojego systemu z CDN XL (o przepraszam,
Comparch ERP XL) w najnowszej wersji.
Nie chcę robić partnera w Comarchu dla jednej integracji, a nie posiadam
ani wersji demo ani dokumentacji do bazy danych CDN XL.
Czy ktoś z was móglby mnie poratować w tej sytuacji?
Głownie chodzi o napisanie widoków do pobierania danych o zleceniach
produkcyjnych.
Kwestia sposobu rozliczenia do dogadania.
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.
Wystarczyłoby - a i pewnie, ale tak się nie projektuje dużego systemu.
Najpierw definiujesz sobie własne typy danych (domneny), a potem ich
używasz. jakbym miał w kazdym polu każdej tabeli okreslać typ i rozmiar
to by mnie k...wica strzeliła bardzo szybko :)
Coś za coś - wydajność nie jest jedynym kryterium, chodzi też o
utrzymanie i prosty rozwój systemu.
Podobnie, można "przytkać" bazę wrzucając dane binarne, typu PDF czy JPG.
To jest mit ;-)
Baza nie zostanie przytkana, tylko drastczynie zmieni się jej rozmiar -
ale to ma raczej niewleki wpływ na wydajność... Oczywiście wszystko
zależy od tego, w jaki sposób będziemy tego używać.
Jeśli takich danych jest naprawdę dużo, to MSSQL oferuje bardzo fajny
mechanizm do obsługi takich danych. Mam na myśli FileStream, a od wersji
2012 FileTables - i to jest naprawdę cool!
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?
Nie; jedne i drugie moga być wielopolowe.
Klucze to ograniczenia, a indeksy to mechanizm podobny do skorowidzu w
książce, którego podstawowym celem jest przyspieszenie operacji
wyszukiwania danych w tabelach (ale nie tylko w tabelach, doczytać o
tzw. widokach zmaterializowanych).
Klucze moga być indeksami, ale moga nimi nie być - zależy od bazy danych.
Np w MSSQL klucz podstawowy (primary key) jest jednocześnie ogranczeniem
(constraint) i indeksem (i też specjalnym typem indeksu, tzw. clustered
index).
Klucze obce (foreign keys), to mechanizm zapewniający integralność
referecyjną (oraz kaskadową aktualizację/usuwanie) pomiędzy danymi w
tabelach, są tylko ograniczeniami i nie jest tworzony dla nich indeks w
sposób automatyczny.
Specjalnym typem ograniczenia i indeksu są tzw. unique index - a wiec
taki zestaw pól (lub wyrażeń), który będzie unikalny na poziomie wiersza
w całej tabeli.
Dlaczego istnieje równocześnie mechanizm klucza głownego i indeksów
unikalnych, skoro wydaje się, że to to samo?
Otóż klucz podstawowy jest wymagany do stworzenia kluczy obcych - nie
można ich stworzyć na podstawie indeksów unikalnych. Najczęściej robi
się tak, że klucz głowny tabeli jest tzw. wartością sztuczną (pole typu
autonumer, guid, itd.), ale dla zapewnienia unikalności w kontekście
logiki biznesowej używa się dodatkowo indeksu unikalnego (np. nie może
powtórzyć się nr PESEL czy coś podobnego).
Tabela może mieć jeden klucz podstawowy (i jeden clustered index, bo ten
ma wpływ na fizyczny porządek wierszy w tabeli), wiele indeksów (w tym
unikalnych) i wiele kluczy obcych.
Używanie triggerów do zapewnienia integralności referencyjnej jest, moim
zdaniem, błędem. Jest tylko jeden przypadek, kiedy trzeba użyć takiego
mechanizmu w MSSQL - ale to wyjątek od reguły.
--
wloochacz
|