eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.comp.programming[OT] Duża kasa i kiepski wynik - dlaczego?Re: [OT] Duża kasa i kiepski wynik - dlaczego?
  • Path: news-archive.icm.edu.pl!news.icm.edu.pl!newsfeed.pionier.net.pl!feeder.erje.net
    !1.eu.feeder.erje.net!feeder2.ecngs.de!ecngs!feeder.ecngs.de!81.171.118.62.MISM
    ATCH!peer02.fr7!news.highwinds-media.com!newsfeed.neostrada.pl!unt-exc-02.news.
    neostrada.pl!unt-spo-a-02.news.neostrada.pl!news.neostrada.pl.POSTED!not-for-ma
    il
    Date: Fri, 31 Jul 2015 10:43:27 +0200
    From: Tomasz Kaczanowski <kaczus@dowyciecia_poczta.onet.pl>
    User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; pl; rv:1.8.1.24) Gecko/20100228
    Thunderbird/2.0.0.24 Mnenhy/0.7.6.0
    MIME-Version: 1.0
    Newsgroups: pl.comp.programming
    Subject: Re: [OT] Duża kasa i kiepski wynik - dlaczego?
    References: <mosvh7$bpl$1@node1.news.atman.pl>
    <55b21285$0$27508$65785112@news.neostrada.pl>
    <mot44o$gd5$1@node1.news.atman.pl>
    <55b2155e$0$27524$65785112@news.neostrada.pl>
    <X...@1...0.0.1>
    <55b71c91$0$2196$65785112@news.neostrada.pl>
    <X...@1...0.0.1>
    <55b8669a$0$27509$65785112@news.neostrada.pl>
    <s...@n...lan>
    <c...@g...com>
    <X...@1...0.0.1>
    <s...@n...lan>
    <X...@1...0.0.1>
    <s...@n...lan>
    <X...@1...0.0.1>
    <s...@n...lan>
    <X...@1...0.0.1>
    In-Reply-To: <X...@1...0.0.1>
    Content-Type: text/plain; charset=ISO-8859-2; format=flowed
    Content-Transfer-Encoding: 8bit
    Lines: 73
    Message-ID: <55bb3530$0$27507$65785112@news.neostrada.pl>
    Organization: Telekomunikacja Polska
    NNTP-Posting-Host: 79.187.17.90
    X-Trace: 1438332209 unt-rea-a-02.news.neostrada.pl 27507 79.187.17.90:46663
    X-Complaints-To: a...@n...neostrada.pl
    X-Received-Bytes: 4687
    X-Received-Body-CRC: 779675264
    Xref: news-archive.icm.edu.pl pl.comp.programming:207991
    [ ukryj nagłówki ]

    W dniu 2015-07-31 10:00, Budzik pisze:
    > Użytkownik Pit n...@s...lonestar.org ...
    >
    >>>>> 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.

    >
    >> , 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?

    > - 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.

    > - 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ą.

    > 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ć, 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.


    --
    Kaczus
    http://kaczus.ppa.pl

Podziel się

Poleć ten post znajomemu poleć

Wydrukuj ten post drukuj


Następne wpisy z tego wątku

Najnowsze wątki z tej grupy


Najnowsze wątki

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo: