🚀 go-pugleaf

W dniu 2017-07-05 o 15:21, Adam pisze:
> W dniu 2017-07-05 o 13:30, wloochacz pisze:
>> W dniu 2017-06-20 o 15:20, Adam pisze:
>> /ciach/
>>
>>> Natomiast Symfonia czy jakieś tam Inserty mają oprócz tego, co
>>> napisałeś jeszcze sporo innych problemów. Najpoważniejsze: brak
>>> spójności systemu. Bywa u klientów, że towar zostanie pobrany na
>>> dokument, a nie zejdzie ze stanu magazynowego.
>>>
>>> W przypadku Optimy, CDN-XL czy Enovy - o spójność baz danych dbają
>>> triggery.
>> No popatrz, mam bazę Enovy (stan na rok 2015, ale nie sadzę aby były aż
>> tak poważne zmiany) pod ręką i nie ma w niej ani jednego triggera.
>> Tak wszystko co piszesz poniżej w kontekście Enovy, nie jest prawdziwe...
> 
> Aż zobaczyłem do jakiejś bazy:
/ciach/

> itd - 490 rekordów.
No i co tam zobaczyłeś, bo  nic z tego nie rozumiem...

> Optimka ma 272, CDN-XL ma 852.
> Zresztą do XL masz dokumentację, podsyłałem Ci kiedyś.
Pisałem o Enovie, a Ty mi tu pokazujesz XL.
A to, że "logika" w ERP XL jest w bazie danych, to jasne.
Burdel z tym taki, że łooo matko...
A najlepiej jest wtedy, gdy mam na przestrzeni kilku lat, kilka firm 
obsługujących ten sam system u klienta (tzw. fakt autentyczny i dotyczy 
ERP XL), robi własne zmiany w triggerach.
Każda z tych firm grzebie sobie w bazie jak im się podoba.
Po kilkunastu takich zmianach, nikt tak naprawdę nie wie co w tym 
trigger-hell się dzieje i kiedy się dzieje...

>>> Albo cała transakcja (w znaczeniu ścieżki logicznej zdarzeń)
>>> przejdzie, albo cała zostanie wycofana. Nawet, gdybym grzebał
>>> bezpośrednio w tabelach z danymi, transakcje są spójne, albo trigger
>>> nie pozwoli zmienić pola, gdy pozostałe warunki nie są zachowane.
>>> Jest to bardzo dobre dla serwisantów.
>> Dobre dla serwisantów?
>> A co to za serwisant, który grzebie w bazie nie wiedząc jakie będę tego
>> konsekwencje dla całego systemu?
>>
>> Taki "serwisant" niech lepiej trzyma lepkie łapki blisko siebie...
> 
> E, tam, nie przesadzaj.
Jasne, ale mam inną opinię.

> Przykładowy trigger dotyczący elementu transakcji (np. faktury) poniżej.
Myślę, że ten trigger  jest z definicji zjebany.

Select top 1?
A co w przypadku, kiedy insert będzie batchowy i będzie więcej niż jeden 
rekord wkładany w tym samym czasie?

Dlatego powtórzę: "Taki "serwisant" niech lepiej trzyma lepkie łapki 
blisko siebie..."
Na co Ty - nie przesadzaj...

 > Myślisz, że bez triggera ktoś by to zapamiętał?
Tak, ale to wymaga programowania w ERPie, a nie w jego bazie.

Poza tym ten cały trigger, jest wzorcowym przykładem jak nie należy tego 
robić i dlaczego nie należy tak tego robić.
Po prostu utrzymanie takiego systemu to istny horror-szoł...

>>> Przykład z życia: pad prądu w środku wpisywania dokumentu. W różnych
>>> systemach następuje rozjazd pomiędzy stanami handlowymi a stanami
>>> magazynowymi, natomiast w Optimie/XL/Enovie praktycznie nigdy. Znam
>>> tylko kilka zgłoszonych przypadków przez blisko 20 lat.
>> Zatem mylisz transakcję bazodanową (która została wycofana, po padł
>> prąd), ze spójnością danych logicznych zapewnioną przez triggery, po
>> stronie bazy danych.
>> I tak przez blisko 20 lat :P
>>
> 
> Być może mylę - nie przeczę.
> Bazodanowa - to jak coś w rodzaju TTS w Novellu?
Bazodanowa to bazodanowa, zgodna z ACID.
W porównaniu do ACID, TTS w Novell to bieda wersja, ale głównie dlatego 
że operuje na plikach (czy na blokach pliku? Ja jestem noga od Novella i 
wiem tyle ile wyczytam) i z tego co wiem, wymaga interakcji z Novell TTS.
W bazie danych nie posługujesz się pojęciem pliku i nic Cię on nie 
obchodzi, a sama transakcja dotyczy wszystkich (zazwyczaj chodzi o 
polecania DML, ale bywa różnie w różnych bazach danych) poleceń SQL, 
które są nią objęte.

> Ale to chyba na innym poziomie, niż logiczna spójność. Muszę doczytać. 
> Jakiś link?
ACID
https://pl.wikipedia.org/wiki/ACID
https://msdn.microsoft.com/en-us/library/aa480356.aspx?f=255&MSPPError=-2147217396

-- 
wloochacz