W dniu 2010-06-27 21:47, Robert Kois pisze:
> Dnia Sun, 27 Jun 2010 19:41:00 +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.

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

>>> Ale dlaczego wymagasz tego od elixiru? Bank dostaje na nazwę nadawcy 4
>>> linie po 35 znaków.
>> Czyli bardzo dobrze.
>> Linia 1: Nazwa, część 1.
>> Linia 2: Nazwa, część 2.
>> Linia 3: Ulica
>> Linia 4: Kod i Miejscowość
>> Nie trzeba przerabiać protokołu. Technicznie już wszystko jest i chyba
>> nawet jest wykorzystywane, skoro to działa.
> 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.

Poza tym, czemu mnie pytasz dlaczego tak chujowo zaprojektowani
eliksira? Przecież on taki jest.

>> O ile wiem (nie chce mi się sprawdzać) średnik nie jest
>>> znakiem niedozwolonym. Namów wszystkie banki by je wstawiały.
>> No wreszcie załapałeś ! Bezkosztowo, wystarczy się tylko umówić.
> 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.

>>> Co nie zmieni
>>> faktu, że nadal nie bardzo wiadomo co w danym polu będzie.
>> Jeżeli się umówią (co chyba już nastąpiło, skoro mój mBank ma to
>> podzielone na właściwe kawałki) co do kolejności, to wiadomo.
> 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.

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

Zresztą, przykład mBanku wykazuje, że jakoś bank to dzieli i nie uznali
tego za bezsensowne, tylko dokonują podziału.

>>>> Niestety gubi część informacji zawartych w tych bazach. Co uważam za
>>>> bezsensowne, bo koszt niegubienia byłby zerowy.
>>> Pokaż jak w tej chwili wprowadzić to co proponujesz zerowym kosztem.
>> Sam pokazałeś.
>> 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.

>> Wersja 2: Tak, jak podałem, każda linia ma znaczenie
> I padamy jak coś jest za długie.

Jako i teraz.

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


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

>>>>> Po to powstał. Prawdopodobnie miał być jak
>>>>> najprostszy by łatwo było się do niego dostosować.
>>>> No właśnie teraz jest skomplikowany. Moje założenia upraszczają go.
>>> Nie upraszczają, to co proponujesz mogłoby działać gdyby struktura danych
>>> we wszystkich bazach bankowych była jednakowa. Nie jest.
>> A jakie inne mają? Układ danych w Polsce jest dość typowy. Nie sądzę,
>> żeby któryś bank jakoś cudował inaczej. Najwyżej będzie niezgodny z ver.
>> 2, a całość odbędzie się tak, jak odbywa teraz.
> Nie jest tak pięknie.

A jednak.

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

>>>>> Błedna analogia. Ja nie wysyłam pieniędzy bankowi, bank jest tylko
>>>>> pośrednikiem. Jakby poczta skanowała sobie wszystkie adresy z kopert i
>>>>> trzymała w bazie to by było bliższe temu co mamy przy przelewach
>>>> No i to robi.
>>> Nie robi.
>> Wyciąłeś o kurierach, to się wypchaj.
> Bo nie ma to związku.

Ma.


> Jeszcze raz zapytam. Chcesz by obcy bank mógł sobie
> sprofilować cię jako klienta i trzymać sobie posortowane dane komu i za co
> płacisz?

Przecież nie w ten sposób banki to przetwarzają i nie ma to związku z
moim podziałem.


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

Po drugie: Nie o tym mowa, zupełnie.

>> Eurobank to w ogóle nie jest bank, tylko targowiskowa zabawka w
>> landrynkowej kolorystyce.
> Akurat mbank mógłby się od nich paru rzeczy nauczyć. Szczególnie w zakresie
> oferty produktowej. Bo co mi po świetnym systemie jak oferta do dupy.

Zależy pewnie z jakiej oferty produktowej korzystasz. Eurobank się w
końcu dorobił oferty dla przedsiębiorców? Bo kiedyś nie miał zupełnie. A
ofertę dla nie-przedsiębiorców też miał lichutką w zakresie, w jakim
korzystam.

>> No wiec właśnie. Zastanawiam się, kto im systemy pisze...
> Akurat oidp oni sami sobie napisali.

No ale tępota podobna mBankowej. Z łapanki biorą programistów i testerów?

>>>> Nie jest to konieczne. Stosując zasadę KISS i normalny tekstowy
>>>> protokół, można nie ograniczać rozmiarów lub ograniczyć je technicznie
>>>> na wartości na tyle duże, że będzie to pomijalne.
>>> [ciach]
>>> A teraz dostosujdo tego wszystkie banki i KIR.
>> KIRu nie trzeba, a banki się mogą dostosowywać sukcesywnie.
>
> Tylko, że to co proponujesz nie zadziała zawsze.

Zadziała. Co najwyżej nie zawsze dobrze rozpozna pola. Ale Twoja
alternatywa jest: nie rozpoznawać w ogóle pól.


> A banki bardzo nie lubią
> płacić za błędy.

Ale czym płacić i za jakie błędy? Proponujesz ,,nie da się 100%
skutecznie, nie dawajmy wcale''. Bez sensu i nieżyciowe.


> Oczywiście możnaby przeprojektować system (oprzeć choćby
> na xmlu) i dałoby to taką funkcjonalność jaką chcesz. Wszystko oparte na
> dotychczasowym formacie można najwyżej oprotezować i niektórzy to robią a
> niektórzy nie

Czyli się u niektórych da. I jak czasami się nie uda, to trudno.
Wystarczy nie gwarantować tego pod kosztem odszkodowania.

>>> Ale ty sugerujesz, że coś jest zjebane bo nie robi rzeczy do których nie
>>> było projektowane.
>> Owszem. Podobnie jak skopano wiele protokołów sieciowych. Ale jakoś nie
>> machnięto ręką i je poprawiono. I nawet Onet się ugiął niedawno i już
>> umożliwia szyfrowane transmisje poczty.
> Przy takim podejściu to www jest zjebane bo nie możesz sobie w prosty
> sposób posortować danych tak przesyłanych.

Co to jest www wg ciebie? Wg mnie to zbiór mniej lub bardziej ze sobą
powiązanych dokumentów rozproszonych po całym świecie. Nie jest to baza
danych, nie ma porządku umożliwiającego sortowanie i też sortowanie nie
jest potrzebne.

Nikt nie chce sortować wszystkich pism przesyłanych np. pomiędzy
mieszkańcami a zarządami ich spółdzielni mieszkaniowych.


--
Przemysław Adam Śmiejek