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