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

do góry

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

do góry

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

do góry

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-s
ql-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-co
march-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

do góry

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-co
march-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

do góry

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-co
march-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

do góry

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

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

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

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 wyobrażam sobie "gmerania" na bazie danych z
kilkudziesięciostronicowym materiałem opisującym jakieś zależności czy
uwarunkowania.


--
Pozdrawiam.

Adam

do góry

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

do góry

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

do góry

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.
>
> Tym zajmują się triggery.
>
> Czy dobrze myślę?
>
> (...)
>

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

Zaleta: triggery "przeżywają" konwersję bazy danych do nowszej wersji, a
Optima jest aktualizowana kilkukrotnie w ciągu roku.



--
Pozdrawiam.

Adam

do góry