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
|