Dnia 24.07.2015 Tomasz Kaczanowski <kaczus@dowyciecia_poczta.onet.pl> napisał/a:
> Bazę o takich rozmiarach w mysql-u? Dowcip?

Skoro Wikipedia daje radę na mySQL-u to czemu nie baza danych z kartami
pacjentów?

do góry

Dnia 24.07.2015 Pit <n...@s...lonestar.org> napisał/a:
>
> Skoro Wikipedia daje radę na mySQL-u to czemu nie baza danych z kartami
> pacjentów?

Taki niepozorny serwis jak YouTube również w znaczący sposób korzysta z
MySQL.

https://github.com/youtube/vitess

do góry

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

>> Ten system (wybory) dało się zrobić za te "grosze". Wybrano tylko
>> wyjątkowych ignorantów którzy wybrali jeszcze mniej kumatych wykonawców.
>> Ale co może być skomplikowanego w wysłaniu kilku raportów i podpisaniu
>> kluczem? Nie przesadzajmy, kumaty programista da radę to zrobić za kase
>> mniejszą.
>
> hmmm 0.5 miliona? - sorki, ale za to na rok nie zatrudnisz nawet osób
> gotowych dobrze to wykonać. Sorki - ale kumaty programista nie
> zaproponuje do bazy z takim obciążeniem mysql-a - i proszę nie dawać mi
> tu przykładu facebooka, bo tam użyty mysql nie ma zbyt wiele wspólnego
> po za nazwą z tym co jest do zainstalowania.

Wysłanie protokołów z komisji wyborczych (mało danych, stosunkowo mało
zapytań) to jest jakieś poważne obciążenie?
Hmm...

do góry

W dniu piątek, 24 lipca 2015 23:15:54 UTC+2 użytkownik grapeli23 napisał:
> Dnia 24.07.2015 Pit <n...@s...lonestar.org> napisał/a:
> >
> > Skoro Wikipedia daje radę na mySQL-u to czemu nie baza danych z kartami
> > pacjentów?
>
> Taki niepozorny serwis jak YouTube również w znaczący sposób korzysta z
> MySQL.
>
> https://github.com/youtube/vitess

To jest kwestia supportu. Youtube czy Wikipedia taki support zapewniają sobie same,
ponadto, nie jest dla nich problemem upgrade. System dla ministerstwa zdrowia nie
będzie miał własnego supportu (w formie developerów), w związku z czym musi opierać
się na oprogramowaniu którego okres supportu (i wypuszczania patchy) liczy się w
dziesiątkach lat, a to aktualnie zapewniają tylko rozwiązania komercyjne.

AdamK

do góry

On 2015-07-25 22:08, Adam Klobukowski wrote:
> w związku z czym musi opierać się na oprogramowaniu którego okres supportu (i
wypuszczania patchy) liczy się w dziesiątkach lat

Zastanawia mnie dlaczego tak cieżko zrobić raz na kilka lat refaktoring.
To tylko gówniana baza danych. Niewiele da się popsuć. Wystarczyło by ta
kasę rozbić na transze i co jakiś czas zatrudniac kogoś do pchnięcia
software do przodu.

My już mamy taki system który przypomina zbrojony beton odlany przed
wiekami - Elixir. Czekaj i płacz.

do góry

On Sun, 26 Jul 2015 16:50:02 +0200, Sebastian
Biały<h...@p...onet.pl> wrote:
> To tylko gówniana baza danych.

Famous last words.

RW

do góry

W dniu niedziela, 26 lipca 2015 16:50:06 UTC+2 użytkownik Sebastian Biały napisał:
> On 2015-07-25 22:08, Adam Klobukowski wrote:
> > w związku z czym musi opierać się na oprogramowaniu którego okres supportu (i
wypuszczania patchy) liczy się w dziesiątkach lat
>
> Zastanawia mnie dlaczego tak cieżko zrobić raz na kilka lat refaktoring.
> To tylko gówniana baza danych. Niewiele da się popsuć. Wystarczyło by ta
> kasę rozbić na transze i co jakiś czas zatrudniac kogoś do pchnięcia
> software do przodu.

Bo po kilku latach nikt nie zna szczegółów projektu, ludzie się rozchodzą do innych
projektów. Dokumentacja może i jest (ale nie pomaga).

Koszt aktualizacji systemu tej wielkości jest porównywalna z kosztem nowego
wdrożenia, a w wielu przypadkach większa. Nikt tego nie będzie robił "bo wyszedł nowy
MySQL, a stary jest już nie wspierany".

AdamK

do góry

On 2015-07-27 08:30, Adam Klobukowski wrote:
> Koszt aktualizacji systemu tej wielkości jest porównywalna z kosztem nowego
wdrożenia

To jest niemożliwe albo oparte o systemy odlewane ze zbrojonego betonu.
Przyznam że wiekszość jest odlewana skoro w dziesiątki mln idą dodatkowe
ficzery lub niemożność ich dodania.

> Nikt tego nie będzie robił "bo wyszedł nowy MySQL, a stary jest już nie wspierany".

Efektem takiego podejścia jest "no tak, musimy działać na tym ostatnim
co nam został S/360 bo tak". Czli koszta supportu lecą w kosmos, koszta
hardware w inny wymiar a jako kierownika tego zabytku zatrudnia się
nekromatę. Jesteś pewny że to jest "lepiej" na dłuższą metę?

PS. Tak wiem że systemy obrony/ataku nuklearnego w USA obsługuje się
dyskietkami 8" i nie zamierzają tego zmienić.

do góry

Dnia 27.07.2015 Sebastian Biały <h...@p...onet.pl> napisał/a:
> On 2015-07-27 08:30, Adam Klobukowski wrote:
>> Koszt aktualizacji systemu tej wielkości jest porównywalna z kosztem nowego
wdrożenia
>
> To jest niemożliwe albo oparte o systemy odlewane ze zbrojonego betonu.

Koszt zapoznania się z nieznanym systemem, zrozumienia jego funkcjonowania
itp. może przekroczyć koszty napisania odpowiednika od zera. Mimo że masz
źródła, to i tak to jest praktycznie reverse engineering (jeśli nie masz do
tego dobrej dokumentacji). Oczywiście wszystko też zależy od typu
aplikacji, bo jeśli jest to prosty interfejs do bazy danych, to sprawa jest
znacznie prostsza niż na przykład system optymalizujący przepływ wagonów
towarowych na kolei.

> Przyznam że wiekszość jest odlewana skoro w dziesiątki mln idą dodatkowe
> ficzery lub niemożność ich dodania.

Bo "ficzer" to nie zawsze jest banalna sprawa, nawet jeśli system jest
bardzo elastycznie zaprojektowany. Często to jest coś w rodzaju "dołóżcie
możliwość tankowania diesla benzyną".

>
>> Nikt tego nie będzie robił "bo wyszedł nowy MySQL, a stary jest już nie
wspierany".
>
> Efektem takiego podejścia jest "no tak, musimy działać na tym ostatnim
> co nam został S/360 bo tak". Czli koszta supportu lecą w kosmos, koszta
> hardware w inny wymiar a jako kierownika tego zabytku zatrudnia się
> nekromatę. Jesteś pewny że to jest "lepiej" na dłuższą metę?

Nie dalej jak rok temu została wyłączona ostatnia Odra pracująca na kolei
(nie pamiętam już gdzie). Skoro coś działa bezawaryjnie i wystarczająco dobrze,
to wymiana tego na coś równie dobrego tylko nowszego jest zawsze droższe.
Skoro Odra miała wystarczającą wydajność obliczeniową, pojemność pamięci,
wygodę obsługi i bezawaryjność (a przez tyle lat pracy wyeliminowano z
systemu praktycznie wszystkie błędy), to po co to zmieniać na coś nowego?
Co z tego że teraz byle smartfon bije Odrę na głowę jeśli chodzi o moc
obliczeniową i pamięć, skoro ta moc byłaby nieużywana i miałoby to
dokładnie taki sam sens jak ładowanie 8-rdzeniowego Intela do sterowania
pralką automatyczną?

> PS. Tak wiem że systemy obrony/ataku nuklearnego w USA obsługuje się
> dyskietkami 8" i nie zamierzają tego zmienić.

Bez przesady, są stosowane dyski wymienne, bo do dysku wyjętego nie można
się włamać, a przy okazji są pozabezpieczane przed EMP, pożarem, zalaniem
itp. (są odporniejsze niż czarne skrzynki w samolotach). Przy okazji weź
poprawkę na to, że tam komputery i software są mocno związane z
uzbrojeniem, jak jakąś rakietę się programuje przez RS-232 albo przez
włożenie dyskietki 3,5", to przerobienie tego na wszechobecne teraz Wifi
czy Bluetooth nie jest tylko kwestią wymjiany komputera i softu na nim, ale
też przebudowania tej rakiety, zapewnienie odporności na
zakłócenie/włamanie, zapewnienie że po EMP nadal się da zaprogramować
rakietę (że napięcia zindukowane w antenach WiFi/Bluetooth nie "spalą"
elektroniki do tych anten przypiętych) itd.

do góry

W dniu 2015-07-24 23:14, grapeli23 pisze:
> Dnia 24.07.2015 Pit<n...@s...lonestar.org> napisał/a:
>>
>> Skoro Wikipedia daje radę na mySQL-u to czemu nie baza danych z kartami
>> pacjentów?
>
> Taki niepozorny serwis jak YouTube również w znaczący sposób korzysta z
> MySQL.
>
> https://github.com/youtube/vitess
>

A wiedzą, że sa to trochę inne systemy. A o czymś takim jak transakcje
słyszał, a o czymś takim jak bardziej zaawansowane rzeczy niż proste
czytanie danych i jakieś proste zapisy słyszał? Jak się dowie czegoś
więcej o bazach, to niech wróci i nie porównuje zastosowania przy
prostych stronach do czegoś bardziej skomplikowanego. Wiem, że w końcu
pojawiły się triggery, funkcje składowane itd, ale wszystko to ciągle
działa ułomnie.

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

do góry