Grupy dyskusyjne   »   pl.comp.pecet   »   Serwer dla MS-SQL (crosspost)

Serwer dla MS-SQL (crosspost)

Data: 2014-04-18 13:19:34
Autor: Zgr
Serwer dla MS-SQL (crosspost)
Cze艣膰.

Potrzeby:
- baza danych na MS-SQL, perspektywicznie ponad 15GB
- dost臋p zdalny przez Remote Desktop dla 5 do 8 os贸b
- lokalnie (w sieci LAN) max. ok. 15 os贸b

Maszynka ma by膰 na kilka lat.

Czy co艣 takiego wystarczy:

Platforma: IBM x3500 M4 v2 (IBM 7383D5G)

Proc: 1x Xeon 6C E5-2630v2 80W 2.6GHz/1600MHz/15MB, ( mo偶liwo艣膰 dodania +1 szt)

RAM: 2x 16GB (1x16GB, 2Rx4, 1.35V) PC3L-10600 CL9 ECC DDR3 1333MHz LP RDIMM (IBM 46W0672)

Macierz: ServeRAID M5100 Series 512MB Flash/RAID 5, nie wymaga baterii (IBM 81Y4487)

HDD: 5x IBM 300GB 2.5in SFF 10K 6Gbps HS SAS HDD (IBM 90Y8877) b臋d膮 ustawione w RAID5 (4 szt) + 1 szt. jako Hot Spare

2 x zasilacz 750W (IBM 94Y5974)

UPS UPS1500THV - 1050W (53962KX )

Od strony OS, b臋dzie to Win 2012 Std z CAL-ami lokalnymi i WinRmt oraz SQL Srv Standard 2012.

Czy od strony sprz臋towej wystarczy to na jakie艣 pi臋膰 lat?

Szybsze dyski s膮 ponad dwukrotnie dro偶sze (IBM 81Y9670).
P贸藕niej mo偶na dorzuci膰 drugi procesor i RAM.


Jakie艣 inne propozycje?

Na sam膮 stron臋 sprz臋tow膮 bud偶et ograniczony do ok. 16 tys. z艂. netto.


--
Pozdrowionka.

Zbych

Data: 2014-04-18 14:22:51
Autor: wloochacz
Serwer dla MS-SQL (crosspost)
W dniu 2014-04-18 13:19, Zgr pisze:
Cze艣膰.

Potrzeby:
- baza danych na MS-SQL, perspektywicznie ponad 15GB
- dost臋p zdalny przez Remote Desktop dla 5 do 8 os贸b
- lokalnie (w sieci LAN) max. ok. 15 os贸b
To jest piku艣  a nie obci膮偶enie, ale...
RD b臋dzie na tym samym serwerze?

Maszynka ma by膰 na kilka lat.

Czy co艣 takiego wystarczy:

Platforma: IBM x3500 M4 v2 (IBM 7383D5G)

Proc: 1x Xeon 6C E5-2630v2 80W 2.6GHz/1600MHz/15MB, ( mo偶liwo艣膰 dodania
+1 szt)

RAM: 2x 16GB (1x16GB, 2Rx4, 1.35V) PC3L-10600 CL9 ECC DDR3 1333MHz LP
RDIMM (IBM 46W0672)

Macierz: ServeRAID M5100 Series 512MB Flash/RAID 5, nie wymaga baterii
(IBM 81Y4487)

HDD: 5x IBM 300GB 2.5in SFF 10K 6Gbps HS SAS HDD (IBM 90Y8877) b臋d膮
ustawione w RAID5 (4 szt) + 1 szt. jako Hot Spare
Robile艣 kiedy艣 serwer pod baz臋 danych?
Wiesz, 偶e typowym mykiem s膮 osobne fizyczne dyski/systemy IO pod baz臋 danych i log transkacji?

2 x zasilacz 750W (IBM 94Y5974)

UPS UPS1500THV - 1050W (53962KX )
Jakie jest planowane obci膮偶enie tego MSSQL'a?
8 user贸w nic nie m贸wi - mog臋 jednym userem zrobi膰 wi臋ksze obci膮zenie ni偶 80 - i odwrotnie.

Co to za aplikacja i jak u偶ywa bazy danych?

Powiem tak - znam pewn膮 appk臋, kt贸ra zar偶ne艂a serwer dla 10 user贸w. Moja appka, kt贸ra robi艂a to samo na tym samym serwerze i z t膮 sam膮 baz膮 danych (sic!), wyrabia艂a si臋 bez zaj膮kni臋cia.
A wi臋c - to zale偶y.
Na tak postawione pytanie nie ma jednoznacznej odpowiedzi.


Od strony OS, b臋dzie to Win 2012 Std z CAL-ami lokalnymi i WinRmt oraz
SQL Srv Standard 2012.
Dlaczego nie Essential?
Powinien by膰 ta艅szy i ma wi臋cej softu na pok艂adzie.

Czy od strony sprz臋towej wystarczy to na jakie艣 pi臋膰 lat?

Szybsze dyski s膮 ponad dwukrotnie dro偶sze (IBM 81Y9670).
P贸藕niej mo偶na dorzuci膰 drugi procesor i RAM.
Dla bazy danych to w艂asnie dyski maj膮 znaczenie, a nie drugi procesor.
RAMu niegdy za wiele.
Inwestuj w HDD - im szybsze, tym lepsze.

Jakie艣 inne propozycje?
Na sam膮 stron臋 sprz臋tow膮 bud偶et ograniczony do ok. 16 tys. z艂. netto.
Tak naprawd臋 to nie sprz臋t jest najwa偶niejszy, tylko spos贸b wsp贸艂pracy konkretnej aplikacji z baz膮 danych.
Mo偶na to totalnie skopa膰 i dostaniesz infor od producenta; prosz臋 do艂o偶y膰 3 procesory i koljene 32 GiB RAMu.
I gadaj z takimi oszo艂omami...

--
Pozdrowionka.

Zbych


--
wloochacz

Data: 2014-04-18 15:18:47
Autor: Zgr
Serwer dla MS-SQL (crosspost)
W dniu 2014-04-18 14:22, wloochacz pisze:
W dniu 2014-04-18 13:19, Zgr pisze:
Cze艣膰.

Potrzeby:
- baza danych na MS-SQL, perspektywicznie ponad 15GB
- dost臋p zdalny przez Remote Desktop dla 5 do 8 os贸b
- lokalnie (w sieci LAN) max. ok. 15 os贸b
To jest piku艣  a nie obci膮偶enie, ale...
RD b臋dzie na tym samym serwerze?

Serwer b臋dzie te偶 serwerem dla pulpit贸w :P
Generalnie b臋dzie:
- serwerem SQL
- serwerem RD dla 5 do 8 pulpit贸w
- serwerem plik贸w
- serwerem ftp (sporadycznie, tylko male艅kie pliki)

B臋dzie te偶 na nim Cobian, kt贸ry b臋dzie zwala艂 dane na NAS-a.



Maszynka ma by膰 na kilka lat.

Czy co艣 takiego wystarczy:

Platforma: IBM x3500 M4 v2 (IBM 7383D5G)

Proc: 1x Xeon 6C E5-2630v2 80W 2.6GHz/1600MHz/15MB, ( mo偶liwo艣膰 dodania
+1 szt)

RAM: 2x 16GB (1x16GB, 2Rx4, 1.35V) PC3L-10600 CL9 ECC DDR3 1333MHz LP
RDIMM (IBM 46W0672)

Macierz: ServeRAID M5100 Series 512MB Flash/RAID 5, nie wymaga baterii
(IBM 81Y4487)

HDD: 5x IBM 300GB 2.5in SFF 10K 6Gbps HS SAS HDD (IBM 90Y8877) b臋d膮
ustawione w RAID5 (4 szt) + 1 szt. jako Hot Spare
Robile艣 kiedy艣 serwer pod baz臋 danych?

Nie bardzo :(

Wiesz, 偶e typowym mykiem s膮 osobne fizyczne dyski/systemy IO pod baz臋
danych i log transkacji?


Przy bardziej obci膮偶onych lub wi臋kszych.
Dzi臋ki za wskaz贸wk臋.

Czyli w takim uk艂adzie 2 x [mirror], gdzie na 1. wolumenie system + LDF, na 2. wolumenie "r贸偶no艣ci" + MDF.

Ewentualnie skonfigurowa膰 3 x [mirror], gdzie 1 - system, 2 - MDF, 3 - LDF + pliki u偶ytkownik贸w.

Dodatkowy dysk nie stanowi problemu, zawsze mo偶na dodatkow膮 p贸艂ke wsadzi膰 (ale to ju偶 powy偶ej 8 HDD).

Tylko nie wiem, czy dla matrycy M5100 81Y4487 mo偶na da膰 Hot Spare "nie przywi膮zany" do 偶adnego mirroru, kt贸ry uaktywni si臋 w razie potrzeby.

Na RAID5 czy RAID6 nie ma problemu.
Wola艂bym RAID6, bo mog膮 pa艣膰 2 dyski r贸wnocze艣nie i macierz dzia艂a, jednak chyba jest mniej wydajna dla SQL, gdzie ok. 70% to odczyt, 30% to zapis.

2 x zasilacz 750W (IBM 94Y5974)

UPS UPS1500THV - 1050W (53962KX )
Jakie jest planowane obci膮偶enie tego MSSQL'a?
8 user贸w nic nie m贸wi - mog臋 jednym userem zrobi膰 wi臋ksze obci膮zenie ni偶
80 - i odwrotnie.

Co to za aplikacja i jak u偶ywa bazy danych?


Dawny CDN, teraz Comarch, system Optima.
System pono膰 nie藕le napisany, do艣膰 dobrze zoptymalizowany. Wi臋kszo艣膰 operacji SQL wykonywana na serwerze.
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.

Powiem tak - znam pewn膮 appk臋, kt贸ra zar偶ne艂a serwer dla 10 user贸w. Moja
appka, kt贸ra robi艂a to samo na tym samym serwerze i z t膮 sam膮 baz膮
danych (sic!), wyrabia艂a si臋 bez zaj膮kni臋cia.
A wi臋c - to zale偶y.
Na tak postawione pytanie nie ma jednoznacznej odpowiedzi.


Racja.


Od strony OS, b臋dzie to Win 2012 Std z CAL-ami lokalnymi i WinRmt oraz
SQL Srv Standard 2012.
Dlaczego nie Essential?
Powinien by膰 ta艅szy i ma wi臋cej softu na pok艂adzie.


Dzi臋ki :)

Rzeczywi艣cie:
G3S-00723-Microsoft Essentials 2012 R2 x64 - 396,84 USD
P73-06172-Microsoft Std 2012 R2 x64 - 715,33 USD
P71-07721-Microsoft Server Datacenter 2012 R2 x64 - 4802,14 USD
(netto)

Jest jeszcze Windows Foundation 2008, ale tego nie bior臋 pod uwag臋.

Czy od strony sprz臋towej wystarczy to na jakie艣 pi臋膰 lat?

Szybsze dyski s膮 ponad dwukrotnie dro偶sze (IBM 81Y9670).
P贸藕niej mo偶na dorzuci膰 drugi procesor i RAM.
Dla bazy danych to w艂asnie dyski maj膮 znaczenie, a nie drugi procesor.
RAMu niegdy za wiele.
Inwestuj w HDD - im szybsze, tym lepsze.

Qrde, problem:

90Y8877 - IBM 300GB 2.5in SFF 10K 6Gbps HS SAS HDD - 686 z艂. netto
81Y9670 - IBM 300GB 2.5in SFF HS 15K 6Gbps SAS HDD - 1703 z艂. netto

Je艣li liczy膰 6 HDD, to robi si臋 znacz膮ca kwota :(


Dzi臋ki za sugesti臋, przeka偶臋 gdzie trzeba. Mo偶e prze偶yj臋 ;)



Jakie艣 inne propozycje?
Na sam膮 stron臋 sprz臋tow膮 bud偶et ograniczony do ok. 16 tys. z艂. netto.
Tak naprawd臋 to nie sprz臋t jest najwa偶niejszy, tylko spos贸b wsp贸艂pracy
konkretnej aplikacji z baz膮 danych.
Mo偶na to totalnie skopa膰 i dostaniesz infor od producenta; prosz臋
do艂o偶y膰 3 procesory i koljene 32 GiB RAMu.
I gadaj z takimi oszo艂omami...

Znam to :(

Data: 2014-04-18 19:38:17
Autor: wloochacz
Serwer dla MS-SQL (crosspost)
W dniu 2014-04-18 15:18, Zgr pisze:
W dniu 2014-04-18 14:22, wloochacz pisze:
W dniu 2014-04-18 13:19, Zgr pisze:
Cze艣膰.

Potrzeby:
- baza danych na MS-SQL, perspektywicznie ponad 15GB
- dost臋p zdalny przez Remote Desktop dla 5 do 8 os贸b
- lokalnie (w sieci LAN) max. ok. 15 os贸b
To jest piku艣  a nie obci膮偶enie, ale...
RD b臋dzie na tym samym serwerze?

Serwer b臋dzie te偶 serwerem dla pulpit贸w :P
Generalnie b臋dzie:
- serwerem SQL
- serwerem RD dla 5 do 8 pulpit贸w
- serwerem plik贸w
- serwerem ftp (sporadycznie, tylko male艅kie pliki)
Je艣li odpowiednio skonfigurujesz ConnectionString dla tych klient贸w na RDP, tak aby u偶ywali po艂膮czenia lokalnego (tzw. memory shared protocol), to Ci kleincie b臋d膮 dzia艂a膰 najszybciej :-)
http://stackoverflow.com/questions/1138559/fastest-sql-server-protocol


B臋dzie te偶 na nim Cobian, kt贸ry b臋dzie zwala艂 dane na NAS-a.



Maszynka ma by膰 na kilka lat.

Czy co艣 takiego wystarczy:

Platforma: IBM x3500 M4 v2 (IBM 7383D5G)

Proc: 1x Xeon 6C E5-2630v2 80W 2.6GHz/1600MHz/15MB, ( mo偶liwo艣膰 dodania
+1 szt)

RAM: 2x 16GB (1x16GB, 2Rx4, 1.35V) PC3L-10600 CL9 ECC DDR3 1333MHz LP
RDIMM (IBM 46W0672)

Macierz: ServeRAID M5100 Series 512MB Flash/RAID 5, nie wymaga baterii
(IBM 81Y4487)

HDD: 5x IBM 300GB 2.5in SFF 10K 6Gbps HS SAS HDD (IBM 90Y8877) b臋d膮
ustawione w RAID5 (4 szt) + 1 szt. jako Hot Spare
Robile艣 kiedy艣 serwer pod baz臋 danych?

Nie bardzo :(

Wiesz, 偶e typowym mykiem s膮 osobne fizyczne dyski/systemy IO pod baz臋
danych i log transkacji?

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?

Dzi臋ki za wskaz贸wk臋.

Czyli w takim uk艂adzie 2 x [mirror], gdzie na 1. wolumenie system + LDF,
na 2. wolumenie "r贸偶no艣ci" + MDF.

Ewentualnie skonfigurowa膰 3 x [mirror], gdzie 1 - system, 2 - MDF, 3 -
LDF + pliki u偶ytkownik贸w.

Dodatkowy dysk nie stanowi problemu, zawsze mo偶na dodatkow膮 p贸艂ke
wsadzi膰 (ale to ju偶 powy偶ej 8 HDD).

Tylko nie wiem, czy dla matrycy M5100 81Y4487 mo偶na da膰 Hot Spare "nie
przywi膮zany" do 偶adnego mirroru, kt贸ry uaktywni si臋 w razie potrzeby.

Na RAID5 czy RAID6 nie ma problemu.
Wola艂bym RAID6, bo mog膮 pa艣膰 2 dyski r贸wnocze艣nie i macierz dzia艂a,
jednak chyba jest mniej wydajna dla SQL, gdzie ok. 70% to odczyt, 30% to
zapis.

2 x zasilacz 750W (IBM 94Y5974)

UPS UPS1500THV - 1050W (53962KX )
Jakie jest planowane obci膮偶enie tego MSSQL'a?
8 user贸w nic nie m贸wi - mog臋 jednym userem zrobi膰 wi臋ksze obci膮zenie ni偶
80 - i odwrotnie.

Co to za aplikacja i jak u偶ywa bazy danych?


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".
Powiedzmy sobie szczerze - Optima to do艣膰 prosty system handlowo-magazynowy. Zalecanie maszyny z Core I3/5/7 do takiego czego艣 to... maskara jaka艣 ;-)

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.
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膰.

Powiem tak - znam pewn膮 appk臋, kt贸ra zar偶ne艂a serwer dla 10 user贸w. Moja
appka, kt贸ra robi艂a to samo na tym samym serwerze i z t膮 sam膮 baz膮
danych (sic!), wyrabia艂a si臋 bez zaj膮kni臋cia.
A wi臋c - to zale偶y.
Na tak postawione pytanie nie ma jednoznacznej odpowiedzi.


Racja.


Od strony OS, b臋dzie to Win 2012 Std z CAL-ami lokalnymi i WinRmt oraz
SQL Srv Standard 2012.
Dlaczego nie Essential?
Powinien by膰 ta艅szy i ma wi臋cej softu na pok艂adzie.


Dzi臋ki :)

Rzeczywi艣cie:
G3S-00723-Microsoft Essentials 2012 R2 x64 - 396,84 USD
P73-06172-Microsoft Std 2012 R2 x64 - 715,33 USD
P71-07721-Microsoft Server Datacenter 2012 R2 x64 - 4802,14 USD
(netto)

Jest jeszcze Windows Foundation 2008, ale tego nie bior臋 pod uwag臋.

Czy od strony sprz臋towej wystarczy to na jakie艣 pi臋膰 lat?

Szybsze dyski s膮 ponad dwukrotnie dro偶sze (IBM 81Y9670).
P贸藕niej mo偶na dorzuci膰 drugi procesor i RAM.
Dla bazy danych to w艂asnie dyski maj膮 znaczenie, a nie drugi procesor.
RAMu niegdy za wiele.
Inwestuj w HDD - im szybsze, tym lepsze.

Qrde, problem:

90Y8877 - IBM 300GB 2.5in SFF 10K 6Gbps HS SAS HDD - 686 z艂. netto
81Y9670    - IBM 300GB 2.5in SFF HS 15K 6Gbps SAS HDD - 1703 z艂. netto

Je艣li liczy膰 6 HDD, to robi si臋 znacz膮ca kwota :(
Je艣li posadzisz na tym Esential, to zaszcz臋dzisz znaczn膮 kwot臋, kt贸r膮 mo偶esz zainwestowa膰 w szybsze dyski.
Tylko jest jedno ma艂e "ale" - bardzo dobrze si臋 zastan贸w, czy ograniczenia licencyjne Essential nie zaczn膮 Cie uwierac za chwil臋 - nie pamietam dok艂adnie, ale tam jest chyba limit do 25 CAL'贸w.

Dzi臋ki za sugesti臋, przeka偶臋 gdzie trzeba. Mo偶e prze偶yj臋 ;)


Jakie艣 inne propozycje?
Na sam膮 stron臋 sprz臋tow膮 bud偶et ograniczony do ok. 16 tys. z艂. netto.
Tak naprawd臋 to nie sprz臋t jest najwa偶niejszy, tylko spos贸b wsp贸艂pracy
konkretnej aplikacji z baz膮 danych.
Mo偶na to totalnie skopa膰 i dostaniesz infor od producenta; prosz臋
do艂o偶y膰 3 procesory i koljene 32 GiB RAMu.
I gadaj z takimi oszo艂omami...

Znam to :(




--
wloochacz

Data: 2014-04-19 13:46:14
Autor: Adam
Serwer dla MS-SQL (crosspost)
W dniu 2014-04-18 19:38, wloochacz pisze:
W dniu 2014-04-18 15:18, Zgr pisze:
(...)
Przy bardziej obci笨onych lub wi阫szych.
True, ale z tego co piszesz, to narzut Optimu mo縠 by znaczny na baz
danych - a tu wi阠ej RAMu i szybkie dyski si k砤niaj.
Ale 32GiB to nie powinno by problemem... Tyle, 縠 ja kompletnie nie mam
pojecia jak Optima wsp蟪pracuj z baz danych.

Powiem tak - mia砮m kiedy firm, kt髍a na Windows Server 2000 32bit z
SQL Serverem 2000 obs硊giwa砤 ok. 120-140 klient體.
Wielko舵 bazy - ok. 40 GiB.
I to dzia砤硂 nawet nie糽e; dlatego jak widz co poniekt髍e wymagania w
stylu "najwydajniej Optima pracuje na komputerze z procesorem CoreI7 z 4
GB RAM lub wi阠ej" to si pytam - WTF?

Aktualne wymagania Optimy (tylko klient), to Win XP SP2, 1GB RAM.
Je秎i na stanowisku ma by Optima + SQL Express, to pasuje 2 GB RAM.

Procesor - mo縠 by Celeron, ale wtedy czeka si d硊uugo na odpowied ;)

Na stanowiska u klient體 k砤d poleasingowe C2D z zegarem powy縠j 2GHz (najcz甓ciej Delle) i pracuj bezproblemowo.

(...)
Dawny CDN, teraz Comarch, system Optima.
System pono nie糽e napisany, do舵 dobrze zoptymalizowany. Wi阫szo舵
operacji SQL wykonywana na serwerze.
Optima?
Je秎i tu:
http://blog.alpol.net.pl/2011/10/jak-przyspieszyc-comarch-optima-2010/
pisz prawd, to ja dzi阫uj za takie "optymalizacje".

琹e trafi砮.
Akurat Optima w werski 2010 zast眕i砤 wersj 17.x.
Optima do wersji 17 w潮cznie by砤 napisana w Clarionie.
Wersja 2010 - to pierwsza wersja napisana w dotNecie.
Niestety, z r罂nych wzgl阣體 wi阫szo舵 operacji by砤 liczona na klientach, st眃 te sporo rzeczy dzia砤硂 nawet kilkadziesi眛(!) razy wolniej, ni w wersjach Clarionowych.
P蠹niej nast阷owa砤 optymalizacja, tak, 縠 kilka lat p蠹niej wersja 2012.x ju zacz瓿a "dogania" szybko禼i wersj 17.
Teraz jest v. 2014.3.

Tak informacyjnie:

Kilkana禼ie lat temu grupa programist體 odesz砤 z 體czesnego CDN-u i za硂縴砤 swoj firm - Soneta (system Enova).
Od pocz眛ku zacz阬i 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體nywalna funkcjonalnie z Optim. Jej instalacja trwa kilkadziesi眛 sekund.
Natomiast Optima pisana przez zdecydowanie wi阫szy sztab ludzi (ale generalnie ludzi m硂dych, po studiach) - wymagania ma o niebo wi阫sze.

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砮m, rzeczywiste wymagania nie s a tak du縠.
Jedyna rzecz, co obci笨a, to serwer analiz (kostka Olapowa), drugi (zewn阾rzny) program.

Optimy (i Enovy) nie nazwa砨ym "prostym" programem - potrafi sporo wi阠ej ni r罂ne Wf-Magi czy Symfonie.

Dzi阫i sprawdzaniu sp骿no禼i na poziomie samej bazy (np. Triggery) - ci昕ko jest "zepsu" baz, nawet gmeraj眂 bezpo秗ednio w danych.

Bardzo konfigurowalne systemy, mo縧iwo舵 prostego dopisywania w砤snych funkcji w SQL, VB, C++, itp. Silnik raport體 Crystal - mo縩a wrzuca w砤sne, opr骳z tego prosty Genrap, gdzie nawet "bl眃ynka" (b潮d zamierzony) dowolnej p砪i potrafi przerobi istniej眂y wydruk wg. w砤snych potrzeb. Doskona砤 integracja z systemami sprzeda縴 on-line, z p砤tno禼iami - jak si potrafi, to mo縩a naprawd b. wiele ustawi pod klienta.
A jak jest za ma硂 - mo縩a zmigrowa pod ERP np. Comarch XL.

S firmy, kt髍e maj po 40 ludk體 siedz眂ych na jednym starym ML 350 G3
i jako to wyrabia.
Problem zaczyna si przy "du縴ch" bazach danych, maj眂ych po kilka
milion體 rekord體 w najwi阫szych tabelach - wtedy macierz nie wyrabia z
wydajno禼i.
Tabel jest blisko 400, sporo kluczy i indeks體, bardzo du縪 trigger體.
Samo dopisanie pozycji do faktury (z poziomu Optimy) generuje
kilkadziesi眛 procedur (?) - m.in. sprawdzanie rezerwacji, sprawdzanie
stan體 magazynowych, sprawdzanie p砤tno禼i, rabat體, itd, itd.

A z ciekawo禼i sprawdzi砮m:

Comarch Optima - 350 tabel
Comarch XL w jakiej starszej wersji - 469 tabel
Enova - 326
Wapro - 435
Subiekt - 570

Ale to jeszcze o niczym nie 秝iadczy.
Widzia砮m (nie pami阾am, gdzie) pola typu DECIMAL(15,2) u縴wane do przechowywania flagi, gdzie wystarczy硂by pole SMALLINT.
Podobnie, mo縩a "przytka" baz wrzucaj眂 dane binarne, typu PDF czy JPG.

Subiekt potrafi "zgubi" rekordy. Potrafi czasem sprzeda towar, kt髍ego nie ma na stanie.
Wapro zn體 potrafi mie problemy ze sp骿no禼i rozrachunk體.

Na szcz甓cie takie rzeczy nie zdarzaj si w CDN-ie (Comarch).

Zastan體 si - naprawd s眃zisz, 縠 to jest dobrze napisane?
Znam taki system, kt髍y te "wszystkie operacje wykonywa na serwerze".
Jakiekolwiek pierdni阠ie - wywo硑wana by砤 SP, kt髍a wo砤砮 nast阷ne SP
i tak w k蟪ko Macieju...
Efekt? jedna wielka KUPA!
Akurat tam architekt systemu zapomnia, 縠 baza SQL jest zorientowana na
przetwarzanie ZBIOR覹 danych, a nie pojedynczych wierszy...
No ale co zrobi - taki b阣ziesz mia system, to muszisz z nim 縴.

No w砤秐ie.
Czasami (m體i z praktyki) lepiej si sprawdzi prostszy system, ale z dobrym wsparciem producenta i z dobr dokumentacj programistyczn ni "kombajn" ERP, w kt髍ym "co si samo dzieje" i nikt, w潮cznie z producentem, nie wie o co chodzi.
Ju paru klient體 migrowa砮m z r罂nych "wynalazk體" m.in. na systemy CDN, wi阠 chyba nie s to czcze wymys硑 ;)

A przetwarzanie wierszy (i gadanie o kursorach) to chyba domena programist體, zaczynaj眂ych od Clippera ;)

Chocia ja te do tej pory nie odr罂niam indeksu od klucza w SQL.
Czy chodzi o to, 縠 klucz "leci" po kilku polach?

(...)


--
Pozdrawiam.

Adam

Data: 2014-04-19 15:29:57
Autor: wloochacz
Serwer dla MS-SQL (crosspost)
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

Data: 2014-04-19 19:00:33
Autor: Adam
Serwer dla MS-SQL (crosspost)
W dniu 2014-04-19 15:29, wloochacz pisze:
W dniu 2014-04-19 13:46, Adam pisze:
(...)>> A jak jest za ma硂 - mo縩a 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骻lby mnie poratowa w tej sytuacji?
G硂wnie chodzi o napisanie widok體 do pobierania danych o zleceniach
produkcyjnych.
Kwestia sposobu rozliczenia do dogadania.


Spr骲uj w miar moich niewielkich mo縧iwo禼i pom骳.

Napisz mi maila ma
a.g
ma硃ka
poczta.onet.pl
z tematem [CDN-XL]
to podam Ci m骿 normalny mail, i zobaczymy, co da si zrobi.

Mog Ci udost阷ni dokumentacj i wersj demo - jednak musia砨ym Ci albo wys砤 klucz HASP, albo go udost阷ni przez Internet.
Tak czy inaczej - no problem :)

S firmy, kt髍e maj po 40 ludk體 siedz眂ych na jednym starym ML 350 G3
i jako to wyrabia.
Problem zaczyna si przy "du縴ch" bazach danych, maj眂ych po kilka
milion體 rekord體 w najwi阫szych tabelach - wtedy macierz nie wyrabia z
wydajno禼i.
Tabel jest blisko 400, sporo kluczy i indeks體, bardzo du縪 trigger體.
Samo dopisanie pozycji do faktury (z poziomu Optimy) generuje
kilkadziesi眛 procedur (?) - m.in. sprawdzanie rezerwacji, sprawdzanie
stan體 magazynowych, sprawdzanie p砤tno禼i, rabat體, itd, itd.

A z ciekawo禼i sprawdzi砮m:

Comarch Optima - 350 tabel
Comarch XL w jakiej starszej wersji - 469 tabel
Enova - 326
Wapro - 435
Subiekt - 570

Ale to jeszcze o niczym nie 秝iadczy.
Widzia砮m (nie pami阾am, gdzie) pola typu DECIMAL(15,2) u縴wane do
przechowywania flagi, gdzie wystarczy硂by pole SMALLINT.
Wystarczy硂by - a i pewnie, ale tak si nie projektuje du縠go systemu.
Najpierw definiujesz sobie w砤sne typy danych (domneny), a potem ich
u縴wasz. jakbym mia w kazdym polu ka縟ej tabeli okresla typ i rozmiar
to by mnie k...wica strzeli砤 bardzo szybko :)

Nie rozumiem.
Wydawa硂 mi si, 縠 definiuj眂 tabel w SQL, nale縴 te zdefiniowa poszczeg髄ne pola, czyli przyk砤dowo:

CREATE TABLE [CDN].[TraNag](
[TrN_TrNID] [int] IDENTITY(1,1) NOT NULL,
[TrN_RelTrNId] [int] NULL,
[TrN_FVMarza] [tinyint] NULL,
[TrN_DDfId] [int] NULL,
[TrN_TypDokumentu] [int] NOT NULL,
[TrN_ZwrId] [int] NULL,
[TrN_ZwrIdWZKK] [int] NULL,
[TrN_FaId] [int] NULL,
[TrN_NumerNr] [int] NOT NULL,
[TrN_NumerString] [varchar](31) NOT NULL,

itd.

Co za co - wydajno舵 nie jest jedynym kryterium, chodzi te o
utrzymanie i prosty rozw骿 systemu.

Podobnie, mo縩a "przytka" baz wrzucaj眂 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硑w na wydajno舵... Oczywi禼ie wszystko
zale縴 od tego, w jaki spos骲 b阣ziemy tego u縴wa.

Je秎i takich danych jest naprawd du縪, to MSSQL oferuje bardzo fajny
mechanizm do obs硊gi takich danych. Mam na my秎i FileStream, a od wersji
2012 FileTables - i to jest naprawd cool!


Musz w wolnej chwili poczyta. Dzi阫i za info.


(...)
A przetwarzanie wierszy (i gadanie o kursorach) to chyba domena
programist體, zaczynaj眂ych od Clippera ;)

Chocia ja te do tej pory nie odr罂niam indeksu od klucza w SQL.
Czy chodzi o to, 縠 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髍ego podstawowym celem jest przyspieszenie operacji
wyszukiwania danych w tabelach (ale nie tylko w tabelach, doczyta o
tzw. widokach zmaterializowanych).
(...)

Dzi阫i,  nieco si rozja秐i硂. Przynajmniej ju wiem, jakich informacji szuka.

U縴wanie trigger體 do zapewnienia integralno禼i referencyjnej jest, moim
zdaniem, b酬dem. Jest tylko jeden przypadek, kiedy trzeba u縴 takiego
mechanizmu w MSSQL - ale to wyj眛ek od regu硑.

Optima jest (by砤?) pomy秎ana jako system "strojony" pod klienta. Napraw baz w za硂縠niu mieli si zajmowa serwisanci o r罂nym stopniu wiedzy.
St眃 te np. przy kasowaniu rekordu (bezpo秗ednio w bazie danych) w TraNag (nag丑wku transakcji) sprawdzane s najprzer罂niejsze warunki, takie jak rezerwacje, p砤tno禼i, stany na poszczeg髄nych magazynach i ca砮 mn髎two innych. St眃 kto (nawet przypadkowy), kto "dobierze si" do bazy danych SQL nawet prostym skanerem, nie jest w stanie jej zepsu. No, chyba 縠 zna polecenie:
Alter table cdn.JakasTabela disable trigger all

Czasami zdarza si go u縴wa, ostatnio np. musia砮m zmieni definicj numeracji kasy na "縴wym" raporcie kasowym z SYMBOL/NR/ROK na SYMBOL/NR/KASA/ROK czy jako tak.

Tak wi阠 z mojego punktu widzenia trigger jest co najmniej pomocny, 縠by nie powiedzie niezb阣ny. Ale by mo縠 czego nie wiem.
Nie wyobra縜m sobie "gmerania" na bazie danych z kilkudziesi阠iostronicowym materia砮m opisuj眂ym jakie zale縩o禼i czy uwarunkowania.


--
Pozdrawiam.

Adam

Data: 2014-04-19 21:03:18
Autor: wloochacz
Serwer dla MS-SQL (crosspost)
W dniu 2014-04-19 19:00, Adam pisze:
W dniu 2014-04-19 15:29, wloochacz pisze:
W dniu 2014-04-19 13:46, Adam pisze:
(...)>> 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.

Spr贸buj臋 w miar臋 moich niewielkich mo偶liwo艣ci pom贸c.

Napisz mi maila ma
a.g
ma艂pka
poczta.onet.pl
z tematem [CDN-XL]
to podam Ci m贸j normalny mail, i zobaczymy, co da si臋 zrobi膰.

Mog臋 Ci udost臋pni膰 dokumentacj臋 i wersj臋 demo - jednak musia艂bym Ci albo
wys艂a膰 klucz HASP, albo go udost臋pni膰 przez Internet.
Tak czy inaczej - no problem :)
O!
Nie wiem co powiedzie膰 - dzi臋ki!
Na pewno napisz臋 :)

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 :)

Nie rozumiem.
Wydawa艂o mi si臋, 偶e definiuj膮c tabel臋 w SQL, nale偶y te偶 zdefiniowa膰
poszczeg贸lne pola, czyli przyk艂adowo:
Oczywi艣cie, 偶e pola trzeba zdefiniowa膰 - pisa艂em o typach danych (domenach, czyli wg terminologii MSSQL "User-Definied Data Types");
Sp贸jrz - w tym przyk艂adzie definicja tabeli jest oparta na standardowych typach danych i OK.
Ale...

CREATE TABLE [CDN].[TraNag](
     [TrN_TrNID] [int] IDENTITY(1,1) NOT NULL,
     [TrN_RelTrNId] [int] NULL,
     [TrN_FVMarza] [tinyint] NULL,
     [TrN_DDfId] [int] NULL,
     [TrN_TypDokumentu] [int] NOT NULL,
     [TrN_ZwrId] [int] NULL,
     [TrN_ZwrIdWZKK] [int] NULL,
     [TrN_FaId] [int] NULL,
     [TrN_NumerNr] [int] NOT NULL,
     [TrN_NumerString] [varchar](31) NOT NULL,

itd.
Moja tabela wygl膮da np. tak:
CREATE TABLE [dbo].[tDfLogEntity]
(
[IdEntity] [dbo].[uNAME_L] NOT NULL,
[PkValue] [dbo].[uNAME_M] NOT NULL,
[IdUser] [dbo].[uINT] NOT NULL,
[LogType] [char] [uName_S] NOT NULL,
[LogDate] [dbo].[uDATE_TIME] NOT NULL,
[UpdateCount] [dbo].[uINT_BIG] NOT NULL
)
Np. definicja domnety uNAME_L wygl膮da tak:
CREATE TYPE [dbo].[uNAME_L] FROM [varchar](80) NULL

I potem pos艂ugujesz si臋 wszedzie w艂asnymi typami, nie muszisz si臋 zastanawia膰 czy to by艂 varchar(80) czy 180...
To po prostu wygodne i 艂atwe do utrzymania.

Poza tym mam w艂asne rpzmy艣lenia na nazywanie table, procedur, p贸l itd w bazie danych. To co jest w CDN mi si臋 nie podoba; uwa偶am za zbyteczne dodowanie przedrostka do nazwy pola, kt贸ry okre艣la z jakiej jest tabeli.
Po co to? Przecie偶 od tego s膮 aliasy, czyli:
select H.TrN_ZwrTyp,
        H.TrN_ZwrFirma,
        H.TrN_ZwrNumer,
        L.TrE_JmFormatZ,
        L.TrE_TypJm,
        L.TrE_PrzeliczM,
        L.TrE_PrzeliczL,
        L.TrE_GrupaPod
from CDN.TraNag H
inner join CDN.TraElem L on (L.TrE_GIDNumer = H.TrN_GIDNumer)

U mnie ka偶de pole nazywa si臋 dok艂adnie tak samo w ka偶dej tabeli, je艣li niesie t臋 sam膮 informacj臋 logiczn膮 (np. kod klienta, nr dokumentu, itd.). Ale to wynika te偶 z pewnych mechanizm贸w w programowaniu apliakcji, ale to ju偶 zupe艂nie inna bajka...

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!


Musz臋 w wolnej chwili poczyta膰. Dzi臋ki za info.


(...)
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).
(...)

Dzi臋ki,  nieco si臋 rozja艣ni艂o. Przynajmniej ju偶 wiem, jakich informacji
szuka膰.

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.

Optima jest (by艂a?) pomy艣lana jako system "strojony" pod klienta.
Napraw膮 baz w za艂o偶eniu mieli si臋 zajmowa膰 serwisanci o r贸偶nym stopniu
wiedzy.
W dobrze zaprojektowanej i wdro偶onej aplikacji (i bazie danych oczywi艣cie) nie ma prawa zdarzy膰 si臋 co艣 takiego jak "popsuta baza".
Nie wiem, mo偶e za ma艂o widzia艂em, ale... Zajmuj臋 si臋 MSSQLem od wersji 2000 na powa偶nie i nigdy nie mia艂em przypadku popsutej bazy danych, na poziomie serwera.
Braki w danych, osercone dokumenty, zagubione transkacje - pewnie, 偶e by艂o. Ale to by艂 efekt 藕le zaprojektowanej apliakcji. Tylko i wy艂膮cznie.

St膮d te偶 np. przy kasowaniu rekordu (bezpo艣rednio w bazie danych) w
TraNag (nag艂贸wku transakcji) sprawdzane s膮 najprzer贸偶niejsze warunki,
takie jak rezerwacje, p艂atno艣ci, stany na poszczeg贸lnych magazynach i
ca艂e mn贸stwo innych. St膮d kto艣 (nawet przypadkowy), kto "dobierze si臋"
do bazy danych SQL nawet prostym skanerem, nie jest w stanie jej zepsu膰.
No, chyba 偶e zna polecenie:
Alter table cdn.JakasTabela disable trigger all
Po pierwsze - nikt normalny nie daje bezpo艣redniego dost臋pu do bazy danych. To jak gmeranie w nosie odbezpieczonym granatem.
Robi艂em takie cuda, jasne - alke to wymaga perfekcyjnej znajomo艣ci logiki aplikacji i mechanizm贸w bazy danych. Jak nie popsujesz co艣 w danych, to mozesz spowodowa膰 eskalacj臋 blokad - na przyk艂ad.

Czasami zdarza si臋 go u偶ywa膰, ostatnio np. musia艂em zmieni膰 definicj臋
numeracji kasy na "偶ywym" raporcie kasowym z SYMBOL/NR/ROK na
SYMBOL/NR/KASA/ROK czy jako艣 tak.

Tak wi臋c z mojego punktu widzenia trigger jest co najmniej pomocny, 偶eby
nie powiedzie膰 niezb臋dny. Ale by膰 mo偶e czego艣 nie wiem.
:-)
Nie obra藕 si臋, ale w艂a艣nie zacytowa艂e艣 mi standardow膮 regu艂k臋 producenta, kt贸ry musi jako艣 przekona膰 innych do swojego rozwi膮zania. Ale ja tego nie kupuj臋 ;-)
Wi臋cej - mam wyrobione zdanie na ten temat poparte do艣wiadczeniem gdzie by艂o mniej wi臋cej podobnie. I nigdy wi臋cej!
Tj. spora cz臋艣膰 logiki by艂a zaszyta w bazie danych, ale to nie by艂o dobre. Moje do艣wiadczenia to nie tylko wdra偶anie, ale te偶 rozw贸j i utrzymanie tak napisanej aplikacji.

Dlaczego uwa偶am to za niezbyt szcz臋艣liwe rozwi膮zanie? Po pierwsze i najwa偶niejsze - rozproszona odpowiedzialno艣膰 (nie wiem czy programujesz, ale zapoznaj si臋 z zasad膮 SOLID a ja tu pisz臋 o pierwszej z nich, czyli "single responsibility").
Nie do ko艅ca wiadomo co robi aplikacja (i dlaczego), a co robi baza (i dlaczego). Ja chc臋 mie膰 spok贸j i uwa偶am, 偶e aplikacja powinna by膰 wygodna w rozwouju i elastyczna w dostosowaniu.
Od tej pory minimalizuj臋 logik臋 w bazie do minimum - de-facto poza utrzymaniem integralno艣ci wi臋cej logiki tam nie ma.
Tak, tak - wiem - to taki 艣wi臋ty Graal aplikacji biznesowych ;-)

Nie wyobra偶am sobie "gmerania" na bazie danych z
kilkudziesi臋ciostronicowym materia艂em opisuj膮cym jakie艣 zale偶no艣ci czy
uwarunkowania.
Tyle to piku艣 :D
Co powiesz na to; ok. 1100 tabel i 12 ty艣 procedur? Oczywi艣cie zero dokumentacji technicznej - tylko aplikacja i profiler.
I we藕 w tym gmeraj ;-)

--
wloochacz

Data: 2014-04-19 22:11:50
Autor: Adam
Serwer dla MS-SQL (crosspost)
W dniu 2014-04-19 21:03, wloochacz pisze:
W dniu 2014-04-19 19:00, Adam pisze:
(...)
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 :)

Nie rozumiem.
Wydawa艂o mi si臋, 偶e definiuj膮c tabel臋 w SQL, nale偶y te偶 zdefiniowa膰
poszczeg贸lne pola, czyli przyk艂adowo:
Oczywi艣cie, 偶e pola trzeba zdefiniowa膰 - pisa艂em o typach danych
(domenach, czyli wg terminologii MSSQL "User-Definied Data Types");
Sp贸jrz - w tym przyk艂adzie definicja tabeli jest oparta na standardowych
typach danych i OK.
Ale...

CREATE TABLE [CDN].[TraNag](
     [TrN_TrNID] [int] IDENTITY(1,1) NOT NULL,
     [TrN_RelTrNId] [int] NULL,
     [TrN_FVMarza] [tinyint] NULL,
     [TrN_DDfId] [int] NULL,
     [TrN_TypDokumentu] [int] NOT NULL,
     [TrN_ZwrId] [int] NULL,
     [TrN_ZwrIdWZKK] [int] NULL,
     [TrN_FaId] [int] NULL,
     [TrN_NumerNr] [int] NOT NULL,
     [TrN_NumerString] [varchar](31) NOT NULL,

itd.
Moja tabela wygl膮da np. tak:
CREATE TABLE [dbo].[tDfLogEntity]
(
[IdEntity] [dbo].[uNAME_L] NOT NULL,
[PkValue] [dbo].[uNAME_M] NOT NULL,
[IdUser] [dbo].[uINT] NOT NULL,
[LogType] [char] [uName_S] NOT NULL,
[LogDate] [dbo].[uDATE_TIME] NOT NULL,
[UpdateCount] [dbo].[uINT_BIG] NOT NULL
)
Np. definicja domnety uNAME_L wygl膮da tak:
CREATE TYPE [dbo].[uNAME_L] FROM [varchar](80) NULL

I potem pos艂ugujesz si臋 wszedzie w艂asnymi typami, nie muszisz si臋
zastanawia膰 czy to by艂 varchar(80) czy 180...
To po prostu wygodne i 艂atwe do utrzymania.

Z Twojego punktu widzenia - mo偶e to by膰 czytelne.
Ale z punktu widzenia producenta programu - chyba niekoniecznie.
Je艣li kto艣 wypuszcza program "do ludzi", to wydaje mi si臋, 偶e lepiej jest, aby typy by艂y typowe ;)

_Management_Studio_ pokazuje (dla TraNag):

CREATE TABLE [CDN].[TraNag](
[TrN_TrNID] [int] IDENTITY(1,1) NOT NULL,
[TrN_TerminZwrotuKaucji] [datetime] NULL,
[TrN_OFFPrawoDoFAPA] [tinyint] NULL,
[TrN_OFFPrawoDoAnulowania] [tinyint] NULL,
[TrN_RelTrNId] [int] NULL,
[TrN_FVMarza] [tinyint] NULL,
[TrN_DDfId] [int] NULL,
[TrN_TypDokumentu] [int] NOT NULL,
[TrN_ZwrId] [int] NULL,
[TrN_FaId] [int] NULL,
[TrN_NumerNr] [int] NOT NULL,
[TrN_NumerString] [varchar](31) NOT NULL,
[TrN_Bufor] [smallint] NOT NULL,
[TrN_Anulowany] [int] NOT NULL,
[TrN_VaNId] [int] NULL,
[TrN_DataDok] [datetime] NOT NULL,
[TrN_DataWys] [datetime] NOT NULL,
[TrN_DataOpe] [datetime] NOT NULL,
[TrN_NumerObcy] [varchar](30) NOT NULL,
(...)

_Dokumentacja_ pokazuje:

Nazwa // Typ // Opis // Opcje
TrN_TrNID // INTEGER // Identyfikator rekordu // Unikalny identyfikator rekordu. Poprzez to pole realizowane s膮 wszystkie relacje typu 1:MANY do innych tabel. // IDENTITY(1,1)

TrN_RelTrNId // INTEGER// Pomocnicze pole relacji miedzy dokumentami

TrN_FVMarza // TINYINT // Faktura marza 1 - Faktura marza

TrN_FVMarzaRodzaj // TINYINT // Faktura marza rodzaj  1- Procedura mar偶y dla biur podr贸偶y 2- Procedura mar偶y 鈥 towary u偶ywane 3- Procedura mar偶y 鈥 dzie艂a sztuki 4- Procedura mar偶y 鈥 przedmioty kolekcjonerskie i antyki

TrN_DDfId // INTEGER // Identyfikator dokumentu w tabeli DokDefinicje

TrN_TypDokumentu // INTEGER // Typ dokumentu (klasa dokumentu z tabeli DokDefinicje) // NOT NULL

TrN_ZwrId // INTEGER // Identyfikator dokumentu 藕rodlowego dla dokument贸w koryguj膮cych

TrN_ZwrIdWZKK // INTEGER // Identyfikator dokumentu 藕rodlowego dla dokument贸w koryguj膮cych WZKK

TrN_FaId // INTEGER // Wska藕nik do faktury wykorzystywany przy przekszta艂acaniu paragon贸w i WZ do faktury W paragonie lub WZ jest tu TrNId faktury, do kt贸rej zosta艂 przekszta艂cony dokument 藕r贸d艂owy

TrN_NumerNr // INTEGER // Autonumerowany czlon numeru dokumentu //  NOT NULL

TrN_NumerString // VARCHAR(31) Sta艂y (parametryzowalny) cz艂on numeru dokumentu // NOT NULL

TrN_NumerPelny // COMPUTED|VARCHAR(30) Pe艂ny numer dokumentu Numer wyliczany funkcj膮 serwerow膮 // CDN.FN_NUMERPELNY(TRN_NUMERNR,TRN_NUMERSTRING)

TrN_Bufor // SMALLINT // Stan dokumentu  1 - bufor,
0 - zatwierdzony, -1 - anulowany // NOT NULL
(...)

itd., p贸藕niej opisy kluczy i relacji.
Oczywi艣cie wszystko tabelarycznie, tutaj pr贸bowa艂em to "prze艂o偶y膰" na "p艂aski" txt.

Wydaje mi si臋 (przy aktualnym stanie mojej wiedzy), 偶e gdyby kto艣 dosta艂 dokumentacj臋 z nadanymi w艂asnymi, nietypowymi nazwami typ贸w danych, to musia艂by dosta膰 jeszcze "s艂ownik" owych typ贸w - dodatkowa niepotrzebna translacja ;)


Poza tym mam w艂asne rpzmy艣lenia na nazywanie table, procedur, p贸l itd w
bazie danych. To co jest w CDN mi si臋 nie podoba; uwa偶am za zbyteczne
dodowanie przedrostka do nazwy pola, kt贸ry okre艣la z jakiej jest tabeli.
Po co to? Przecie偶 od tego s膮 aliasy, czyli:
select H.TrN_ZwrTyp,
        H.TrN_ZwrFirma,
        H.TrN_ZwrNumer,
        L.TrE_JmFormatZ,
        L.TrE_TypJm,
        L.TrE_PrzeliczM,
        L.TrE_PrzeliczL,
        L.TrE_GrupaPod
from CDN.TraNag H
inner join CDN.TraElem L on (L.TrE_GIDNumer = H.TrN_GIDNumer)


Aliasy s膮 wykorzystywane.

U mnie ka偶de pole nazywa si臋 dok艂adnie tak samo w ka偶dej tabeli, je艣li
niesie t臋 sam膮 informacj臋 logiczn膮 (np. kod klienta, nr dokumentu,
itd.). Ale to wynika te偶 z pewnych mechanizm贸w w programowaniu
apliakcji, ale to ju偶 zupe艂nie inna bajka...

Tutaj chyba te偶:

Tabele TraNag (1:MANY) TraElem
Pola 艂膮cz膮ce TrN_TrNID = TrE_TrNId
Opcje Klucz obcy FK_TrETraNag


(...)
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.

Optima jest (by艂a?) pomy艣lana jako system "strojony" pod klienta.
Napraw膮 baz w za艂o偶eniu mieli si臋 zajmowa膰 serwisanci o r贸偶nym stopniu
wiedzy.
W dobrze zaprojektowanej i wdro偶onej aplikacji (i bazie danych
oczywi艣cie) nie ma prawa zdarzy膰 si臋 co艣 takiego jak "popsuta baza".
Nie wiem, mo偶e za ma艂o widzia艂em, ale... Zajmuj臋 si臋 MSSQLem od wersji
2000 na powa偶nie i nigdy nie mia艂em przypadku popsutej bazy danych, na
poziomie serwera.
Braki w danych, osercone dokumenty, zagubione transkacje - pewnie, 偶e
by艂o. Ale to by艂 efekt 藕le zaprojektowanej apliakcji. Tylko i wy艂膮cznie.

Nie wiem, czy dobrze si臋 wyrazi艂em.

Przyk艂ad:
Klient si臋 "waln膮艂" i z jakich艣 powod贸w trzeba faktur臋 wycowa膰 "do bufora" ("Bufor" oznacza, 偶e dokument jest zapisany, ale nie zatwierdzony "na sta艂e", mo偶na go dowolnie zmienia膰 lub usun膮膰).

Przy wycofaniu do bufora trzeba pami臋ta膰, aby wycofa膰 dokumenty magazynowe (czyli WZ), wycofa膰 p艂atno艣ci (czyli KP), wr贸ci膰 ewentualne rezerwacje i jeszcze wiele innych rzeczy.
Wydaje mi si臋, 偶e gdyby nie by艂o trigger贸w, to serwisant m贸g艂by przyk艂adowo wycofa膰 WZ, przywr贸ci膰 rezerwacje, ale zapomnia艂by o wycofaniu p艂atno艣ci.

Tym zajmuj膮 si臋 triggery.

Czy dobrze my艣l臋?


St膮d te偶 np. przy kasowaniu rekordu (bezpo艣rednio w bazie danych) w
TraNag (nag艂贸wku transakcji) sprawdzane s膮 najprzer贸偶niejsze warunki,
takie jak rezerwacje, p艂atno艣ci, stany na poszczeg贸lnych magazynach i
ca艂e mn贸stwo innych. St膮d kto艣 (nawet przypadkowy), kto "dobierze si臋"
do bazy danych SQL nawet prostym skanerem, nie jest w stanie jej zepsu膰.
No, chyba 偶e zna polecenie:
Alter table cdn.JakasTabela disable trigger all
Po pierwsze - nikt normalny nie daje bezpo艣redniego dost臋pu do bazy
danych. To jak gmeranie w nosie odbezpieczonym granatem.
Robi艂em takie cuda, jasne - alke to wymaga perfekcyjnej znajomo艣ci
logiki aplikacji i mechanizm贸w bazy danych. Jak nie popsujesz co艣 w
danych, to mozesz spowodowa膰 eskalacj臋 blokad - na przyk艂ad.

Czasami zdarza si臋 go u偶ywa膰, ostatnio np. musia艂em zmieni膰 definicj臋
numeracji kasy na "偶ywym" raporcie kasowym z SYMBOL/NR/ROK na
SYMBOL/NR/KASA/ROK czy jako艣 tak.

Tak wi臋c z mojego punktu widzenia trigger jest co najmniej pomocny, 偶eby
nie powiedzie膰 niezb臋dny. Ale by膰 mo偶e czego艣 nie wiem.
:-)
Nie obra藕 si臋, ale w艂a艣nie zacytowa艂e艣 mi standardow膮 regu艂k臋
producenta, kt贸ry musi jako艣 przekona膰 innych do swojego rozwi膮zania.
Ale ja tego nie kupuj臋 ;-)
Wi臋cej - mam wyrobione zdanie na ten temat poparte do艣wiadczeniem gdzie
by艂o mniej wi臋cej podobnie. I nigdy wi臋cej!
Tj. spora cz臋艣膰 logiki by艂a zaszyta w bazie danych, ale to nie by艂o
dobre. Moje do艣wiadczenia to nie tylko wdra偶anie, ale te偶 rozw贸j i
utrzymanie tak napisanej aplikacji.

Ale je艣li utrzymaniem aplikacji zajmuje si臋 ca艂y tabun student贸w?

Je艣li dodatkowe funkcje (i triggery, i co艣 tam jeszcze) dopisuje "tysi膮c" dystrybutor贸w i dealer贸w?



Dlaczego uwa偶am to za niezbyt szcz臋艣liwe rozwi膮zanie? Po pierwsze i
najwa偶niejsze - rozproszona odpowiedzialno艣膰 (nie wiem czy programujesz,
ale zapoznaj si臋 z zasad膮 SOLID a ja tu pisz臋 o pierwszej z nich, czyli
"single responsibility").

No w艂a艣nie.
Niedouczony serwisant nie da rady "zbuforowa膰" przyk艂adowej faktury, nie robi膮c ca艂ego ci膮gu zdarze艅 z tym zwi膮zanego. Albo spe艂ni wszystkie warunki, aby m贸c zbuforowa膰 faktur臋, albo trigger poinformuje go, 偶e zapomnia艂 wycofa膰 p艂atno艣膰.


Nie do ko艅ca wiadomo co robi aplikacja (i dlaczego), a co robi baza (i
dlaczego). Ja chc臋 mie膰 spok贸j i uwa偶am, 偶e aplikacja powinna by膰
wygodna w rozwouju i elastyczna w dostosowaniu.
Od tej pory minimalizuj臋 logik臋 w bazie do minimum - de-facto poza
utrzymaniem integralno艣ci wi臋cej logiki tam nie ma.
Tak, tak - wiem - to taki 艣wi臋ty Graal aplikacji biznesowych ;-)

Nie wyobra偶am sobie "gmerania" na bazie danych z
kilkudziesi臋ciostronicowym materia艂em opisuj膮cym jakie艣 zale偶no艣ci czy
uwarunkowania.
Tyle to piku艣 :D
Co powiesz na to; ok. 1100 tabel i 12 ty艣 procedur? Oczywi艣cie zero
dokumentacji technicznej - tylko aplikacja i profiler.
I we藕 w tym gmeraj ;-)


Mo偶na si臋 za艂ama膰 :(

Ja tak uczy艂em si臋 wieki temu pisa膰 w Clarionie 2.1 for DOS - widzia艂em aplikacj臋, mia艂em szcz膮tek dokumentacji po angielsku (a wtedy zna艂em mo偶e kilkadziesi膮t s艂ow po angielsku) i widzia艂em, co aplikacja robi.
Pr贸bowa艂em to powt贸rzy膰.
Dopiero jakie艣 3 lata p贸藕niej kto艣 napisa艂 podr臋cznik w j臋z. polskim. Napisa艂 zreszt膮 2 tomy, ale jak z nim rozmawia艂em, to drugiego nie uda艂o si臋 wyda膰.
Internetu jeszcze nie by艂o, tylko Fido i BBS-y.




Ale pogadamy mo偶e nieco p贸藕niej - Weso艂ych 艢wi膮t :)


--
Pozdrawiam.

Adam

Data: 2014-04-22 21:13:44
Autor: Adam
Serwer dla MS-SQL (crosspost)
W dniu 2014-04-19 22:11, Adam pisze:
W dniu 2014-04-19 21:03, wloochacz pisze:
W dniu 2014-04-19 19:00, Adam pisze:
(...)
W dobrze zaprojektowanej i wdro縪nej aplikacji (i bazie danych
oczywi禼ie) nie ma prawa zdarzy si co takiego jak "popsuta baza".
Nie wiem, mo縠 za ma硂 widzia砮m, ale... Zajmuj si MSSQLem od wersji
2000 na powa縩ie i nigdy nie mia砮m przypadku popsutej bazy danych, na
poziomie serwera.
Braki w danych, osercone dokumenty, zagubione transkacje - pewnie, 縠
by硂. Ale to by efekt 糽e zaprojektowanej apliakcji. Tylko i wy潮cznie.

Nie wiem, czy dobrze si wyrazi砮m.

Przyk砤d:
Klient si "waln背" i z jakich powod體 trzeba faktur wycowa "do
bufora" ("Bufor" oznacza, 縠 dokument jest zapisany, ale nie
zatwierdzony "na sta砮", mo縩a go dowolnie zmienia lub usun辨).

Przy wycofaniu do bufora trzeba pami阾a, aby wycofa dokumenty
magazynowe (czyli WZ), wycofa p砤tno禼i (czyli KP), wr骳i ewentualne
rezerwacje i jeszcze wiele innych rzeczy.
Wydaje mi si, 縠 gdyby nie by硂 trigger體, to serwisant m骻砨y
przyk砤dowo wycofa WZ, przywr骳i rezerwacje, ale zapomnia砨y o
wycofaniu p砤tno禼i.

Tym zajmuj si triggery.

Czy dobrze my秎?

(...)


Przypomnia硂 mi si jeszcze jedno wa縩e zadanie dla trigger體: dodatkowe warunki.

W systemie CDN-Optima nie ma mo縧iwo禼i zdefiniowania "wymagalno禼i" p髄.
Przyk砤dowo, formatka kontrahenta. Chcemy wymusi wprowadzenie warto禼i do pola "telefon" - najpro禼iej zrobi trigger, kt髍y b阣zie dar pysk, je秎i chcemy zapisa kart kontrahenta z pustym polem "telefon".
Oczywi禼ie to do舵 prosty, wr阠z trywialny przyk砤d.
Nie bardzo wiem, jak inaczej mo縩a by to zrobi.

Zaleta: triggery "prze縴waj" konwersj bazy danych do nowszej wersji, a Optima jest aktualizowana kilkukrotnie w ci眊u roku.



--
Pozdrawiam.

Adam

Data: 2014-04-23 13:24:05
Autor: wloochacz
Serwer dla MS-SQL (crosspost)
W dniu 2014-04-22 21:13, Adam pisze:
W dniu 2014-04-19 22:11, Adam pisze:
W dniu 2014-04-19 21:03, wloochacz pisze:
W dniu 2014-04-19 19:00, Adam pisze:
(...)
W dobrze zaprojektowanej i wdro偶onej aplikacji (i bazie danych
oczywi艣cie) nie ma prawa zdarzy膰 si臋 co艣 takiego jak "popsuta baza".
Nie wiem, mo偶e za ma艂o widzia艂em, ale... Zajmuj臋 si臋 MSSQLem od wersji
2000 na powa偶nie i nigdy nie mia艂em przypadku popsutej bazy danych, na
poziomie serwera.
Braki w danych, osercone dokumenty, zagubione transkacje - pewnie, 偶e
by艂o. Ale to by艂 efekt 藕le zaprojektowanej apliakcji. Tylko i wy艂膮cznie.

Nie wiem, czy dobrze si臋 wyrazi艂em.

Przyk艂ad:
Klient si臋 "waln膮艂" i z jakich艣 powod贸w trzeba faktur臋 wycowa膰 "do
bufora" ("Bufor" oznacza, 偶e dokument jest zapisany, ale nie
zatwierdzony "na sta艂e", mo偶na go dowolnie zmienia膰 lub usun膮膰).

Przy wycofaniu do bufora trzeba pami臋ta膰, aby wycofa膰 dokumenty
magazynowe (czyli WZ), wycofa膰 p艂atno艣ci (czyli KP), wr贸ci膰 ewentualne
rezerwacje i jeszcze wiele innych rzeczy.
Wydaje mi si臋, 偶e gdyby nie by艂o trigger贸w, to serwisant m贸g艂by
przyk艂adowo wycofa膰 WZ, przywr贸ci膰 rezerwacje, ale zapomnia艂by o
wycofaniu p艂atno艣ci.
A pewnie - m贸g艂by.
Gmeranie po bazie danych zawsze mo偶e sko艅czy膰 si臋 czym艣 podobnym.

Tym zajmuj膮 si臋 triggery.
Czy dobrze my艣l臋?
Dobrze, ale z zastrze偶eniem - tym mog膮 zajmowa膰 si臋 triggery.
Tak samo jak da si臋 to zrobi膰 za pomoca procedury wywo艂ywanej na 偶膮danie - np. przez aplikacj臋 serwisow膮.
Kiedy艣 dwano tem, jak zajmowa艂em si臋 wdro偶eniami ERP贸w, mia艂em ca艂y toolbox do takich zabaw ;-)


(...)


Przypomnia艂o mi si臋 jeszcze jedno wa偶ne zadanie dla trigger贸w: dodatkowe
warunki.

W systemie CDN-Optima nie ma mo偶liwo艣ci zdefiniowania "wymagalno艣ci" p贸l.
Przyk艂adowo, formatka kontrahenta. Chcemy wymusi膰 wprowadzenie warto艣ci
do pola "telefon" - najpro艣ciej zrobi膰 trigger, kt贸ry b臋dzie dar艂 pysk,
je艣li chcemy zapisa膰 kart臋 kontrahenta z pustym polem "telefon".
Oczywi艣cie to do艣膰 prosty, wr臋cz trywialny przyk艂ad.
Nie bardzo wiem, jak inaczej mo偶na by to zrobi膰.
Ale, moim zdaniem, to jest krzywe... walidacj膮 tego typu powinna zajmowa膰 si臋 aplikacja.
Powinna oferowa膰 u偶ytkownikowi stosowne mo偶liwo艣ci do definicji takich walidator贸w - w艂膮cznie z walidacj膮 opart膮 na wyra偶eniach/skryptach.
A je艣li tego nie robi - no c贸偶...

Zaleta: triggery "prze偶ywaj膮" konwersj臋 bazy danych do nowszej wersji, a
Optima jest aktualizowana kilkukrotnie w ci膮gu roku.
Raczej odwrotnie ;-)
Zauwa偶, 偶e MSSQL jest taki "gupi", 偶e nie sprawdza trigger贸w/procedur pod k膮tem zgodno艣ci ze schematem bazy danych.
Innymi s艂owy - stw贸rz trigger, kt贸ry robi cokolwiek i odw艂uje si臋 do jakiego艣 pola w tabeli.
Potem usu艅 to pole (zmie艅 nazw臋, cokolwiek) - teraz masz trigger, kt贸ry pieknie si臋 wysypie w momencie jego u偶ycia - ale nie wcze艣niej.

Poza tym, ogl膮dam dokumentacj臋 CDN - faktycznie, tam ejst cala masa trigger贸w, kt贸re wo艂aj膮 si臋 nawzajem.
Trafi艂em na taki zapis:
if @@NESTLEVEL>4 return

Uuuaaa... nie b臋d臋 si臋 wypowiada艂, bo za ma艂o wiem - ale to wygl膮da podejrzanie.

--
wloochacz

Data: 2014-04-24 00:01:47
Autor: Adam
Serwer dla MS-SQL (crosspost)
W dniu 2014-04-23 13:24, wloochacz pisze:
W dniu 2014-04-22 21:13, Adam pisze:
W dniu 2014-04-19 22:11, Adam pisze:
W dniu 2014-04-19 21:03, wloochacz pisze:
W dniu 2014-04-19 19:00, Adam pisze:
(...)
W dobrze zaprojektowanej i wdro縪nej aplikacji (i bazie danych
oczywi禼ie) nie ma prawa zdarzy si co takiego jak "popsuta baza".
Nie wiem, mo縠 za ma硂 widzia砮m, ale... Zajmuj si MSSQLem od wersji
2000 na powa縩ie i nigdy nie mia砮m przypadku popsutej bazy danych, na
poziomie serwera.
Braki w danych, osercone dokumenty, zagubione transkacje - pewnie, 縠
by硂. Ale to by efekt 糽e zaprojektowanej apliakcji. Tylko i
wy潮cznie.

Nie wiem, czy dobrze si wyrazi砮m.

Przyk砤d:
Klient si "waln背" i z jakich powod體 trzeba faktur wycowa "do
bufora" ("Bufor" oznacza, 縠 dokument jest zapisany, ale nie
zatwierdzony "na sta砮", mo縩a go dowolnie zmienia lub usun辨).

Przy wycofaniu do bufora trzeba pami阾a, aby wycofa dokumenty
magazynowe (czyli WZ), wycofa p砤tno禼i (czyli KP), wr骳i ewentualne
rezerwacje i jeszcze wiele innych rzeczy.
Wydaje mi si, 縠 gdyby nie by硂 trigger體, to serwisant m骻砨y
przyk砤dowo wycofa WZ, przywr骳i rezerwacje, ale zapomnia砨y o
wycofaniu p砤tno禼i.
A pewnie - m骻砨y.
Gmeranie po bazie danych zawsze mo縠 sko馽zy si czym podobnym.

Tym zajmuj si triggery.
Czy dobrze my秎?
Dobrze, ale z zastrze縠niem - tym mog zajmowa si triggery.
Tak samo jak da si to zrobi za pomoca procedury wywo硑wanej na 勘danie
- np. przez aplikacj serwisow.
Kiedy dwano tem, jak zajmowa砮m si wdro縠niami ERP體, mia砮m ca硑
toolbox do takich zabaw ;-)

Ja patrz z poziomu CDN-Optimy.
Tam w zasadzie opr骳z SQL Management Studio, albo prostego skanera nic wi阠ej nie potrzeba.

Oczywi禼ie jest te gar舵 procedur, ale czasem szybciej jest zrobi co "z palca". No, chyba 縠 wypuszczam "m硂dego" pracownika, to wol, aby u縴wa gotowych skrypt體.



(...)


Przypomnia硂 mi si jeszcze jedno wa縩e zadanie dla trigger體: dodatkowe
warunki.

W systemie CDN-Optima nie ma mo縧iwo禼i zdefiniowania "wymagalno禼i" p髄.
Przyk砤dowo, formatka kontrahenta. Chcemy wymusi wprowadzenie warto禼i
do pola "telefon" - najpro禼iej zrobi trigger, kt髍y b阣zie dar pysk,
je秎i chcemy zapisa kart kontrahenta z pustym polem "telefon".
Oczywi禼ie to do舵 prosty, wr阠z trywialny przyk砤d.
Nie bardzo wiem, jak inaczej mo縩a by to zrobi.
Ale, moim zdaniem, to jest krzywe... walidacj tego typu powinna
zajmowa si aplikacja.

Optima ma zdefiniowane jako "wymagalne" tylko najwa縩iejsze pola, reszta jest opcjonalna. Nie ma flag "wymagalno禼i"

Jak pisa砮m, jest to trywialny przyk砤d.
Ale mo縩a zrobi przyk砤dowo trigger, kt髍y b阣zie sprawdza histori p砤tno禼i, histori dokument體 sp砤canych po terminie i np. proponowa (lub przelicza) now tabel rabatow.

Powinna oferowa u縴tkownikowi stosowne mo縧iwo禼i do definicji takich
walidator體 - w潮cznie z walidacj opart na wyra縠niach/skryptach.
A je秎i tego nie robi - no c罂...

W Optimie skrypty mo縩a podpi辨 jako funkcj dodatkow, wo砤n na 縜danie przez operatora, lub jako filtr do widoku tabel, kt髍y to filtr mo縠 by wymagalny dla u縴tkownika. Przyk砤d: tabela pracownik體 w kadrach, gdzie poszczeg髄ne "panienki" mog mie dost阷 tylko do pracownik體 swojego wydzia硊, za "naczelna matrona" widzi wszystkich.


Zaleta: triggery "prze縴waj" konwersj bazy danych do nowszej wersji, a
Optima jest aktualizowana kilkukrotnie w ci眊u roku.
Raczej odwrotnie ;-)
Zauwa, 縠 MSSQL jest taki "gupi", 縠 nie sprawdza trigger體/procedur
pod k眛em zgodno禼i ze schematem bazy danych.
Innymi s硂wy - stw髍z trigger, kt髍y robi cokolwiek i odw硊je si do
jakiego pola w tabeli.
Potem usu to pole (zmie nazw, cokolwiek) - teraz masz trigger, kt髍y
pieknie si wysypie w momencie jego u縴cia - ale nie wcze秐iej.

Zgadza si.
Ale w Optimie przy konwersji danych do nowszej wersji s dodawane nowe pola (i klucze, i indeksy, i widoki), natomiast nigdy (chyba) nie s usuwane istniej眂e, nawet je秎i ju s niepotrzebne.
Przyk砤d:
w "starych" wersjach Optimy na kartotece towaru by砤 jednostka miary g丑wna i dodatkowa (np. sztuka i karton) oraz pole EAN.
Aktualnie (od kilku wersji) jest dowolna liczba jednostek miary przypisanych do jednej kartoteki towarowej (np. 1 szt, 12 szt= karton, 192 szt = skrzynka, 13824 szt=paleta) oraz do ka縟ej z tych jednostek mo縩a "doklei" dowoln liczb kod體 EAN.
St眃 m.in. pole "jm. dodatkowe" ju nie jest potrzebne, ale zostaje.
Tyle, 縠 trzeba w砤sne procedury, wydruki czy triggery pozmienia.

Kwestia dyskusyjna, czy lepiej, gdy trigger/procedura/wydruk od razu si wy硂縴, bo znikn瓿o pole, czy po miesi眂u klient zacznie wrzeszcze, 縠 co mu si 糽e liczy, bo procedura leci po pustych polach.


Poza tym, ogl眃am dokumentacj CDN - faktycznie, tam ejst cala masa
trigger體, kt髍e wo砤j si nawzajem.
Trafi砮m na taki zapis:
if @@NESTLEVEL>4 return

Uuuaaa... nie b阣 si wypowiada, bo za ma硂 wiem - ale to wygl眃a
podejrzanie.


W kt髍ym miejscu? Pami阾asz? Mo縠sz poda?

Ja ju kilka razy widzia砮m IF 1=1 AND  - te nie wiem, po co. Nie pami阾am, gdzie to by硂, ale jak znajd, to spytam.

Poza tym Ty teraz ogl眃asz chyba CDN-XL, natomiast Optima jest du縪 prostsza.



--
Pozdrawiam.

Adam

Data: 2014-04-24 15:31:42
Autor: Adam
Serwer dla MS-SQL (crosspost) - UWAGA: Essential ma zablokowane RD
W dniu 2014-04-18 14:22, wloochacz pisze:
W dniu 2014-04-18 13:19, Zgr pisze:
(...)
Od strony OS, b臋dzie to Win 2012 Std z CAL-ami lokalnymi i WinRmt oraz
SQL Srv Standard 2012.
Dlaczego nie Essential?
Powinien by膰 ta艅szy i ma wi臋cej softu na pok艂adzie.


Uwaga: znalaz艂em informacj臋, kt贸ra mo偶e by膰 bardzo istotna:

"Informujemy, 偶e licencja WS Essentials nie posiada mo偶liwo艣ci pracy terminalowej. Us艂uga terminalowa mo偶e s艂u偶y膰 jedynie do cel贸w administracyjnych (2 admin贸w). Niestety infolinie handlowe MS informuj膮 o takiej funkcjonalno艣ci, podczas gdy technicznie zosta艂a wy艂膮czona w tym produkcje. 鈥濷nly the RD Gateway role service is installed and configured, other RDS role services including RD Session Host are not supported.鈥 Podobna sytuacja wyst臋puje w wersji WS Foudandation 2012.

Rozwi膮zaniem jest postawienie terminala na osobnym serwerze (np. Windows Server Foundation 2008 OEM). Ma on jednak limit dost臋pu dla maksymalnie 15 u偶ytkownik贸w. WSF natomiast nie mo偶e by膰 jednocze艣nie kontrolerem domeny i serwerem terminali."

殴r贸d艂a nie podam, gdy偶 cytat pochodzi ze stron walidowanych dla dealer贸w CDN.



--
Pozdrawiam.

Adam

Data: 2014-04-24 15:45:41
Autor: wloochacz
Serwer dla MS-SQL (crosspost) - UWAGA: Essential ma zablokowane RD
W dniu 2014-04-24 15:31, Adam pisze:
W dniu 2014-04-18 14:22, wloochacz pisze:
W dniu 2014-04-18 13:19, Zgr pisze:
(...)
Od strony OS, b臋dzie to Win 2012 Std z CAL-ami lokalnymi i WinRmt oraz
SQL Srv Standard 2012.
Dlaczego nie Essential?
Powinien by膰 ta艅szy i ma wi臋cej softu na pok艂adzie.


Uwaga: znalaz艂em informacj臋, kt贸ra mo偶e by膰 bardzo istotna:

"Informujemy, 偶e licencja WS Essentials nie posiada mo偶liwo艣ci pracy
terminalowej. Us艂uga terminalowa mo偶e s艂u偶y膰 jedynie do cel贸w
administracyjnych (2 admin贸w). Niestety infolinie handlowe MS informuj膮
o takiej funkcjonalno艣ci, podczas gdy technicznie zosta艂a wy艂膮czona w
tym produkcje. 鈥濷nly the RD Gateway role service is installed and
configured, other RDS role services including RD Session Host are not
supported.鈥 Podobna sytuacja wyst臋puje w wersji WS Foudandation 2012.

Rozwi膮zaniem jest postawienie terminala na osobnym serwerze (np. Windows
Server Foundation 2008 OEM). Ma on jednak limit dost臋pu dla maksymalnie
15 u偶ytkownik贸w. WSF natomiast nie mo偶e by膰 jednocze艣nie kontrolerem
domeny i serwerem terminali."

殴r贸d艂a nie podam, gdy偶 cytat pochodzi ze stron walidowanych dla dealer贸w
CDN.
No to zawsze takiego Essentiala mo偶na doposa偶y膰 w Thinstuff Terminal Server
http://www.thinstuff.com/products/xpvs-server/
I tak wyjdzie sporo taniej; nie, nie testowa艂em, ale ficzery ma zach臋caj膮ce.


--
wloochacz

Data: 2014-04-24 15:48:25
Autor: wloochacz
Serwer dla MS-SQL (crosspost) - UWAGA: Essential ma zablokowane RD
W dniu 2014-04-24 15:45, wloochacz pisze:
No to zawsze takiego Essentiala mo偶na doposa偶y膰 w Thinstuff Terminal Server
http://www.thinstuff.com/products/xpvs-server/
I tak wyjdzie sporo taniej; nie, nie testowa艂em, ale ficzery ma
zach臋caj膮ce.
Albo nasz rodzimy WinFlector:
https://www.winflector.com/

Tego testowa艂em i dzia艂a艂o ca艂kiem fajnie.


--
wloochacz

Data: 2014-04-23 23:38:45
Autor: fReLuZ
Serwer dla MS-SQL (crosspost)
W dniu 2014-04-18 13:19, Zgr pisze:
Cze艣膰.

Potrzeby:
- baza danych na MS-SQL, perspektywicznie ponad 15GB
- dost臋p zdalny przez Remote Desktop dla 5 do 8 os贸b
- lokalnie (w sieci LAN) max. ok. 15 os贸b

Maszynka ma by膰 na kilka lat.

Czy co艣 takiego wystarczy:

Platforma: IBM x3500 M4 v2 (IBM 7383D5G)

Proc: 1x Xeon 6C E5-2630v2 80W 2.6GHz/1600MHz/15MB, ( mo偶liwo艣膰 dodania
+1 szt)

RAM: 2x 16GB (1x16GB, 2Rx4, 1.35V) PC3L-10600 CL9 ECC DDR3 1333MHz LP
RDIMM (IBM 46W0672)

Macierz: ServeRAID M5100 Series 512MB Flash/RAID 5, nie wymaga baterii
(IBM 81Y4487)

HDD: 5x IBM 300GB 2.5in SFF 10K 6Gbps HS SAS HDD (IBM 90Y8877) b臋d膮
ustawione w RAID5 (4 szt) + 1 szt. jako Hot Spare

2 x zasilacz 750W (IBM 94Y5974)

UPS UPS1500THV - 1050W (53962KX )

Od strony OS, b臋dzie to Win 2012 Std z CAL-ami lokalnymi i WinRmt oraz
SQL Srv Standard 2012.

Czy od strony sprz臋towej wystarczy to na jakie艣 pi臋膰 lat?

Szybsze dyski s膮 ponad dwukrotnie dro偶sze (IBM 81Y9670).
P贸藕niej mo偶na dorzuci膰 drugi procesor i RAM.


Jakie艣 inne propozycje?

Na sam膮 stron臋 sprz臋tow膮 bud偶et ograniczony do ok. 16 tys. z艂. netto.



generalnie i na oko jezeli to jakas aplikacja typu Optima - no to da rade.

Serwer dla MS-SQL (crosspost)

Nowy film z video.banzaj.pl wi阠ej »
Redmi 9A - recenzja bud縠towego smartfona