🚀 go-pugleaf

W dniu 26.04.2019 o 10:17, Wojciech Bancer pisze:
> On 2019-04-25, Kviat <Kviat> wrote:
> 

>>> To co pisałem o triggerach odnosiło się do świata serwerowo-webowego,
>>> nie do desktopowych aplikacjach klienckich przeznaczonych do działania
>>> w intranecie.
>>
>> Twoją wypowiedź odebrałem tak, że triggery/sp są złe bo są złe,
>> niezależnie od "świata".
> 
> Ale ja podałem argumenty dlaczego są złe, a nie "bo są złe".
> Natomiast można założyć, że w świecie o którym mówisz, ze względu
> na niewielkie rozproszenie i małą skalę są to wady nieistotne.

Ok. Moim zdaniem w pewnych przypadkach w Twoim świecie są to wady.
A nie, że wady ogólnie.

>> W aplikacjach webowych, a ściślej: przeglądarkowych, jesteś właściwie
>> skazany na warstwę pośrednią jaką jest np. php w dostępie do bazy
>> danych.
> 
> Ależ wodzu, co wódż? Otwieramy port 3306/5432 i jedziesz.
> 
>> Na drodze: przeglądarka->baza danych, to właśnie php pełni
>> niejako naturalną rolę api dla aplikacji "przeglądarkowej".
>> Nie ma innego sposobu.
> 
> Nie możesz tego zrobić jedynie dlatego że przeglądarki wprowadzają ograniczenia
> w komunikacji, a nie dlatego że to niemożliwe w języku 

Tak. To miałem na myśli.

> (patrz https://github.com/sindresorhus/awesome-nodejs#database ).
> Jakby consensus środowiska był taki, że bezpośrednia praca z DB "to jest to",
> to przeglądarki nie miałyby takich ograniczeń.

Ale mają i nie chciałem drążyć tego tematu, dlatego posłużyłem się 
skrótem myślowym.

>> Przykład podałem w poprzednim poście. Najprostszy z możliwych z
>> aktualizacją pola stanu magazynowego po dodaniu/zmianie/skasowaniu
>> rekordu z towarem.
> 
> I jak myślisz, jak Ci to zadziała na sklepie wielkości Amazona?

A ile jest sklepów wielkości Amazona?

> Dlaczego google używa baz nierelacyjnych do swoich wyszukiwarek (bigtable)
> https://cloud.google.com/bigtable/

Bo takich potrzebuje.

> We wszystkich przypadkach odpowiedź jest taka sama: tradycyjne serwery sql
> "nie wyrabiają" i nie potrafią sprostać potrzebom.

Nie we wszystkich przypadkach.
W większości przypadków tradycyjne serwery sql bez problemu wyrabiają.

> Tam gdzie naprawdę musisz mieć skalowalne rozwiązanie, to właśnie
> tak jest. I nie jedna "maszyna z API". Wrzucę kod na:

Zgada. Tam gdzie naprawdę musisz.

> Tego wszystkiego nie zrealizujesz w tracydyjnym modelu SQL,
> nie dlatego że pojedyncze bajtowe operacje są mniej/bardziej
> wydajne, tylko dlatego że jest to narzędzie o niewielkiej
> skalowalności.

Ale przecież to nie jest tak, że teraz wszyscy nagle powinni porzucić 
triggery/sp, bo stały się złe, bo Amazon i google z nich nie korzysta.

Borys Pogoreło już o tym wspomniał. Wdrażanie na siłę takich rozwiązań, 
tam gdzie nie są konieczne, to jest rozwiązywanie problemów, których 
większość nie ma i nigdy mieć nie będzie. Za to rodzą inne problemy, 
które można w prosty sposób załatwić triggerem czy za pomocą sp.

Pozdrawiam
Piotr