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