Użytkownik Tomasz Kaczanowski kaczus@dowyciecia_poczta.onet.pl ...

>>>>>> Ale ja nie pisze jak było tylko ze wymagania nie były jakies
>>>>>> wielkie i nie był potrzebny jakis mega hiper system.
>>>>>> Potrzebny był za to w miare prosty system, ale dobrze napisany.
>>>>>
>>>>> Oczywiście że nie potrzeba jakiegoś mega hiper systemu, może nawet w
>>>>> tym co było wystarczyło mądrze serwer (dać mniej równoległych sesji,
>>>>> przez co byłyby "załatwione" szybciej i bez rozsypywania się
>>>>> integralności danych ze względu na wyskakujące timeouty czy "out of
>>>>> memory").
>>>>
>>>> cbdu.
>>>
>>> Komu? Sobie? :D
>>
>> Ogólnie :)
>>
>>> Przecież nie twierdziłem, że potrzebny jest
>>> "hipersystem"
>>
>> Inni twierdzili.
>
> Nikt nie twierdził, że supersystem jest potrzebny, tylko wiedza jak to
> zrobić i pomysły SF, które podajesz pewnie przyszły do głowy twórcom, po
> weryfikacji z rzeczywistością (np z przepisami i wymogami) polegli.
>
Myslisz?
>>
>>> , napisałem jedynie, że nie jest to zadanie trywialne
>>> typu "jeden insert na każdy obwód i po sprawie" i jeśli to ma działać
>>> "live" (nie na zasadzie teraz coś wysyłam, a za godzinę dostaję
>>> potwierdzenie, że wysłałem, tylko praktycznie natychmiast, czyli w
>>> ciągu powiedzmy maksymalnie pół minuty) to sporo rzeczy jest do
>>> przemyślenia, bo "pułapki" jak najbardziej są.
>>>
>> Przychodzi mi na mysl inne, trywialne rozwiazanie.
>> - weryfikacja danych na poziomie programu w komisji
>
> Takk i przy zakłóceniu komunikacji, gdy nie przyjdą wszystkie dane
> poprawnie żadnej kontroli, choćby sumy kontrolnej?
>
nie przekrecaj.
Mowiłem o tym, zeby w bazie danych nie obrabiac ich na zywo i zeby nie
sprawdzac poprawnosci protokołu.
Poprawnosc techniczna przesłanej paczki np. suma kontrolna to oczywista
oczywistosc.

>> - wrzucenie pliku wynikowego przez ftp (to tez mogłby robic to program)
>
> A co z potwierdzeniem poprawności danych i akceptacją przyjęcia? Wiesz -
> dopóki takiej nie ma, komisja nie może się rozejść do domu.
>
Poprawnosc danych - wydawałby program, skoro to on weryfikował.
Lokalnie.
Akceptacja przyjecia - wydawałby program po potwierdzeniu, ze plik został
prawidłowo przesłany.

>> - a dalej juz serwer przerabia sobie pliki we własnym zakresie, w
>> odpowiedniej dla siebie predkosci.
>
> Przecież podawane było, że to nie jest kwestia wydajności serwera, tylko
> złego projektu programistycznego i na to, że system nie zadziałał
> złożyło się wiele przyczyn, ale podstawowa to była taka, że tym, którzy
> go tworzyli wydawało się, że wiedzą.
>
Jasne.
Ale wyłożyli sie na kolejkowaniu etc. Tak pisaliscie.
Gdyby mogli sami decydowac o tym, jak pliki sa obrabiane, to pewnie nie
mieliby problemu z natłokiem zapytan i rozjechaniem sie danych.

>> Przeciez ten system nie musiał działać online w sensie ze od razu przy
>> polaczeniu dane lądowały we wspolnej bazie, prawda?
>
> Musiało być zatwierdzenie, jak później to rozwiązać

jw.

>, czy będzie pełne
> księgowanie, czy tak jak było kiedyś w niektórych systemach bankowych,
> najpierw księgowanie uproszczone, a następnie przetwarzanie (dlatego w
> niektórych bankach np w nocy nie dało sie zrobić operacji kartami w
> dawnych czasach, bo było tzw "przetwarzanie"), to na prawdę najmniejszy
> problem. I nikt nie mówi, że mając sprzęt, który był nie dało się tego
> przeprowadzić prawidłowo, ale żeby to zrobić, trzeba było mieć trochę
> więcej wiedzy. A to, że rozjechały sie dane po pierwszych awariach
> nasuwa mi pomysł, że i sama baza danych była zrobiona źle i dlatego
> wszystko dupnęło.
>
To co było potrzebne zeby zrobic to dobrze?
Mielismy po prosut pecha?
Drugie pol miliona zł?