🚀 go-pugleaf

W dniu 25.04.2019 o 21:26, Wojciech Bancer pisze:
> On 2019-04-24, Kviat <Kviat> wrote:
> 
> [...]
> 
>> Błędne założenie, że nie istnieją aplikacje końcowe z dostępem do bazy,
> 
> Ciachnąłem, bo dyskutujemy o dwóch różnych światach.

Myślałem, że dyskutujemy o triggerach/sp.

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

> W końcu jesteśmy na grupie PHP. To co opisałeś to właśnie
> cecha systemów których development "ciągnie" się od lat 90-tych i coś
> co ja nazwałem legacy (bo ten model architektury powstał zanim internet
> stał się tym czym się stał).

I nie dość, że się będzie ciągnął jeszcze długo, to jeszcze przez długi 
czas będą powstawać nowe aplikacje.

Nazwałeś to legacy, bo akurat siedzisz tam gdzie siedzisz.
To, że zajmujesz się akurat taką, a nie inną działką, nie czyni działek 
którymi się nie zajmujesz legacy.

> W systemach webowych (including PHP) zastąpione przez tworzenie aplikacji
> nadrzędnej/API, a nie przez radosne udostępnianie portu 3306 całemu
> światu i myślałem że to oczywiste że rozmawiamy współczesnych systemach
> webowych.

Systemy webowe, to nie tylko html i js w przeglądarce + php.

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

Aplikacja desktopowa też może być jak najbardziej aplikacją webową. Może 
się łączyć z bazą, jak wyżej wspomniałeś np. z MySql, bezpośrednio, 
przez VPN, albo... przez soap czy rest czy jakiekolwiek inne api 
(realizowane przez php czy cokolwiek innego, to rzecz wtórna).

To czy komunikacja leci przez internet czy po kablach w sieci lokalnej, 
to z programistycznego punktu widzenia nie ma kompletnie znaczenia.
To czy button "zapisz", "edytuj", "usuń" wyświetla się na canvasie 
przeglądarki, czy na formatce aplikacji desktopowej też nie ma znaczenia.

I oczywiście masz dużo racji, że w sieci publicznej jakim jest internet 
otwieranie portu bazy danych na świat jest co najmniej dyskusyjne, o 
tyle w sieci wewnętrznej ma dużo mniejsze znaczenie, albo nie ma żadnego.

Te wszystkie dywagacje, czy z api czy bez api, czy przez internet czy 
nie przez internet, czy to php czy tcl (btw. w tcl jeszcze parę lat 
temu, całkiem niedawno, był robiony portal polska.pl), nie mają nic 
wspólnego z tym, czy triggery/sp są użyteczne (potrzebne) czy nie są. A 
już tym bardziej czy są dobre czy złe.

> Jak masz merytoryczne argumenty dlaczego we współczesnym systemie webowym
> trigger byłby lepszy w użyciu od API, to chętnie posłucham,

Przykład podałem w poprzednim poście. Najprostszy z możliwych z 
aktualizacją pola stanu magazynowego po dodaniu/zmianie/skasowaniu 
rekordu z towarem.
Nie twierdzę że zawsze i wszędzie jest lepszy. Twierdzę, że są takie 
sytuacje, że jest lepszy. Silnik bazy danych zrobi to szybciej i pewniej 
niż najbardziej wypasione api.
Szczerze mówiąc, kompletnie nie rozumiem idei implementowania takiej 
operacji w api, skoro sam silnik bazy danych to może zrobić (o 
implementowaniu tego w aplikacji klienckiej w ogóle nie wspominam).

Możliwe, że gdzie indziej stawiamy granicę pomiędzy logiką biznesową 
operacji na danych, a samymi danymi.
W ten sposób można dojść do wniosku, że niepotrzebnie bazie danych zleca 
się pilnowanie relacji między tabelami i niepotrzebne są pola primary 
key i foreign key, czy on delete cascade itd, bo przecież to samo może 
robić api...
Tylko po co w takim razie implementują te bajery w kombajnach 
bazodanowych i bez sensu tymi nikomu niepotrzebnymi, wręcz złymi 
rzeczami jakimi są triggery/sp, zaśmiecają maszyny, zamiast dać proste 
składowisko danych, a o resztę niech się martwi maszyna z api...

Ciekawe, że nikt z producentów silników bazodanowych nie wpadł na to, że 
skoro dla "systemów webowych" możliwość tworzenia triggerów/sp to 
kompletnie niepotrzebny bajer, nie zrobili dla nich jakichś okrojonych 
wersji, skoro to taki gigantyczny rynek i w nowoczesnym świecie i tak 
tego nikt nie używa?

> ale dyskusja
> o "desktopach" to jak dyskusja o rowerach na grupie samochodowej. Nie
> ten świat.

Tak samo jak dyskusja o aplikacji webowej, gdy dyskusja dotyczy 
triggerów w bazie, a nie aplikacji.

Pozdrawiam
Piotr