W dniu 2010-06-28 09:04, Robert Kois pisze:
> Dnia Sun, 27 Jun 2010 22:10:26 +0200, Przemysław Adam Śmiejek napisał(a):
>
>>>> Jeżeli SZBD nie pozwala zrobić zestawienia, to jest to zły system.
>>> Ależ pozwala, tylko nie takie jak sobie życzysz.
>> Nie. Nie pozwala zgodnie z zasadami SZBD.
> Pozwala. To że ty nie możesz to inna sprawa.


Wg Twojej interpretacji nie pozwala.

>>>> Czyli jednak banki chyba się jakoś dogadały albo
>>>> mają w mBanku bardzo dobry parser.
>>> Pewnie mają, ale może nie chcą dawać za darmo.
>> Nie widzę możliwości zapłacenia za poprawny plik CSV.
> Zapytaj banku, może udostępniają narzędzia, a może nie. Ino elixir nie ma
> nic do tego.

Owszem, omawiamy kilka spraw:

a) czemu mBank nie daje dobrego csv
b) czy eliksir ma psuć pola czy nie


> [ciach]
>>> Co robisz jak nazwa firmy ma 80 znaków? Przycinamy? A jak są 2 firmy które
>>> różnią się tylko ostatnim wyrazem nazwy?
>> Wg ciebie nie ma to najmniejszego znaczenia.
> Ale dla ciebie ma.

Dzięki, że mówisz za mnie.

> Mi wystarczyłaby sama nazw (a nawet jej część
> wystarczająca mi do identyfikacji nadawcy)a, ty domagasz się pozostałych
> danych adresowych. Z mojego punktu widzenia działa (z dokładnością do
> spieprzonego cvsa z mbanku).

No więc Tobie moja wersja nie szkodzi. MI moja wersja daje bonusy.

>> Poza tym, czemu mnie pytasz dlaczego tak chujowo zaprojektowani
>> eliksira? Przecież on taki jest.
>
> Jeszcze raz, powoli. Elixir robi dokładnie to, czego od niego się wymaga.
> Nie jest baza danych, jest systemem rozliczeniowym.

z protokołem transmisji danych pomiędzy bazami, który to protokół mógłby
być lepiej zaprojektowany.

>>> Błąd, to nie jest bezkosztowo. Te średniki soft musi wstawiać a potem
>>> obrobić. Krasnoludki za mleko tego nie zrobią.
>> Uważasz, że linijka:
>> dane = imię + nazwisko + cośtam
>> wykonuje się tak bardzo wydajniej, że linijka
>> dane = imię + ";" + nazwisko + ";" + cośtam
>> będzie takim kosztem?
>> Sparsowanie tego też będzie mniejszym kosztem niż parser zgadujący.
> A parsery to się same napiszą.

Obecny parser mBanku jakoś działa i jakoś się napisał. Więc chyba mBank
uznał że warto.

Przecież nie mówię: ,,Zmusić wszystkich do parsera'', tylko ,,dać taką
możliwość''. Kto chce, skorzysta. Dla niekorzystających nie generuje to
żadnych kosztów. Dla korzystających daje możliwości.

>>> Jak widać z twoich kiepskich przykładów powyżej to może działać ale
>>> niekoniecznie musi.
>> I tak jest lepsze niż brak w ogóle działania.
> To zależy od punktu widzenia.

Pokaż zalety z wersji ,,nie działa wcale''.

>>>> Prosty parser to załatwia, ale jak bank przekaże błędne
>>> dane klientowi to kilent będzie domagał się odszkodowania. Bez porządnego
>>> podziału nie są w stanie zagwarantować 100% zgodności. I to, że ty się nie
>>> przejmiesz jak raz dostaniesz obcięta nazwę ma dla banku małe znaczenie.
>> Strasznie coś kręcisz i mącisz. Przed chwilą te dane były zupełnie bez
>> znaczenia dla ciebie, teraz znów jest tragedia, jak coś się nie uda
>> czasami i jest to powód do pozostania przy systemie, gdy zupełnie nie ma
>> nic....
> Jeszcze raz, mnie to zwisa. Ale może znajdzie się klient który za coś
> takiego pozwie bank.

A teraz nie pozwie?

>>>> Wersja 1: Uznajemy całe pole jako jeden ciąg i dzielimy go sobie
>>>> wewnętrznie jakimś znakiem umownym oraz umawiamy się co do kolejności pól.
>>> NNie da się, jeżeli nie mamy porządnie opisanego formatu to wyjątki nas
>>> zjedzą. Ot weź sobie jakiegoś hiszpana z kilkoma imionami.
>> No i? Zupełnie nie koliduje.
> Oczywiście, no chyba, że te imiona i nazwiska przekroczą 70 znaków. I już
> masz problem.

A teraz nie masz? Przecie ograniczenie pól już istnieje.

>>>> Wersja 2: Tak, jak podałem, każda linia ma znaczenie
>>> I padamy jak coś jest za długie.
>> Jako i teraz.
> Ale teraz nikt nie traktuje tego jako kluczową daną. Jest to czysto
> informacyjne.

No i niech takie zostanie, skoro się boisz pozwów.

>>> Tak btw to zdajesz sobie sprawę, że nie
>>> wszędzie na świecie są kody pocztowe?
>> No i? Eliksir działa w Polsce.
>> Zresztą, taki format danych w Polsce jest stosowany nagminnie, a wyjątki
>> zagraniczne jakoś się do niego nagina.
> O tym, że obcokrajowiec może mieć konto w Polsce chyba wiesz.

No i? Jakoś banki stosują to nagminnie i żyją z tym.

> No i nadal
> mamy problem z firmami które potrafią mieć długie nazwy.

Mamy. Nie moja wina, że zaprojektowano eliksir z ciasnymi ograniczeniami.


>>>> Co zresztą chyba już nastąpiło.
>>> Nic nie nastąpiło. Zauważyłbyś to jakby ci się chciało poszukać jak działa
>>> elixir.
>> Jakoś mBank sobie radzi.
> A pan Zitek sobie wklepuje dane do programu księgowego i też mu działa.

I kosztuje.

> Tylko co to ma wspólnego z formatem danych w elixirze?


Nic, najlepiej jakby eliksir przesyłał dane tak zmiksowane, żeby w ogóle
ich rozpakowanie trwało miesiąc i wymagało pracy sztabu osób. AMEN.

Dla mnie EOT.


>>> Jak pokazałem wyżej to nie takie proste
>> Nic nie pokazałeś. Pokazałeś, że jakieś wyjątki się nie łapią,
>> analogicznie jak teraz.
> Ale teraz to nie ma znaczenia.

I nadal nie musi mieć. Może być tylko wygodą dla Tristana i podobnych.

>>> A potem wykorzystać to np. przy twoim wniosku kredytowym?
>> Po pierwsze: Czemu nie? Dla mnie np. czad, że od 10 lat jestem klientem
>> mBanku i na podstawie historii mi dają różne rzeczy od ręki i nie muszę
>> latać i załatwiać wniosków w kolorach tęczy.
>
> A na podstawie twoich przelewów z mbanku takie pekao stwierdzi np. że masz
> kochankę, płacisz alimenty i na dodatek kupiłeś samochód o jakiegoś ich
> klienta.


Niech se stwierdza. Zresztą zupełnie nie widzę związku z moim podziałem
danych a tą wiedzą.

> http://www.eportfel.com/?q=ePortfel/licencje Czemu sobie nie kupisz czegoś
> takiego? Wygląda, ze robi dokładnie to co chcesz.

Pomijając konieczność płacenia przez klientów banków, to jak to ma
działać? Może działać tylko, jak będzie miało już gotowe dane, więc
właśnie wtedy, gdy będzie wg mojej wersji. A wtedy wystarczy mi arkusz.

--
Przemysław Adam Śmiejek