Symfony 4 - jak projektować bazę danych pod Doctrine?

[Marek S]

Witam,

Bardzo niewygodnie tworzy się struktury bazodanowe używając make:entity
i potem zastanawiając się czy np. pole "string" stanie się varchar czy
text itd.

Najczytelniej jest zaprojektować bazę w SQL, wraz z własnymi typami,
procedurami w PlPgSQL, triggerami, przeróżnymi constrainami. Potem
przetestowanie gdzieś na boku struktur i dopiero wtedy można pomyśleć o
przenoszeniu danych do ORM.

Czy jest jakaś możliwość aby ORM zbudował się na podstawie albo pliku
SQL, albo na postawie tego, co jest w bazie?

--
Pozdrawiam,
Marek

[Wojciech Bancer]

On 2019-04-20, Marek S <pr...@spamowi.com> wrote:

[...]

> Bardzo niewygodnie tworzy się struktury bazodanowe używając make:entity
> i potem zastanawiając się czy np. pole "string" stanie się varchar czy
> text itd.

To może warto przeczytać instrukcję, skoro to dla Ciebie aż takie istotne?
Już nawet nie cały, ale podstawy by wypadało.

> Najczytelniej jest zaprojektować bazę w SQL, wraz z własnymi typami,
> procedurami w PlPgSQL, triggerami, przeróżnymi constrainami. Potem
> przetestowanie gdzieś na boku struktur i dopiero wtedy można pomyśleć o
> przenoszeniu danych do ORM.

Myślę, że żaden ORM nie obsłuży triggerów. A do tego mają swoje constraints,
których nie uświadczysz na surowej bazie (jak np. obsługa tablic wartości, czyli
np. typ simple_array albo array).

Triggery nie są one uniwersalne, więc żaden ORM nie będzie ich raczej obsługiwać.

> Czy jest jakaś możliwość aby ORM zbudował się na podstawie albo pliku
> SQL, albo na postawie tego, co jest w bazie?

A zadałeś te pytanie w google, zanim napisałeś na grupę?
Bo na hasło "doctrine import db" masz odpowiedź w 1 linku.

--
Wojciech Bańcer
wojciec...@gmail.com

[Marek S]

W dniu 2019-04-21 o 14:25, Wojciech Bancer pisze:

>> Bardzo niewygodnie tworzy się struktury bazodanowe używając make:entity
>> i potem zastanawiając się czy np. pole "string" stanie się varchar czy
>> text itd.
>
> To może warto przeczytać instrukcję, skoro to dla Ciebie aż takie istotne?
> Już nawet nie cały, ale podstawy by wypadało.

Faktem jest, że gdy już wszystko zawiedzie, należy przeczytać instrukcję :-D

> Myślę, że żaden ORM nie obsłuży triggerów. A do tego mają swoje constraints,
> których nie uświadczysz na surowej bazie (jak np. obsługa tablic wartości, czyli
> np. typ simple_array albo array).

A teraz na poważnie: napisałeś wcześniej, że należałoby przeczytać
instrukcję, a teraz piszesz, że i tak by mi to nic nie dało gdyż
funkcjonalność, o którą pytam nie jest wspierana przez ORMy.

Cenię Twoją wiedzę, ale nauczyciel z Ciebie kiepski ;-) Ale cóż,
przecierpię :-D

> Triggery nie są one uniwersalne, więc żaden ORM nie będzie ich raczej obsługiwać.

Jak zatem w praktyce takie rzeczy się robi? Oczywiście mógłbym ręcznie
dopisywać coś do migracji lecz jest w tym pewnego rodzaju zagrożenie:
otóż w fazie DEV, szczególnie gdy stawia się pierwsze kroki w tematyce,
łatwo o błędy. Zdarzało mi się automatycznie tworzyć migracje, usuwać je
po wycofaniu, poprawić coś tam i jeszcze raz generować. Gdybym ręcznie w
nich grzebał, to utraciłbym dodatkowe zmiany.

Jak zatem od strony praktycznej dołączasz nie-ORMowe wstawki? Tworzysz
oddzielne, ręczne migracje?

>> Czy jest jakaś możliwość aby ORM zbudował się na podstawie albo pliku
>> SQL, albo na postawie tego, co jest w bazie?
>
> A zadałeś te pytanie w google, zanim napisałeś na grupę?
> Bo na hasło "doctrine import db" masz odpowiedź w 1 linku.

Mądralo, gdybym wiedział o co pytać by w poprawnym kierunku podążać, to
nie zadawałbym tu pytań.

Odpowiadając: owszem, szukałem w Google... ale narzędzi do tego (czyli
export to doctrine, convert to doctrine). I tak np. analizowałem Navicat
pod kątem tego, czy potrafi wygenerować coś dla ORMów. Nie pomyślałem,
że sam ORM takie rzeczy potrafi sam z siebie robić, ma wbudowane
importowanie. A dlaczego nie pomyślałem? Wyjaśniam poniżej.

Lokalnie też podpytywałem kolegów, którzy mieli z jakimikolwiek
frameworkami do czynienia. Wszyscy niestety, jak rzemieślnicy przy
taśmie fabrycznej, tworzyli encje poprzez frameworki, nigdy odwrotnie.
Jeden z nich nawet sądzi, że klucze obce tworzy się za pomocą Join'ów.
Stąd podświadomie założyłem, że ORM to jednokierunkowy mechanizm w
zakresie tworzenia struktur w bazach.

Uwaga do Ciebie: bierz pod uwagę, że osoby wdrażające się w jakikolwiek
temat potrafią błądzić i rozpatrywać nawet absurdalne sposoby realizacji
jakiegoś zadania. A już w szczególności, gdy lokalne środowisko
zaciemnia właściwe podejście. Także trochę przyhamuj z łaski swojej z
takimi pytaniami.

--
Pozdrawiam,
Marek

[Wojciech Bancer]

On 2019-04-21, Marek S <pr...@spamowi.com> wrote:

[...]

>> To może warto przeczytać instrukcję, skoro to dla Ciebie aż takie istotne?
>> Już nawet nie cały, ale podstawy by wypadało.
>
> Faktem jest, że gdy już wszystko zawiedzie, należy przeczytać instrukcję :-D
>
>> Myślę, że żaden ORM nie obsłuży triggerów. A do tego mają swoje constraints,
>> których nie uświadczysz na surowej bazie (jak np. obsługa tablic wartości, czyli
>> np. typ simple_array albo array).
>
> A teraz na poważnie: napisałeś wcześniej, że należałoby przeczytać
> instrukcję, a teraz piszesz, że i tak by mi to nic nie dało gdyż
> funkcjonalność, o którą pytam nie jest wspierana przez ORMy.

Tak poważnie, to pisze w pierwszym zdaniu tejże. Nie musiałbyś więc
potem szukać. triggery i inne rzeczy (np. stored procedures), to raczej
relikt czasów minionych, a przynajmniej ja już od dawna nie widziałem
ich w użyciu poza systemami legacy (a w kilku dużych korpo pracuję).
ORMy są nastawione na bycie kompatybilne z wieloma silnikami, w związku
z czym ograniczają się do obsługi funkcjonalności niejako "wspólnej".

I w tym momencie trzeba sobie zadać pytanie "ok, ale co w zamian
do rozwiązania problemu". I znowu odpowiedź jest, w... instrukcji!

Doctrine "w zamian" pozwala na dodawanie eventów:
https://www.doctrine-project.org/projects/doctrine-orm/en/2.6/reference/events.html

> Cenię Twoją wiedzę, ale nauczyciel z Ciebie kiepski ;-) Ale cóż,
> przecierpię :-D

Nie aspiruję.

>> Triggery nie są one uniwersalne, więc żaden ORM nie będzie ich raczej obsługiwać.
>
> Jak zatem w praktyce takie rzeczy się robi? Oczywiście mógłbym ręcznie
> dopisywać coś do migracji lecz jest w tym pewnego rodzaju zagrożenie:
> otóż w fazie DEV, szczególnie gdy stawia się pierwsze kroki w tematyce,
> łatwo o błędy. Zdarzało mi się automatycznie tworzyć migracje, usuwać je
> po wycofaniu, poprawić coś tam i jeszcze raz generować. Gdybym ręcznie w
> nich grzebał, to utraciłbym dodatkowe zmiany.

Ale do instrukcji nie zajrzałeś, bo po co? :)

> Jak zatem od strony praktycznej dołączasz nie-ORMowe wstawki? Tworzysz
> oddzielne, ręczne migracje?

Nie dołączam.

>> A zadałeś te pytanie w google, zanim napisałeś na grupę?
>> Bo na hasło "doctrine import db" masz odpowiedź w 1 linku.
>
> Mądralo, gdybym wiedział o co pytać by w poprawnym kierunku podążać, to
> nie zadawałbym tu pytań.

Sztuka bycia programistą, to również sztuka zadawania odpowiednich
pytań w google. Albo przeszukiwania stack overflow.

> Odpowiadając: owszem, szukałem w Google... ale narzędzi do tego (czyli
> export to doctrine,

Zwraca właściwy wynik na 6 pozycji:
"How to Generate Entities from an Existing Database (Symfony Docs)"

> convert to doctrine).

Zwraca właściwy wynik na 3 pozycji:
"How to Generate Entities from an Existing Database (Symfony Docs)"

> Lokalnie też podpytywałem kolegów, którzy mieli z jakimikolwiek
> frameworkami do czynienia. Wszyscy niestety, jak rzemieślnicy przy
> taśmie fabrycznej, tworzyli encje poprzez frameworki, nigdy odwrotnie.

Bo to jest praktyczniejsze.

[...]

> Uwaga do Ciebie: bierz pod uwagę, że osoby wdrażające się w jakikolwiek
> temat potrafią błądzić i rozpatrywać nawet absurdalne sposoby realizacji
> jakiegoś zadania. A już w szczególności, gdy lokalne środowisko
> zaciemnia właściwe podejście. Także trochę przyhamuj z łaski swojej z
> takimi pytaniami.

Jakimi? Czy sprawdzałeś w google? Pytasz o tak absolutne podstawy,
że odpowiedzi naprawdę nie jest trudno się doszukać.

--
Wojciech Bańcer
wojciec...@gmail.com

[Marek S]

W dniu 2019-04-21 o 19:49, Wojciech Bancer pisze:

>> A teraz na poważnie: napisałeś wcześniej, że należałoby przeczytać
>> instrukcję, a teraz piszesz, że i tak by mi to nic nie dało gdyż
>> funkcjonalność, o którą pytam nie jest wspierana przez ORMy.
>
> Tak poważnie, to pisze w pierwszym zdaniu tejże. Nie musiałbyś więc
> potem szukać. triggery i inne rzeczy (np. stored procedures), to raczej
> relikt czasów minionych, a przynajmniej ja już od dawna nie widziałem
> ich w użyciu poza systemami legacy (a w kilku dużych korpo pracuję).
> ORMy są nastawione na bycie kompatybilne z wieloma silnikami, w związku
> z czym ograniczają się do obsługi funkcjonalności niejako "wspólnej".

Ja z kolei w jednej korpo pracuję, która w swoim statusie trudni się
wykupywaniem innych, upadających korpo z określonej gałęzi rynku na
całym świecie i których systemy informatyczne trzeba w związku z tym
integrować z naszymi. I tak jak patrzę na ich systemy, to wcale nie jest
rzadkością budowanie baz z triggerami. Również patrząc na nowe
rozwiązania wdrażane przez naszych jak i programistów z USA, to nie
przypominam sobie bazy baz powyższych rozwiązań.

No dobrze, to rys historyczny mamy za nami. Teraz do rzeczy.

> I w tym momencie trzeba sobie zadać pytanie "ok, ale co w zamian
> do rozwiązania problemu". I znowu odpowiedź jest, w... instrukcji!

Być może. Jeśli szukałem triggerów i nie znalazłem bo ich tam nie ma
(jak sam wspomniałeś), to czy ze szklanej kuli mam wywróżyć co jest w
zamian? Teraz nawiązuje do Twojego ganiącego tonu wypowiedzi. Spróbuj
złożyć 2 zdania bez tego. Wierzę w Ciebie, że dasz radę. ;-)

Jeśli jednak nie, trudno. Będę musiał się przyzwyczaić do łajania :-D

> Doctrine "w zamian" pozwala na dodawanie eventów:
> https://www.doctrine-project.org/projects/doctrine-orm/en/2.6/reference/events.html

Hmmm.. no niby to mogłoby zastąpić je. Czytałem ten rozdział, ale nie
pomyślałem by stosować je w roli odpowiedników triggerów. Na kursie
wspominano o zupełnie innym przeznaczeniu zdarzeń.

Obawiam się, że takie ORMowe podróby zarżną wydolność systemu. Zdarza
się iż czasem muszę zaimportować pół miliona rozbudowanych rekordów, co
czasem zajmuje 3h pracy systemu. ORMowy trigger może drastycznie
wydłużyć procedurę. Oczywiście nie wiem - dywaguję.

>> Lokalnie też podpytywałem kolegów, którzy mieli z jakimikolwiek
>> frameworkami do czynienia. Wszyscy niestety, jak rzemieślnicy przy
>> taśmie fabrycznej, tworzyli encje poprzez frameworki, nigdy odwrotnie.
>
> Bo to jest praktyczniejsze.

Zgodzę się. Wydajność tego, co się robi, jakiś indeksy na wyszukiwanych
polach... któż takimi pierdołami by się przejmował.

https://www.rmf24.pl/fakty/polska/news-trojmiasto-awaria-systemu-wypozyczalni-rowerow-mevo,nId,2912676

Użytkownik w okolicach 60000 zakończył działanie systemu. Zapewne Janusz
frameworków założył 2-bajtowy klucz w bazie lub inne cudo wykonał :-D


--
Pozdrawiam,
Marek

[Wojciech Bancer]

On 2019-04-22, Marek S <pr...@spamowi.com> wrote:

[...]

>> I w tym momencie trzeba sobie zadać pytanie "ok, ale co w zamian
>> do rozwiązania problemu". I znowu odpowiedź jest, w... instrukcji!
>
> Być może. Jeśli szukałem triggerów i nie znalazłem bo ich tam nie ma
> (jak sam wspomniałeś), to czy ze szklanej kuli mam wywróżyć co jest w
> zamian? Teraz nawiązuje do Twojego ganiącego tonu wypowiedzi. Spróbuj
> złożyć 2 zdania bez tego. Wierzę w Ciebie, że dasz radę. ;-)

google: "doctrine triggers" [click].
Pierwszy link: How to handle SQL triggers in Symfony2? - Stack Overflow
https://stackoverflow.com/questions/18377690/how-to-handle-sql-triggers-in-symfony2
I pierwsza odpowiedź stanowi odpowiedź na Twoje pytanie.

[...]

> Obawiam się, że takie ORMowe podróby zarżną wydolność systemu.
> Zdarza się iż czasem muszę zaimportować pół miliona rozbudowanych
> rekordów, co czasem zajmuje 3h pracy systemu. ORMowy trigger może
> drastycznie wydłużyć procedurę. Oczywiście nie wiem - dywaguję.

https://www.doctrine-project.org/projects/doctrine-orm/en/2.6/reference/batch-processing.html

>>> Lokalnie też podpytywałem kolegów, którzy mieli z jakimikolwiek
>>> frameworkami do czynienia. Wszyscy niestety, jak rzemieślnicy przy
>>> taśmie fabrycznej, tworzyli encje poprzez frameworki, nigdy odwrotnie.
>>
>> Bo to jest praktyczniejsze.
>
> Zgodzę się. Wydajność tego, co się robi, jakiś indeksy na wyszukiwanych
> polach... któż takimi pierdołami by się przejmował.

Indeksy można nakładać poprzez anotacje.
To co opisujesz, to jest typowy PEBKAC.

> https://www.rmf24.pl/fakty/polska/news-trojmiasto-awaria-systemu-wypozyczalni-rowerow-mevo,nId,2912676

A tu serwisy oparte o Symfony2:
https://stfalcon.com/en/blog/post/largest-websites-built-on-symfony2
np. https://www.youtube.com/watch?v=CFQaVDR96x4&feature=youtu.be
Albo jeden ze znanych serwisów porno.

> Użytkownik w okolicach 60000 zakończył działanie systemu. Zapewne Janusz
> frameworków założył 2-bajtowy klucz w bazie lub inne cudo wykonał :-D

Przede wszystkim trzeba zaprojektować dobrą architekturę. W dzisiejszych
czasach kiedy zmiana z php 5.6 na 7.1 podnosi wydajność serwisu bardziej
niż najbardziej wyszukane optymalizacje, należy się skupić na zapewnieniu
dobrej architektury a nie na bajtowych optymalizacjach.

--
Wojciech Bańcer
wojciec...@gmail.com

[Marek S]

W dniu 2019-04-21 o 14:25, Wojciech Bancer pisze:

>> Czy jest jakaś możliwość aby ORM zbudował się na podstawie albo pliku
>> SQL, albo na postawie tego, co jest w bazie?
>
> A zadałeś te pytanie w google, zanim napisałeś na grupę?
> Bo na hasło "doctrine import db" masz odpowiedź w 1 linku.

...i nie działa w przypadku bardziej złożonych struktur niż prosta
tabela bez wyszukanych powiązań.

No więc w Postgresie stworzyłem strukturę, którą od pewnego czasu
stosuję w projektach:

create table if not exists test
(
id bigserial not null
constraint test_pkey
primary key,
aaa varchar(100) not null,
bbb varchar(200) not null
);


create table if not exists test2
(
ccc varchar(150) not null
)
inherits (test);


create table if not exists test3
(
ddd varchar(150) not null
)
inherits (test);

Tak, wiem, że zaraz zadasz pytanie: "a co ta struktura ma robić, bo my
nie wiemy". Asekuracyjnie odpowiem: kosić trawnik.

Próbuję to zaciągnąć zgodnie z tym, co doctrine opisuje, lecz otrzymuje
błąd:


php.exe D:\HTML\Symfony\bin\console doctrine:mapping:import App\Entity
annotation --path=src/Entity

In DatabaseDriver.php line 288:


Table test2 has no primary key. Doctrine does not support reverse
engineering from tables that don't have a primary
key.




doctrine:mapping:import [--em [EM]] [--shard SHARD] [--filter FILTER]
[--force] [--path PATH] [-h|--help] [-q|--quiet] [-v|vv|vvv|--verbose]
[-V|--version] [--ansi] [--no-ansi] [-n|--no-interaction] [-e|--env ENV]
[--no-debug] [--] <command> <name> [<mapping-type>]


Process finished with exit code 1 at 22:51:22.
Execution time: 1,516 ms.

Tak, wiem, że napiszesz iż wprowadzony stosunkowo niedawno do Postgresa
(od 9.3 bodajże) polimorfizm jest legacy. Jednakże chciałbym używać
polimorfizmu bez tworzenia substytutów w postaci:

https://www.doctrine-project.org/projects/doctrine-orm/en/2.6/reference/inheritance-mapping.html

Interesuje mnie zwykły polimorfizm, bez tworzenia dziwacznych układów 2
tabel, które muszę JOINować lub tworzenia Single Table Inheritance,
które w obu przypadkach nie jest żadnym dziedziczeniem lecz odpowiednio
zwykłym JOINowaniem lub budowaniem prostych tabel, zawierających niby
dziedziczone pola.

Jak wymusić importowanie polimorficznych struktur?

Jutro przeprowadzę test z importoiwaniem user-typów, które używam od
lat. Również z uwzględnieniem tych "legacy" - czyli istniejących od
niedawna, w/g Twojej nomenklatury. Powiem tak: nie spodziewam się
niczego pozytywnego. Ale zobaczymy, może się mylę.

--
Pozdrawiam,
Marek

[Wojciech Bancer]

On 2019-04-22, Marek S <pr...@spamowi.com> wrote:

[...]

> Tak, wiem, że napiszesz iż wprowadzony stosunkowo niedawno do Postgresa
> (od 9.3 bodajże) polimorfizm jest legacy. Jednakże chciałbym używać
> polimorfizmu bez tworzenia substytutów w postaci:
>
> https://www.doctrine-project.org/projects/doctrine-orm/en/2.6/reference/inheritance-mapping.html
>
> Interesuje mnie zwykły polimorfizm

[...]

Jeśli Cię nie interesują rozwiązania oferowane przez Doctrine, to nie używaj
Doctrine i pozostań przy pisaniu SQLi.

--
Wojciech Bańcer
wojciec...@gmail.com

[ww]

W dniu 2019-04-21 o 14:25, Wojciech Bancer pisze:

> On 2019-04-20, Marek S <pr...@spamowi.com> wrote:
>
> [...]
>
>> Bardzo niewygodnie tworzy się struktury bazodanowe używając make:entity
>> i potem zastanawiając się czy np. pole "string" stanie się varchar czy
>> text itd.
>
> To może warto przeczytać instrukcję, skoro to dla Ciebie aż takie istotne?
> Już nawet nie cały, ale podstawy by wypadało.
>
>> Najczytelniej jest zaprojektować bazę w SQL, wraz z własnymi typami,
>> procedurami w PlPgSQL, triggerami, przeróżnymi constrainami. Potem
>> przetestowanie gdzieś na boku struktur i dopiero wtedy można pomyśleć o
>> przenoszeniu danych do ORM.
>
> Myślę, że żaden ORM nie obsłuży triggerów.

A w jaki sposób ORM miałby te triggery obsłużyć? Bo ja ich używam do
wielu rzeczy o których ORM kompletnie nie musi wiedzieć.

I doctrine wspiera tworzenie różnych "nieporzenoszalnych"
elementów składni SQL pod dany silnik.

[Wojciech Bancer]

On 2019-04-23, ww <w...@o2.pl> wrote:

[...]

>> Myślę, że żaden ORM nie obsłuży triggerów.
>
> A w jaki sposób ORM miałby te triggery obsłużyć?

No obsługuje alternatywę, poprzez swoje zdarzenia.

Nie wiem w jaki sposób miałby to umożliwiać natywnie (czego chyba wymaga Marek S),
biorąc pod uwagę niesamowity wręcz burdel i brak spójności w triggerach, pomiędzy
różnymi typami baz.

> Bo ja ich używam do wielu rzeczy o których ORM kompletnie nie musi
> wiedzieć.

To jest tak zwana zła praktyka. Potem inny programista siada i "rzeczy dzieją
się magicznie". Zresztą jest to jeden z głównych powodów by nie używać triggerów
(obok tego że to bazy danych są zazwyczaj najmniej skalowalnym i najwęższym
gardłem systemu i nie należy go nadmiernie obciążać).

W świecie w którym możesz mieć "na zawołanie" 1000 funkcji / kontenerów robiących coś
równolegle na infrastrukturze cloud, odpalanych w sekundy, ale np. tylko 1-2 serwery baz
danych, to jest oczywiste że dużo bardziej skalowalne są te ostatnie i należy je odciążyć
maksymalnie, a nie "dokładać" im niepotrzebnej tam roboty.

> I doctrine wspiera tworzenie różnych "nieporzenoszalnych"
> elementów składni SQL pod dany silnik.

Nie tyle "wspiera" co "umożliwia".

Ale koncept za jego rozwojem jednak jest taki, żeby nie dodawać rzeczy
niekompatybilnych będących specyficznymi wyłącznie dla jednego
z obsługiwanych dialektów, chyba że nie ma innego wyjścia (jak mamy
np. w obsłudze primary keys i generation strategy.

--
Wojciech Bańcer
wojciec...@gmail.com

[Marek S]

W dniu 2019-04-23 o 08:26, Wojciech Bancer pisze:

>
> Jeśli Cię nie interesują rozwiązania oferowane przez Doctrine, to nie używaj
> Doctrine i pozostań przy pisaniu SQLi.

Nie o to chodzi. Chciałbym pozostać przy Doctrine bo to jakiś tam
standard. Do tego migracje też są fajnym narzędziem przy przenoszeniu
projektu - nie trzeba prowadzić własnej implementacji podobnych
mechanizmów.

Przy prostych operacjach typu CRUD, nawet 200% narzut tego ORMa jest do
zaakceptowania. I to jest ok. Staram się jedynie przełamać ograniczenia
jakoś. Z pewnością są metody na to.

--
Pozdrawiam,
Marek

[Marek S]

W dniu 2019-04-23 o 15:18, ww pisze:

> A w jaki sposób ORM miałby te triggery obsłużyć? Bo ja ich używam do
> wielu rzeczy o których ORM kompletnie nie musi wiedzieć.
>
> I doctrine wspiera tworzenie różnych "nieporzenoszalnych"
> elementów składni SQL pod dany silnik.

O, właśnie - to mnie najbardziej interesuje. Nie chcę poświęcać
wydajności bazy na rzecz typowego, wygodnego dla programistów,
posługiwania się Doctrine, gdzie co niektórzy nie bardzo wiedzą, co to
SQL (autentycznie). Chciałbym szerzej korzystać z tego środowiska.

W związku z tym mam parę pytań:

1. Czy posługujesz się migracjami do tworzenia nietypowych struktur
poprzez dopisanie do nich własnych SQLi? Czy może porzucasz migracje i
tworzysz bazę "normalnie", w narzędziach do takich rzeczy a potem
jedynie importujesz niektóre tabele do ORM?

2. Co robisz jeśli ORM totalnie nie wspiera jakichś mechanizmów? Np.
pierwszy test, jaki przeprowadziłem, dotyczył tabel polimorficznych w
PostgreSQL. Mega użyteczna rzecz ... ale nie da się ich zaimportować do
ORM'a, który tylko potrafi udawać polimorfizm poprzez "mapowanie"
prostych tabelek. Z drugiej strony chciałbym, aby ORM potrafił
zapisywać/odczytywać do/z takowych. Jak przekładasz to na ograniczone
struktury ORMowe? Masz godne uwagi linki?
P.S.
Powyższy przykład z tabelami byłby do rozwiązania - po prostu ręcznie
napisałbym encję i repozytorium. Ale w przypadku np. własnych typów, czy
korzystania z procedur napisanych w PlPgSQL i nie wiem czego jeszcze -
tak prosto może nie pójść. Jestem jeszcze na początku edukacji, stąd
moje zapewne trywialne pytania.

3. Na koniec... z czystej ciekawości spytam: czy istnieje jakiś natywny
sposób dla ORMa aby usunąć/zaktualizować pole w jakimś rekordzie bez
niepotrzebnie generowanego SELECT'a?

Szukałem po Stack'u lecz wszędzie widziałem jedynie to, że ludzie
posługują się SQLem by wykonać DELETE FROM tabela WHERE id=5. ORM wymaga:

// tu wykonywany jest nadmiarowy select
$user =$entityManager->find('Users', $id);
$entityManager->remove($user);
$entityManager->flush();

Jakoś nie chce mi się wierzyć aby ORM nie potrafił zwyczajnie usunąć
rekordu z bazy i w tym celu generował nadmiarowe zapytania. Przekopałem
dokumentację Doctrine i nie znalazłem odpowiedzi.


Jeśli masz jakieś sugestie, nawet nie powiązane z powyższym, a z którymi
walczyłeś z naginaniem ORM'a - to będę wdzięczny za info.

--
Pozdrawiam,
Marek

[Wojciech Bancer]

On 2019-04-23, Marek S <pr...@spamowi.com> wrote:

[...]

>> Jeśli Cię nie interesują rozwiązania oferowane przez Doctrine, to nie używaj
>> Doctrine i pozostań przy pisaniu SQLi.
>
> Nie o to chodzi. Chciałbym pozostać przy Doctrine bo to jakiś tam
> standard. Do tego migracje też są fajnym narzędziem przy przenoszeniu
> projektu - nie trzeba prowadzić własnej implementacji podobnych
> mechanizmów.

No więc masz dziedziczenie po stronie ORM oraz eventy (też po stronie ORM).

> Przy prostych operacjach typu CRUD, nawet 200% narzut tego ORMa jest do
> zaakceptowania. I to jest ok. Staram się jedynie przełamać ograniczenia
> jakoś. Z pewnością są metody na to.

"Wydajność" bazy to mit zamierzchłych czasów kiedy maszyny to były serwery
dedykowane, stojące w zaciszu firmowych serwerowni. Obecnie można bez problemów
skalować systemy backendowe, podczas gdy skalowanie baz danych jest zazwyczaj
dużo większym problemem (np. trzeba organizować partycjonowanie, czy master-slave,
albo poświęcić czasowo integralność danych).

--
Wojciech Bańcer
wojciec...@gmail.com

[Borys Pogoreło]

Dnia Tue, 23 Apr 2019 19:10:19 +0200, Marek S napisał(a):

> 2. Co robisz jeśli ORM totalnie nie wspiera jakichś mechanizmów? Np.
> pierwszy test, jaki przeprowadziłem, dotyczył tabel polimorficznych w
> PostgreSQL. Mega użyteczna rzecz ... ale nie da się ich zaimportować do
> ORM'a, który tylko potrafi udawać polimorfizm poprzez "mapowanie"
> prostych tabelek. Z drugiej strony chciałbym, aby ORM potrafił
> zapisywać/odczytywać do/z takowych. Jak przekładasz to na ograniczone
> struktury ORMowe? Masz godne uwagi linki?

Zdecyduj się - albo chcesz mieć uniwersalny mechanizm albo narzędzie
dedykowane funkcjom specyficznym dla Postgresa. Znów próbujesz działać na
przekór narzędziu, którego przeznaczeniem jest stworzenie warstwy
abstrakcji mapowanej następnie na struktury poszczególnych silników baz
danych. W efekcie do dyspozycji masz tylko wspólną część, uzupełnioną
logiką zaszytą w PHP.

Jeśli tak potrzebujesz tego polimorfizmu, to znajdź sobie coś do Postgresa,
bo znów będziesz narzekać na ograniczenia, które sam wprowadzasz.

> Jakoś nie chce mi się wierzyć aby ORM nie potrafił zwyczajnie usunąć
> rekordu z bazy i w tym celu generował nadmiarowe zapytania. Przekopałem
> dokumentację Doctrine i nie znalazłem odpowiedzi.

Rozwiń skrót ORM. Z założenia operacje wykonujesz na obiekcie.

Laravel ma dodatkową metodę statyczną Model::destroy($id).

--
Borys Pogoreło
borys(#)leszno,edu,pl

[Marek S]

W dniu 2019-04-23 o 19:21, Wojciech Bancer pisze:

> "Wydajność" bazy to mit zamierzchłych czasów kiedy maszyny to były serwery
> dedykowane, stojące w zaciszu firmowych serwerowni.

Ciekawa teoria. W firmie w jakiej pracuje - cały jeden dział zajmuje się
tylko optymalizacją baz danych jakie im się podrzuca do korekt. Nie
przeczę - może to "legacy" ludzie.

Po drugie, jak wspomniałem przy okazji codziennych importów po pół
miliona rekordów. Jeden mój ruch i prawie dwukrotnie szybciej proces
zaczął działać. A pewnie gdyby przeprojektować system, to i z 10-krotnie
dałoby się przyspieszyć.

--
Pozdrawiam,
Marek

[Marek S]

W dniu 2019-04-23 o 19:51, Borys Pogoreło pisze:

> Zdecyduj się - albo chcesz mieć uniwersalny mechanizm albo narzędzie
> dedykowane funkcjom specyficznym dla Postgresa.

Chcę mieć ORM wspierający specyfikę Postgresa. Inne bazy mnie nie
interesują. Nie zabiegam o kompatybilność z ubogimi krewnymi. Absolutnie
nie to jest moim celem.

> Znów próbujesz działać na
> przekór narzędziu, którego przeznaczeniem jest stworzenie warstwy
> abstrakcji mapowanej następnie na struktury poszczególnych silników baz
> danych. W efekcie do dyspozycji masz tylko wspólną część, uzupełnioną
> logiką zaszytą w PHP.

Tę część zatem pominąć milczeniem możemy.

> Jeśli tak potrzebujesz tego polimorfizmu, to znajdź sobie coś do Postgresa,
> bo znów będziesz narzekać na ograniczenia, które sam wprowadzasz.

Nie rozumiem? Co to jest "coś" do Postgresa? Masz na myśli dedykowany
ORM? Nie da się Doctrine tak oprogramować, by korzystała z ficzerów
Postgresa?

>> Jakoś nie chce mi się wierzyć aby ORM nie potrafił zwyczajnie usunąć
>> rekordu z bazy i w tym celu generował nadmiarowe zapytania. Przekopałem
>> dokumentację Doctrine i nie znalazłem odpowiedzi.
>
> Rozwiń skrót ORM. Z założenia operacje wykonujesz na obiekcie.

A mimo wszystko tenże ORM pozwala na użycie SQL'a w ramach własnych
struktur... Tyle tylko, że samemu trzeba te parę linijek kodu
niepotrzebnie dopisywać.

>
> Laravel ma dodatkową metodę statyczną Model::destroy($id).

No ale my o Doctrine... Z Laravelem już się pożegnałem.

A właśnie, trafne spostrzeżenie! Więc po drugie, skoro Laravel zawiera
taką metodę w swoim ORMie, to czy w świetle Twojej powyższej wypowiedzi
to już nie jest ORM bo potrafi po ID kasować?

--
Pozdrawiam,
Marek

[Wojciech Bancer]

On 2019-04-23, Marek S <pr...@spamowi.com> wrote:

[...]

>> "Wydajność" bazy to mit zamierzchłych czasów kiedy maszyny to były serwery
>> dedykowane, stojące w zaciszu firmowych serwerowni.
>
> Ciekawa teoria. W firmie w jakiej pracuje - cały jeden dział zajmuje się
> tylko optymalizacją baz danych jakie im się podrzuca do korekt. Nie
> przeczę - może to "legacy" ludzie.

Najprawdopodobniej. Albo obsługujący stare aplikacje.
To się zdarza, nie wszystkie aplikacje opłaca się przepisywać.

> Po drugie, jak wspomniałem przy okazji codziennych importów po pół
> miliona rekordów. Jeden mój ruch i prawie dwukrotnie szybciej proces
> zaczął działać. A pewnie gdyby przeprojektować system, to i z 10-krotnie
> dałoby się przyspieszyć.

Myślę że Twoja praca kosztowała więcej niż koszt działania serwera
przez te kilka godzin. No i jak sobie z firmy pójdziesz, to ktoś
będzie musiał rozgryzać "dlaczego magicznie coś się dzieje" na bazie,
skoro w kodzie aplikacji nic nie ma.

--
Wojciech Bańcer
wojciec...@gmail.com

[Borys Pogoreło]

Dnia Tue, 23 Apr 2019 22:10:48 +0200, Marek S napisał(a):

> Chcę mieć ORM wspierający specyfikę Postgresa. Inne bazy mnie nie
> interesują. Nie zabiegam o kompatybilność z ubogimi krewnymi. Absolutnie
> nie to jest moim celem.

To używasz złego narzędzia. Może są jakieś dodatki, które dodają
funkcjonalność stricte postgresową. Google zwraca co najmniej trzy na
pierwszej stronie.

> A właśnie, trafne spostrzeżenie! Więc po drugie, skoro Laravel zawiera
> taką metodę w swoim ORMie, to czy w świetle Twojej powyższej wypowiedzi
> to już nie jest ORM bo potrafi po ID kasować?

Nie, widocznie autorzy zauważyli, że takie coś jest przydatne i dodali. Ale
brak takiej funkcji nie jest błędem.

--
Borys Pogoreło
borys(#)leszno,edu,pl

[Wojciech Bancer]

On 2019-04-23, Marek S <pr...@spamowi.com> wrote:

> W dniu 2019-04-23 o 19:51, Borys Pogoreło pisze:
>
>> Zdecyduj się - albo chcesz mieć uniwersalny mechanizm albo narzędzie
>> dedykowane funkcjom specyficznym dla Postgresa.
>
> Chcę mieć ORM wspierający specyfikę Postgresa. Inne bazy mnie nie
> interesują. Nie zabiegam o kompatybilność z ubogimi krewnymi. Absolutnie
> nie to jest moim celem.

Ale po co Ci ORM w takim razie?
Może chcesz mieć coś w tym stylu:
http://www.pomm-project.org/

>
>> Jeśli tak potrzebujesz tego polimorfizmu, to znajdź sobie coś do Postgresa,
>> bo znów będziesz narzekać na ograniczenia, które sam wprowadzasz.
>
> Nie rozumiem? Co to jest "coś" do Postgresa? Masz na myśli dedykowany
> ORM? Nie da się Doctrine tak oprogramować, by korzystała z ficzerów
> Postgresa?

Dać to się wszystko da, kwestia czasu i środków.
Ale jak dotychczas chyba nie było zapotrzebowania, bo nic tego typu
opensource nie powstało (albo nie zostało wystarczająco rozreklamowane).

Doctrine ma kompatybilność jako cel nadrzędny, więc może jednak ten
ORM nie jest dla Ciebie?

>>> Jakoś nie chce mi się wierzyć aby ORM nie potrafił zwyczajnie usunąć
>>> rekordu z bazy i w tym celu generował nadmiarowe zapytania. Przekopałem
>>> dokumentację Doctrine i nie znalazłem odpowiedzi.
>>
>> Rozwiń skrót ORM. Z założenia operacje wykonujesz na obiekcie.
>
> A mimo wszystko tenże ORM pozwala na użycie SQL'a w ramach własnych
> struktur... Tyle tylko, że samemu trzeba te parę linijek kodu
> niepotrzebnie dopisywać.

No to po co Ci ORM jak chcesz używać SQLa?

>> Laravel ma dodatkową metodę statyczną Model::destroy($id).
> No ale my o Doctrine... Z Laravelem już się pożegnałem.

Da się i w doctrine, z użyciem query buildera.
https://stackoverflow.com/questions/15555042/doctrine-2-delete-with-query-builder (pierwsza odpowiedź)

Można też użyć PartialObject / PartialReference:
https://www.doctrine-project.org/projects/doctrine-orm/en/2.6/reference/partial-objects.html

$reference = $em->getPartialReference('MyApp\Domain\User', 1);

---
Partial references are objects with only the identifiers set as they are passed to the
second argument of the getPartialReference() method. All other fields are null.
---

Działa przy różnego rodzaju joinach, czy update, może zadziałać i tu.

--
Wojciech Bańcer
wojciec...@gmail.com

[ww]

W dniu 2019-04-23 o 17:13, Wojciech Bancer pisze:

> On 2019-04-23, ww <w...@o2.pl> wrote:
>
> [...]
>
>>> Myślę, że żaden ORM nie obsłuży triggerów.
>>
>> A w jaki sposób ORM miałby te triggery obsłużyć?
>
> No obsługuje alternatywę, poprzez swoje zdarzenia.
>
> Nie wiem w jaki sposób miałby to umożliwiać natywnie (czego chyba wymaga Marek S),
> biorąc pod uwagę niesamowity wręcz burdel i brak spójności w triggerach, pomiędzy
> różnymi typami baz.
>
>> Bo ja ich używam do wielu rzeczy o których ORM kompletnie nie musi
>> wiedzieć.
>
> To jest tak zwana zła praktyka. Potem inny programista siada i "rzeczy dzieją
> się magicznie". Zresztą jest to jeden z głównych powodów by nie używać triggerów
> (obok tego że to bazy danych są zazwyczaj najmniej skalowalnym i najwęższym
> gardłem systemu i nie należy go nadmiernie obciążać).

Znam wiele "dobrych praktyk", które niestety w nieidealnej
rzeczywistości nie chcą się sprawdzać. Jeżeli dostajesz tony danych
to niestety czasem trzeba poświecić przejrzystość na rzecz wydajności.

> W świecie w którym możesz mieć "na zawołanie" 1000 funkcji / kontenerów robiących coś
> równolegle na infrastrukturze cloud, odpalanych w sekundy, ale np. tylko 1-2 serwery baz
> danych, to jest oczywiste że dużo bardziej skalowalne są te ostatnie i należy je odciążyć
> maksymalnie, a nie "dokładać" im niepotrzebnej tam roboty.

Niepotrzebnej tam roboty? U mnie triggery i procedury wbudowane robią
zwykle rzeczy, które ze względu na optymalność muszą się odbywać jak
najbliżej bazy, i tam właśnie są najoptymalniejsze.

>> I doctrine wspiera tworzenie różnych "nieporzenoszalnych"
>> elementów składni SQL pod dany silnik.
>
> Nie tyle "wspiera" co "umożliwia".

To dokładnie to samo. Jeśli coś da się zrobić za pomocą wbudowanych
narzędzi to jest to wspierane.

> Ale koncept za jego rozwojem jednak jest taki, żeby nie dodawać rzeczy
> niekompatybilnych będących specyficznymi wyłącznie dla jednego
> z obsługiwanych dialektów, chyba że nie ma innego wyjścia (jak mamy
> np. w obsłudze primary keys i generation strategy.

Koncepty konceptami a życie życiem.

[ww]

W dniu 2019-04-23 o 19:10, Marek S pisze:

> W dniu 2019-04-23 o 15:18, ww pisze:
>

> 3. Na koniec... z czystej ciekawości spytam: czy istnieje jakiś natywny
> sposób dla ORMa aby usunąć/zaktualizować pole w jakimś rekordzie bez
> niepotrzebnie generowanego SELECT'a?
>
> Szukałem po Stack'u lecz wszędzie widziałem jedynie to, że ludzie
> posługują się SQLem by wykonać DELETE FROM tabela WHERE id=5. ORM wymaga:
>
> // tu wykonywany jest nadmiarowy select
> $user =$entityManager->find('Users', $id);
> $entityManager->remove($user);
> $entityManager->flush();

a QueryBuilder nie umożliwia
$em->createQueryBuilder()->delete()->where() lub
$em->createQueryBuilder()->update() ??

[Roman Tyczka]

On Tue, 23 Apr 2019 22:31:12 +0200, Wojciech Bancer wrote:

>> Po drugie, jak wspomniałem przy okazji codziennych importów po pół
>> miliona rekordów. Jeden mój ruch i prawie dwukrotnie szybciej proces
>> zaczął działać. A pewnie gdyby przeprojektować system, to i z 10-krotnie
>> dałoby się przyspieszyć.
>
> Myślę że Twoja praca kosztowała więcej niż koszt działania serwera
> przez te kilka godzin. No i jak sobie z firmy pójdziesz, to ktoś
> będzie musiał rozgryzać "dlaczego magicznie coś się dzieje" na bazie,
> skoro w kodzie aplikacji nic nie ma.

Dziwne to wnioskowanie. Dlaczego treść triggerów i sp nie traktujesz jako
kod źródłowy systemu? Tak samo struktura bazy to kod źródłowy aplikacji.
Niektóre systemy są pisane w kilku językach programowania, każdy ten
fragment jest częścią systemu.
Druga sprawa z tym unikaniem triggerów w celu oszczędzania wydajności to
imho właśnie zabijanie wydajności i spójności. Trigger przy danych wykona
się dzięsiątki razy szybciej niż kod gdzieś w oddali, zwłaszcza
interpretowany. Ja rozumiem, że np. jak sobie rozrzucisz ten kod po 10
serwerach aplikacyjnych to one go wykonają w sumie szybciej, ale wtedy
tracisz fundamentalną cechę bazy czyli ACID, bo wszystko to wykona się w
osobnych transakcjach bez gwarancji niepodzielności i spójności. A jeszcze
co do transakcji to kluczowe jest by transakcje aktualizujące dane były jak
najkrótsze, wykorzystanie triggera skraca ten czas, użycie kodu na zewnątrz
wydłuża, co ciągnie za sobą problemy z blokowaniem zasobów bazy i dalsze
spadki wydajności.
Coś za coś, nie jest tak, że jedno jest lepsze niż drugie i droga bez
triggerów jest słuszna. Być może jest tak jak Marek sugeruje, że na rynku
brakuje fachowców od baz danych i się to załatwia ORMami, nie rozumiejąc co
się w zamian traci.

--
pozdrawiam
Roman Tyczka

[Wojciech Bancer]

On 2019-04-24, Roman Tyczka <noe...@because.no> wrote:

[...]

>> Myślę że Twoja praca kosztowała więcej niż koszt działania serwera
>> przez te kilka godzin. No i jak sobie z firmy pójdziesz, to ktoś
>> będzie musiał rozgryzać "dlaczego magicznie coś się dzieje" na bazie,
>> skoro w kodzie aplikacji nic nie ma.
>
> Dziwne to wnioskowanie. Dlaczego treść triggerów i sp nie traktujesz jako
> kod źródłowy systemu? Tak samo struktura bazy to kod źródłowy aplikacji.
> Niektóre systemy są pisane w kilku językach programowania, każdy ten
> fragment jest częścią systemu.

Jak zapiszesz trigger do git?
Jak zapewnisz bezkonfliktową pracę *zespołu* (nie jednej osobie) na takim
zestawie, rozwiążesz konflikty? Triggery to relikt zamierzchłych czasów
"one-man-army" programistów.

> Druga sprawa z tym unikaniem triggerów w celu oszczędzania wydajności to
> imho właśnie zabijanie wydajności i spójności. Trigger przy danych wykona
> się dzięsiątki razy szybciej niż kod gdzieś w oddali,

Idąc takim tokiem to należy pisać tylko w assemblerze, wszystko
inne jest dziesiątki razy wolniejsze.

> zwłaszcza interpretowany. Ja rozumiem, że np. jak sobie rozrzucisz ten kod po 10
> serwerach aplikacyjnych to one go wykonają w sumie szybciej, ale wtedy
> tracisz fundamentalną cechę bazy czyli ACID, bo wszystko to wykona się w
> osobnych transakcjach bez gwarancji niepodzielności i spójności.

Nic się nie traci.

> A jeszcze co do transakcji to kluczowe jest by transakcje aktualizujące dane
> były jak najkrótsze, wykorzystanie triggera skraca ten czas, użycie kodu
> na zewnątrz wydłuża, co ciągnie za sobą problemy z blokowaniem zasobów bazy
> i dalsze spadki wydajności.

To jest koncept postrzegania wydajności "w górę". Takie podejście ma tą wadę,
że jest *skończone*, tzn. w końcu napotyka się na gardło pod tytułem "hardware
więcej nie da". Wystarczy liniowy skok i brak zasobów gotowy.

> Coś za coś, nie jest tak, że jedno jest lepsze niż drugie i droga bez
> triggerów jest słuszna.

Pewne rozwiązania z czasem stają się tzw. anti-patternami.
Przykłady to goto, wzorce singletona. Wkładanie logiki biznesowej
do triggerów też jest pewnego rodzaju anty-wzorcem. Jakby czysta
wydajność była tak kluczowa, to pisalibyśmy wszystko w asemblerze
albo gołym C. Procedury, triggery itp. są koszmarkiem do zarzącania
w porównaniu do alternatyw, a oferują dużo biedniejsze możliwości.
Profit w postaci szybkości nie jest tu wystarczającym argumentem.

> Być może jest tak jak Marek sugeruje, że na rynku
> brakuje fachowców od baz danych i się to załatwia ORMami, nie rozumiejąc co
> się w zamian traci.

W dobie rozwiązan cloudowych patrzy się raczej jak coś skalować "w bok" a nie
tylko przez podniesienie mocy maszyny i mikrooptymalizacje. I tak, przez to
kod pojedynczej aplikacji wykonuje się może te 10x wolniej, ale jesteś w stanie
tego wykonać o rzędy wielkości więcej niż przy skalowaniu w górę. I jesteś
w stanie reagować na zmiany przez skalowanie ifnrastruktury w miarę wzrostu
obciążenia.

Utrzymywanie kodu na jednym serwerze jest zaprzeczeniem tej idei, a (co już podnosiłem)
bazy danych to sa zazwyczaj najmniej skalowalne elementy infrastuktury. I myślenie
architektów idzie w kierunku zapewnienia możliwej równoległości przeliczeń (co
też sprawdza się w ML), a nie w kierunku optymalizacji bajtowych,
czy oferowanych przez języki programowania.

--
Wojciech Bańcer
wojciec...@gmail.com

[Wojciech Bancer]

On 2019-04-24, ww <w...@o2.pl> wrote:

[...]

>> To jest tak zwana zła praktyka. Potem inny programista siada i "rzeczy dzieją
>> się magicznie". Zresztą jest to jeden z głównych powodów by nie używać triggerów
>> (obok tego że to bazy danych są zazwyczaj najmniej skalowalnym i najwęższym
>> gardłem systemu i nie należy go nadmiernie obciążać).
>
> Znam wiele "dobrych praktyk", które niestety w nieidealnej
> rzeczywistości nie chcą się sprawdzać. Jeżeli dostajesz tony danych
> to niestety czasem trzeba poświecić przejrzystość na rzecz wydajności.

Problem w tym, że niektórzy uznają pojęcie "wydajność" za bardzo jednotorowe.

>> W świecie w którym możesz mieć "na zawołanie" 1000 funkcji / kontenerów robiących coś
>> równolegle na infrastrukturze cloud, odpalanych w sekundy, ale np. tylko 1-2 serwery baz
>> danych, to jest oczywiste że dużo bardziej skalowalne są te ostatnie i należy je odciążyć
>> maksymalnie, a nie "dokładać" im niepotrzebnej tam roboty.
>
> Niepotrzebnej tam roboty? U mnie triggery i procedury wbudowane robią
> zwykle rzeczy, które ze względu na optymalność muszą się odbywać jak
> najbliżej bazy, i tam właśnie są najoptymalniejsze.

Podałem swoje argumenty dlaczego tak uważam i dlaczego uważam triggery
za mniej wydajne. Nie mam ochoty się powtarzać. Bazy danych są najbardziej
obciążonym kawałkiem w typowych aplikacjach i nie należy ich dociążać.

Triggery są też złe pod tym kątem, że operują na przestrzeni globalnej,
i (przy mniej ogarniętych w DBA programistach) jest ciężko nad nimi
zapanować, nie zapewniają mechanizmów ułatwiających ich kontrolę,
wersjonowania, nie pozwalają na efektywną pracę w zespole.
Ogólnie mają bardzo dużo wad i niewiele zalet.

Jakby taka niskopoziomowa wydajność miała tak duże znaczenie,
to nie pisałbyś w PHP, czy node.js tylko w C.

Poza tym teoria że "trigger" jest 10-krotnie wydajniejszy wydaje mi się
cokolwiek mocno naciągana. Przepraszam wydajniejszy w czym? Zapytania
SQL wytworzone przez trigger zajmują tyle samo czasu co wysłane przez
aplikację, różnica wynika co najwyżej z czasu dostępów do usługi (co
nie jest chyba specjalnie istotne).

Tak, narzut uruchamiania aplikacji jest czymś co się odbija
na wydajności, ale tą aplikację i tak uruchamiamy, jak chcemy
uruchomić query.

Narzut obiektowości w aplikacji wprowadza pewną karę wydajności,
ale jest on dołożony z konkretnych powodów, których nie spełnia
wykorzystanie triggera (ani nie spełnia pisanie aplikacji
w asemblerze, czy w czystym C).

A że trigger jakoś istotnie szybciej przeiteruje po tablicy
w pamięci niż aplikacja, to wybacz nie wierzę. Język interpretowany
nie ma dostępu do pamięci "gorszego sortu" tylko tej samej,
chyba że serwer DB stoi na innej infrastrukturze.

>>> I doctrine wspiera tworzenie różnych "nieporzenoszalnych"
>>> elementów składni SQL pod dany silnik.
>>
>> Nie tyle "wspiera" co "umożliwia".
>
> To dokładnie to samo. Jeśli coś da się zrobić za pomocą wbudowanych
> narzędzi to jest to wspierane.

Nie to miałem na myśli. Wspierane = idzie zgodnie z ideą za jaką idzie
doctrine. Jak zaczniesz stosować swoje hacki, to skończysz na tym, że
np. inne biblioteki/pluginy zależne od Doctrine, które może zechcesz
użyć mogą się wysypać, bo nie zachowałeś zawartego w Doctrine
kontraktu. No i w razie problemów na linii core <-> Twoja modyfikacja
jesteś zdany na siebie.

--
Wojciech Bańcer
wojciec...@gmail.com

[Kviat]

W dniu 24.04.2019 o 15:13, Wojciech Bancer pisze:

> On 2019-04-24, ww <w...@o2.pl> wrote:
>
>>
>> Niepotrzebnej tam roboty? U mnie triggery i procedury wbudowane robią
>> zwykle rzeczy, które ze względu na optymalność muszą się odbywać jak
>> najbliżej bazy, i tam właśnie są najoptymalniejsze.
>
> Podałem swoje argumenty dlaczego tak uważam i dlaczego uważam triggery
> za mniej wydajne. Nie mam ochoty się powtarzać. Bazy danych są najbardziej
> obciążonym kawałkiem w typowych aplikacjach i nie należy ich dociążać.

Triggery i procedury wbudowane nie służą tylko i wyłącznie do celów
optymalizacyjnych.

> Triggery są też złe pod tym kątem, że operują na przestrzeni globalnej,
> i (przy mniej ogarniętych w DBA programistach) jest ciężko nad nimi
> zapanować, nie zapewniają mechanizmów ułatwiających ich kontrolę,
> wersjonowania, nie pozwalają na efektywną pracę w zespole.
> Ogólnie mają bardzo dużo wad i niewiele zalet.

Nie widzę przeszkód w wersjonowaniu kodu procedury składowanej..
Co do pracy w zespole, to przecież osoba pisząca aplikację łączącą się z
bazą (korzystająca z danych składowanych w bazie) niekoniecznie musi
wiedzieć, co dana procedura/trigger robi "w środku". Interesują go
wyniki jakie otrzymuje z bazy.

> A że trigger jakoś istotnie szybciej przeiteruje po tablicy
> w pamięci niż aplikacja, to wybacz nie wierzę. Język interpretowany
> nie ma dostępu do pamięci "gorszego sortu" tylko tej samej,
> chyba że serwer DB stoi na innej infrastrukturze.

I wtedy aby przeiterować trzeba z bazy wypchnąć do klienta wszystkie
rekordy, które mają być przeiterowane, łącznie z rekordami zależnymi,
żeby otrzymać wynik.
Tutaj to kwestia kompromisu, czy do stu klientów wypchnąć po
kablach/radiu po np. 5GB żeby sobie przeiterowali lokalnie, czy
przeiterować 100 razy w bazie i w sieć puścić tylko wynik.
A nawet przeiterować w bazie raz, zapisać wynik w tabeli tymczasowej i
pchać sto razy wynik po jednej iteracji.

Również chodzi o zapewnienie integralności, spójności danych wewnątrz
samej bazy, a nie tylko o szybkie iteracje.

Jeżeli z bazą łączą się różne aplikacje (np. Księgowość, Magazyn,
Sprzedaż itp.), to łatwiej (i bezpieczniej) jest ogarnąć zależności np.
między dokumentami w bazie, niż w poszczególnych aplikacjach. Im więcej
różnych aplikacji/modułów tym większa szansa, że w którejś z nich będzie
błąd i spowoduje rozsypanie zależności.
Dodatkowo, jeżeli potrzebna jest jakaś zmiana, to zmianę wykonujesz w
jednym miejscu, w bazie, a nie we wszystkich aplikacjach klienckich.
Jeżeli integralność danych pilnowana jest w serwerze danych, to błąd w
aplikacji np. Magazyn nie spowoduje, że wszystkie inne nagle zaczną
pokazywać błędne dane.
Tego typu aplikacji nie pisze "wszystko w jednym" (bo po co
magazynierowi cały kombajn z księgowością?). A nawet udostępnia się
możliwość pisania dodatków przez firmy trzecie (oczywiście dając jakąś
warstwę pośrednią, api).
To tak w skrócie i na szybko, że jednak triggery i procedury składowane
czasem się przydają.

Pozdrawiam
Piotr

[Marek S]

W dniu 2019-04-23 o 22:38, Borys Pogoreło pisze:

>
> To używasz złego narzędzia. Może są jakieś dodatki, które dodają
> funkcjonalność stricte postgresową. Google zwraca co najmniej trzy na
> pierwszej stronie.

Pewnie, że są. Jednakże pisałeś, że używam złego narzędzia (Doctrine)
więc po co mi one skoro sugerujesz bym się pozbył tegoż?

>> A właśnie, trafne spostrzeżenie! Więc po drugie, skoro Laravel zawiera
>> taką metodę w swoim ORMie, to czy w świetle Twojej powyższej wypowiedzi
>> to już nie jest ORM bo potrafi po ID kasować?
>
> Nie, widocznie autorzy zauważyli, że takie coś jest przydatne i dodali. Ale
> brak takiej funkcji nie jest błędem.

Bo ja wiem? Usuwanie każdego rekordu za pomocą poprzedzających
selectów... jak dla mnie dość osobliwe... choć zgodne z obecną ORMową modą.

Ja skomentowałem jedynie Twoje słowa dotyczące tego, iż w dobrym ORMowym
tonie jest stosowanie nie robiących nic użytecznego zapytań przed
wykonaniem właściwych. Bo tak odebrałem, co napisałeś tłumacząc powyższe.

--
Pozdrawiam,
Marek

[Marek S]

W dniu 2019-04-23 o 22:47, Wojciech Bancer pisze:

> Ale po co Ci ORM w takim razie?
> Może chcesz mieć coś w tym stylu:
> http://www.pomm-project.org/

Bardzo ciekawe rozwiązanie. Zainteresuję się nim.
Ale jest jeszcze jedna rzecz. Moją intencją jest biegłe opanowanie
Doctrine z uwagi na to, że w pracy będzie mi to potrzebne. Realizacja
jakiegoś własnego przedsięwzięcia w Doctrine + PostgreSQL +
optymalizacja korzystania z bazy przez Doctrine, byłaby dla mnie cenną
lekcją.

Tak, pamiętam Twoje słowa. Zamiast przyspieszyć 10x procesy w bazie, np.
poprzez dołożenie triggerów odciążających ORM, czy przebudowanie/dodanie
indeksów, wolisz postawić 10 serwerów. Ja preferuję inne podejście:
zoptymalizować bazę, a gdy już więcej się nie da - wtedy zająć się
infrastrukturą sprzętową. Tego nie zmienię w sobie.

>> Nie rozumiem? Co to jest "coś" do Postgresa? Masz na myśli dedykowany
>> ORM? Nie da się Doctrine tak oprogramować, by korzystała z ficzerów
>> Postgresa?
>
> Dać to się wszystko da, kwestia czasu i środków.
> Ale jak dotychczas chyba nie było zapotrzebowania, bo nic tego typu
> opensource nie powstało (albo nie zostało wystarczająco rozreklamowane).

Zostało rozreklamowane nie jeden raz. Ostatnio rowery trójmiejskie
stanęły - to dobra reklama beztroskiego korzystania z wszelkich
udogodnień przez programistów, bez wnikania, co de facto będzie działo
się w tle. ORM ma to załatwić i już. A jak się coś sypnie, skończy się
jakaś sekwencja bo za krótka była (ORM taką sobie wygenerował) etc...
wtedy powstaje problem. Zanika rozumienie nawet prostych SQLi. Jak dla
mnie to czarny scenariusz dla rozwoju. Nie działa - wyrzucamy i robimy
kolejnego bubla.

> Doctrine ma kompatybilność jako cel nadrzędny, więc może jednak ten
> ORM nie jest dla Ciebie?

Tak jak napisałem powyżej - raczej muszę się go trzymać z uwagi na
pojawiające się zadanie w najbliższej przyszłości. Im więcej będę
potrafił wycisnąć z tego ORM, tym lepiej dla mnie. Opanowanie CRUD nie
jest moim celem. Opanowanie Doctrine - już tak.

>> A mimo wszystko tenże ORM pozwala na użycie SQL'a w ramach własnych
>> struktur... Tyle tylko, że samemu trzeba te parę linijek kodu
>> niepotrzebnie dopisywać.
>
> No to po co Ci ORM jak chcesz używać SQLa?

Ponieważ przyspiesza znacząco rozwój oprogramowania. Jeśli utworzę SQL,
to nie oznacza to, że ORM nie będzie potrafił go wykorzystać w sposób
zautomatyzowany. Przykład: obsługa zdarzeń ORMowych, którą mi sam
zapodałeś.

>
>>> Laravel ma dodatkową metodę statyczną Model::destroy($id).
>> No ale my o Doctrine... Z Laravelem już się pożegnałem.
>
> Da się i w doctrine, z użyciem query buildera.
> https://stackoverflow.com/questions/15555042/doctrine-2-delete-with-query-builder (pierwsza odpowiedź)

To ja wiem. To jest korzystanie z SQLa, do którego z awersją podchodzisz
r=traktując go jako raka w ORMie.

> Można też użyć PartialObject / PartialReference:
> https://www.doctrine-project.org/projects/doctrine-orm/en/2.6/reference/partial-objects.html

(...)

> Działa przy różnego rodzaju joinach, czy update, może zadziałać i tu.

Ok, to może mieć sens. Muszę to w głowie przekompilować.

--
Pozdrawiam,
Marek

[Marek S]

W dniu 2019-04-24 o 08:24, ww pisze:

> a QueryBuilder nie umożliwia
> $em->createQueryBuilder()->delete()->where() lub
> $em->createQueryBuilder()->update() ??

Tak, to wiem. Ale jak sama nazwa wskazuje - Query... czyli programista
generuje SQL. Alternatywnie jest też Native SQL - gdzie SQL jest już
zupełnie jawny, bez zastępowania wyrażeń SQLowych odpowiednikami
ORMowymi. QueryBuilder to taki trochę większy kamuflaż SQL'a. Może i
racja, że to można nazwać natywnym sposobem.

Na uwadze miałem to, że Wojtek dość dobitnie podkreślał parę razy, że
SQL w ORM, to delikatnie mówiąc: nietakt. A nawet, że gdy zajdzie
potrzeba użycia SQL'a, to należy zrezygnować z ORM.

Stąd było moje pytanie.

--
Pozdrawiam,
Marek

[Wojciech Bancer]

On 2019-04-24, Marek S <pr...@spamowi.com> wrote:

[...]

> Tak, pamiętam Twoje słowa. Zamiast przyspieszyć 10x procesy w bazie, np.
> poprzez dołożenie triggerów odciążających ORM, czy przebudowanie/dodanie
> indeksów, wolisz postawić 10 serwerów.

Nie, nie, nie, nie. Nie zrozumiałeś. To co napisałem to:
Zamiast przyspieszyć _moze_ 2x procesy w bazie np. przez dołożenie trigerów,
wolę mieć opcję stabilnej obsługi zarówno 10, 100 jak i 1000+ userów "na raz")
bez straty wydajności, w zależności od potrzeb, przez auto-skalowalne rozwiązania.

> Ja preferuję inne podejście:
> zoptymalizować bazę, a gdy już więcej się nie da - wtedy zająć się
> infrastrukturą sprzętową. Tego nie zmienię w sobie.

No i właśnie. Projektujesz system który "ma ścianę" i to dość blisko.

>> Dać to się wszystko da, kwestia czasu i środków.
>> Ale jak dotychczas chyba nie było zapotrzebowania, bo nic tego typu
>> opensource nie powstało (albo nie zostało wystarczająco rozreklamowane).
>
> Zostało rozreklamowane nie jeden raz. Ostatnio rowery trójmiejskie
> stanęły - to dobra reklama beztroskiego korzystania z wszelkich
> udogodnień przez programistów, bez wnikania, co de facto będzie działo
> się w tle.

Problem w tym, że na razie "beztroski" to wydajesz się Ty, w angażowaniu
ORMa bez zrozumienia idei za nim stojących.

> ORM ma to załatwić i już.

I nawet nie chciało Ci się zajrzeć do manuala tegoż ORMa, prawda?
Bo byś znalazł rozdziały dot. wydajności, batch processingu itp.

> A jak się coś sypnie, skończy się jakaś sekwencja bo za krótka była
> (ORM taką sobie wygenerował) etc...

Znowu fałszujesz i nadinterpretowujesz sobie fakty ja Ci wygodnie.
ORM "sam" sobie nie generuje nic. Generuje to co mu każesz.

[...]

>> Da się i w doctrine, z użyciem query buildera.
>> https://stackoverflow.com/questions/15555042/doctrine-2-delete-with-query-builder (pierwsza odpowiedź)
>
> To ja wiem. To jest korzystanie z SQLa, do którego z awersją podchodzisz
> r=traktując go jako raka w ORMie.

Gdzie Ty tam widzisz SQL? o.O
To jest wg Ciebie SQL?
---
$qb = $em->createQueryBuilder();
$qb->delete('Services', 's');
$qb->where('s.project = :project');
$qb->setParameter('project', $project);
---

Ciekawe. Jaki dialekt wiesz może?
Rozróżnij też DQL od SQLa.

To że Doctrine pracuje na obiektach oraz ich modelach i relacjach (patrz wyżej, masz
referencję do obiektów, nie do nazw tabel), nie oznacza że każdy jedne wiersz i linijka
musi być hydrowana.

--
Wojciech Bańcer
wojciec...@gmail.com

[Wojciech Bancer]

On 2019-04-24, Kviat <Kviat> wrote:

[...]

>> Podałem swoje argumenty dlaczego tak uważam i dlaczego uważam triggery
>> za mniej wydajne. Nie mam ochoty się powtarzać. Bazy danych są najbardziej
>> obciążonym kawałkiem w typowych aplikacjach i nie należy ich dociążać.
>
> Triggery i procedury wbudowane nie służą tylko i wyłącznie do celów
> optymalizacyjnych.

No na pewno nie służą do zapisywania w nich logiki biznesowej.
Zbyt kiepski to język.

>> Triggery są też złe pod tym kątem, że operują na przestrzeni globalnej,
>> i (przy mniej ogarniętych w DBA programistach) jest ciężko nad nimi
>> zapanować, nie zapewniają mechanizmów ułatwiających ich kontrolę,
>> wersjonowania, nie pozwalają na efektywną pracę w zespole.
>> Ogólnie mają bardzo dużo wad i niewiele zalet.
>
> Nie widzę przeszkód w wersjonowaniu kodu procedury składowanej..

Aha. I rollback do tego też?
Albo taka magiczna sztuczka jak przeskok o 2 wersje, połączone
ze zmianami na danych.

> Co do pracy w zespole, to przecież osoba pisząca aplikację łączącą się z
> bazą (korzystająca z danych składowanych w bazie) niekoniecznie musi
> wiedzieć, co dana procedura/trigger robi "w środku". Interesują go
> wyniki jakie otrzymuje z bazy.

A potem osoba od DBA odejdzie i jest "aaayyyyeeeeecosiędzieje".
Widziałem takie podejście wiele razy.

>> A że trigger jakoś istotnie szybciej przeiteruje po tablicy
>> w pamięci niż aplikacja, to wybacz nie wierzę. Język interpretowany
>> nie ma dostępu do pamięci "gorszego sortu" tylko tej samej,
>> chyba że serwer DB stoi na innej infrastrukturze.
>
> I wtedy aby przeiterować trzeba z bazy wypchnąć do klienta wszystkie
> rekordy, które mają być przeiterowane, łącznie z rekordami zależnymi,
> żeby otrzymać wynik.

I mam uwierzyć, że jak ktoś nie potrafi optymalnie sobie pobrać
danych do procesowania w aplikacji, to zrobi to optymalnie w triggerze.
Tak, jasne.

> Tutaj to kwestia kompromisu, czy do stu klientów wypchnąć po
> kablach/radiu po np. 5GB żeby sobie przeiterowali lokalnie, czy
> przeiterować 100 razy w bazie i w sieć puścić tylko wynik.

I jak masz 100 takich klientów, to ten ostatni sobie poczeka na wyniki
tydzień, bo maszyna nie ogarnie.

> A nawet przeiterować w bazie raz, zapisać wynik w tabeli tymczasowej i
> pchać sto razy wynik po jednej iteracji.

Ciągle widzę brak ogarniania koncepcji skalowalności "wszerz".
Macie wszyscy nawyki pisania aplikacji z 10 userami dziennie,
czy może aplikacji desktopowych?

> Jeżeli z bazą łączą się różne aplikacje (np. Księgowość, Magazyn,
> Sprzedaż itp.), to łatwiej (i bezpieczniej) jest ogarnąć zależności np.
> między dokumentami w bazie,

Nie. W API. Które jest jedno i tylko ono ma dostęp do bazy.

> niż w poszczególnych aplikacjach. Im więcej różnych aplikacji/modułów
> tym większa szansa, że w którejś z nich będzie błąd i spowoduje
> rozsypanie zależności.

Od logiki biznesowej to jest JEDNA aplikacja, względnie zestaw niezależnych
aplikacji (mikroserwisów) realizujących swoje indywidualne (niezależne) funkcjonalności.

Wystawia się kontrakt, interfejs, dokumentację, walidację i odpowiada za
realizację. A nie pół dupy zza krzaka, część w triggerach, część w aplikacji
(tej której się triggerami nie da), a część bóg wie gdzie.

Aplikacje o których mówiłeś, łączą się do konkretnych usług które potrzebują
(jeśli mówimy o architekturze mikroserwisów), albo do jednej aplikacji (jak
o architekturze monolitycznej) i to one pilnują swojego subsetu reguł.
A nie jakiś kryptyczny kod w bazie.

Dzięki temu masz i większe bezpieczeństwo i większą możliwość fragmentacji,
skalowania, wydzielania, zabezpieczania (dawanie wielu aplikacjom dostępu
do bazy to jakaś masakra, jak chces zprojektować np. aplikacje mobilne w
takim trybie) i większą skalowalność. Wyobrażasz sobie takie API facebooka
realizowane z dostępem "na bazie"?

Takie grzebanie po bazie to mi się wydaje charakterystyczne dla aplikacji
księgowych na Windowsa, które instalowały na desktopie bazę, nie udostępniały
API, a wszelkie inne programy "wdrażane" wymagały specjalistów od modyfikacji
tejże bazy. Koszmarek.

> Dodatkowo, jeżeli potrzebna jest jakaś zmiana, to zmianę wykonujesz w
> jednym miejscu, w bazie, a nie we wszystkich aplikacjach klienckich.

No chyba że zmiana jest niekompatybilna i wtedy trzeba wszysktie aplikacje
klienckie aktualizować, bo baza nie umożliwia porządnego wersjonowania.

[...]

> To tak w skrócie i na szybko, że jednak triggery i procedury składowane
> czasem się przydają.

Błędne założenia (że dostęp do bazy mają jakieś dziwne aplikacje końcowe,
to i błędne wnioski.

--
Wojciech Bańcer
wojciec...@gmail.com

[Borys Pogoreło]

Dnia Wed, 24 Apr 2019 19:03:47 +0200, Marek S napisał(a):

> Pewnie, że są. Jednakże pisałeś, że używam złego narzędzia (Doctrine)
> więc po co mi one skoro sugerujesz bym się pozbył tegoż?

Skoro tak się uparłeś na to Doctrine, to może masz jakieś narzucone
ograniczenia, o których nie napisałeś - tego nie wiemy. Dostajesz
odpowiedzi na pytania, które zadajesz.

> Ja skomentowałem jedynie Twoje słowa dotyczące tego, iż w dobrym ORMowym
> tonie jest stosowanie nie robiących nic użytecznego zapytań przed
> wykonaniem właściwych. Bo tak odebrałem, co napisałeś tłumacząc powyższe.

W ORM-owym tonie jest załadowanie danych do obiektu, *bo tak działa ORM*.

--
Borys Pogoreło
borys(#)leszno,edu,pl

[Kviat]

W dniu 24.04.2019 o 20:18, Wojciech Bancer pisze:

> On 2019-04-24, Kviat <Kviat> wrote:
>
> [...]
>
>>> Podałem swoje argumenty dlaczego tak uważam i dlaczego uważam triggery
>>> za mniej wydajne. Nie mam ochoty się powtarzać. Bazy danych są najbardziej
>>> obciążonym kawałkiem w typowych aplikacjach i nie należy ich dociążać.
>>
>> Triggery i procedury wbudowane nie służą tylko i wyłącznie do celów
>> optymalizacyjnych.
>
> No na pewno nie służą do zapisywania w nich logiki biznesowej.
> Zbyt kiepski to język.

W prawdziwym życiu oprócz logiki biznesowej (w zasadzie to do tego
określenia możesz wrzucić wszystko co chcesz, dopóki nie uściślisz co
masz na myśli), istnieją też inne logiki.
Jeden klient może chcieć moduł sprzedażowy+magazyn w jednym, a inny
osobno fakturowanie, a osobno magazyn. I te dwa różne modele biznesowe
łączy tylko to, że łączą się z tym samym serwerem bazy danych.

Jest jeszcze np. logika ustawodawcy, który wydaje takie, a nie inne
przepisy, że np. nie możesz usunąć jakiegoś dokumentu jak już go
wystawiłeś, albo dokumentu powiązanego logicznie (np. księgowo) z innym.

Masz możliwość implementowania tego w kilku aplikacjach klienckich i
przy każdej drobnej popierdółce zmieniasz i rekompilujesz wszystkie
aplikacje/moduły (nie wspominając o narzędziach firm zewnętrznych) i
wysyłasz klientowi żeby zrobił upgrade na 30 stanowiskach.
Albo robisz jedną zmianę w strukturze bazy, trigger before delete i
wysyłasz jeden upgrade dla serwera bazy. Wszystkie aplikacje, jakkolwiek
by nie były wypasione i choćby się łączyły z serwerem z drugiego końca
kraju, dostają komunikat z serwera, że nie da się usunąć rekordu i już.
(nie czepiaj się proszę przykładu - to tylko przykład)

Pisałem w poprzednim poście, co chyba przeoczyłeś, że jeżeli nie
zapewnisz integralności na poziomie bazy, to wystarczy głupi błąd w
jednej aplikacji klienckiej np.Magazyn w wersji 100.2345.45 SP3 i reszta
aplikacji klienckich leży z błędnymi danymi.

>> Nie widzę przeszkód w wersjonowaniu kodu procedury składowanej..
>
> Aha. I rollback do tego też?

Rollback do czego? Do przepisów księgowych które zmieniły się dwa lata temu?

> Albo taka magiczna sztuczka jak przeskok o 2 wersje, połączone
> ze zmianami na danych.

I w czym problem? Jeżeli wyszła wersja 10.2, a klient pracuje na wersji
10.0 to aktualizacja struktury bazy polega na:
10.0 -> 10.1 -> 10.2
a nie
10.0 -> 10.2

Musi być zachowana ciągłość, bo niektóre zmiany w wersji 10.2 dotyczą
wcześniejszych z wersji 10.1
Nie da się przeskoczyć z wersji 10.0 do 10.2, bo przepisy które są
aktualne dla wersji 10.2 nie istniały w czasie wersji 10.0, a były to
przepisy zmieniające przepisy z wersji 10.1, która wprowadzała zmianę do
przepisów w wersji 10.0.

Logika biznesowa to nie są sztuczki magiczne.

>> Co do pracy w zespole, to przecież osoba pisząca aplikację łączącą się z
>> bazą (korzystająca z danych składowanych w bazie) niekoniecznie musi
>> wiedzieć, co dana procedura/trigger robi "w środku". Interesują go
>> wyniki jakie otrzymuje z bazy.
>
> A potem osoba od DBA odejdzie i jest "aaayyyyeeeeecosiędzieje".
> Widziałem takie podejście wiele razy.

Przecież to nie jest wada triggerów i procedur składowanych.
To wada firmy krzak, w której jedyna "osoba od DBA" robi notatki o
zmianach ołówkiem na karteczkach post-it, a na odchodne ze złości klika
"encrypt stored procedure".

>>> A że trigger jakoś istotnie szybciej przeiteruje po tablicy
>>> w pamięci niż aplikacja, to wybacz nie wierzę. Język interpretowany
>>> nie ma dostępu do pamięci "gorszego sortu" tylko tej samej,
>>> chyba że serwer DB stoi na innej infrastrukturze.
>>
>> I wtedy aby przeiterować trzeba z bazy wypchnąć do klienta wszystkie
>> rekordy, które mają być przeiterowane, łącznie z rekordami zależnymi,
>> żeby otrzymać wynik.
>
> I mam uwierzyć, że jak ktoś nie potrafi optymalnie sobie pobrać
> danych do procesowania w aplikacji, to zrobi to optymalnie w triggerze.
> Tak, jasne.

Zdefiniuj co to znaczy "optymalnie pobrać"?
Tylko połowę WZ, RW i PZ żeby poznać aktualny stan magazynowy towaru,
czy wszystkie 15 tysięcy dokumentów zawierających jeszcze po 20 innych
pozycji towarowych z ostatnich czterech miesięcy, albo tworzyć w
kliencie dynamiczne zapytania do bazy, potworki SQLowe wybierające z
ostatnich 15 tysięcy dokumentów tylko te zawierające dany towar i niech
sobie klient zlicza jaki jest stan?
A w czasie pobierania i zliczania trzy inne stanowiska właśnie
wygenerowały kolejne 3 dokumenty i stan się zmienił.

A nie lepiej zliczyć na bieżąco w bazie AFTER INSERT/DELETE/UPDATE po
każdym dokumencie i zaktualizować pole ze stanem i wysłać tylko do
klienta aktualny stan?

>> Tutaj to kwestia kompromisu, czy do stu klientów wypchnąć po
>> kablach/radiu po np. 5GB żeby sobie przeiterowali lokalnie, czy
>> przeiterować 100 razy w bazie i w sieć puścić tylko wynik.
>
> I jak masz 100 takich klientów, to ten ostatni sobie poczeka na wyniki
> tydzień, bo maszyna nie ogarnie.

Albo nie poczeka, bo serwer już dawno to zrobił i ma gotowy wynik w
buforze i jak trzeci klient zapyta o to samo, to mu wyśle gotowca.
Setnemu też.
Ten setny sto razy dłużej poczeka, gdy serwer będzie musiał wysłać do
100 klientów po 50 tys rekordów żeby sobie sami przeliczyli.

>> A nawet przeiterować w bazie raz, zapisać wynik w tabeli tymczasowej i
>> pchać sto razy wynik po jednej iteracji.
>
> Ciągle widzę brak ogarniania koncepcji skalowalności "wszerz".
> Macie wszyscy nawyki pisania aplikacji z 10 userami dziennie,
> czy może aplikacji desktopowych?

Czasem model biznesowy klienta skalowalności wszerz polega na dołożeniu
30 biurka ze sprzedawcą w mieście dalej niż dołożenie dziesiątego
serwera z bazą danych, bo jeden serwer nie wyrabia z pchaniem 15 tys
dokumentów na sekundę do 30 sprzedawców przez vpn po neostradzie albo
przez sieć komórkową, bo akurat handlowiec laptopa odpalił w samochodzie
stojąc na MOPie i chciał sprawdzić stan magazynowy gwoździa 3".
Zamiast powiedzieć klientowi ile ma gwoździ na stanie to wisi na
telefonie i czeka aż mu się tabelka z dokumentami magazynowymi z
ostatnich 4 miesięcy ściągnie do pamięci laptopa i laptop aktualny stan
przeliczy. Świetny pomysł.

>> Jeżeli z bazą łączą się różne aplikacje (np. Księgowość, Magazyn,
>> Sprzedaż itp.), to łatwiej (i bezpieczniej) jest ogarnąć zależności np.
>> między dokumentami w bazie,
>
> Nie. W API. Które jest jedno i tylko ono ma dostęp do bazy.

Oczywiście zgoda.
W świecie idealnym każda aplikacja ma api.
Ba! A nawet api stoi na osobnej maszynie, a serwer bazy w bunkrze.

Co nie zmienia faktu, że przy Twoim podejściu nadal do api musisz
przesłać 100 razy po 15 tys. dokumentów, gdy 100 klientów poprosi o
aktualny stan magazynowy i to api te 100 razy po 15 tys dokumentów musi
przesłać do klientów. Hmmm... to może niech api raz przeliczy stan i
sobie go zapisze... w bazie danych? I tak api przy każdym jednym
INSERT/UPDATE/DELETE jednego dokumentu będzie pobierał wszystkie
dokumenty z bazy i przeliczał i zapisywał w bazie?

W świecie rzeczywistym zdarza się, że api jest instalowane wraz z
aplikacją kliencką, żeby klient który kupił program miał ułatwienie w
pisaniu (czy używaniu) "autorskich" rozszerzeń, a komp z serwerem
bazodanowym stoi w pokoju obok.
Skoro w/g Ciebie serwer bazodanowy nie jest od logiki biznesowej, to api
tym bardziej.

W świecie rzeczywistym zdarza się, że pomimo istnienia api, zlecenie
napisania rozszerzenia/wtyczki przyjmuje ktoś, kto i tak "wie lepiej" i
łączy się do bazy bezpośrednio, bo szef dał mu hasło.
Dlatego wymyślono opcję "encrypt stored procedure", żeby w razie takiego
zachowania maksymalnie zmniejszyć niepożądane skutki. Jak będzie chciał
coś grzebnąć w bazie bezpośrednio z SQL Management Studio, to nawet nie
usunie rekordu powiązanego logicznie (biznesowo) z innym rekordem.
A nawet jak mu się uda jakimś cudem usunąć np. WZ, to procedura zadba o
to, żeby uaktualnić stan magazynowy.

>> niż w poszczególnych aplikacjach. Im więcej różnych aplikacji/modułów
>> tym większa szansa, że w którejś z nich będzie błąd i spowoduje
>> rozsypanie zależności.
>
> Od logiki biznesowej to jest JEDNA aplikacja, względnie zestaw niezależnych
> aplikacji (mikroserwisów) realizujących swoje indywidualne (niezależne) funkcjonalności.

Przecież napisałem, że może być wiele...
W jaki sposób ma to zagwarantować integralność danych w bazie?

> Wystawia się kontrakt, interfejs, dokumentację, walidację i odpowiada za
> realizację. A nie pół dupy zza krzaka, część w triggerach, część w aplikacji
> (tej której się triggerami nie da), a część bóg wie gdzie.

W świecie idealnym pewnie tak jest.
W prawdziwym świecie niektóre aplikacje żyją, rozwijają się i ewoluują
latami wraz ze zmianami, które były nie do przewidzenia na etapie
projektowania ileś lat wcześniej, nie wspominając o możliwościach
ówczesnych serwerów bazodanowych czy infrastruktury.

Są też takie aplikacje, gdzie zdecydowanie lepiej i bezpieczniej jest
zapewnić integralność danych na poziomie bazy danych niż w aplikacji, bo
z serwerem bazy danych ktoś może połączyć się nie tylko dedykowaną
aplikacją czy przez api.

> Aplikacje o których mówiłeś, łączą się do konkretnych usług które potrzebują
> (jeśli mówimy o architekturze mikroserwisów), albo do jednej aplikacji (jak
> o architekturze monolitycznej) i to one pilnują swojego subsetu reguł.
> A nie jakiś kryptyczny kod w bazie.

Aplikacje o których mówiłem łączą się z serwerem bazy danych.
Zapewne masz na myśli jakieś inne aplikacje.

> Dzięki temu masz i większe bezpieczeństwo i większą możliwość fragmentacji,
> skalowania, wydzielania, zabezpieczania (dawanie wielu aplikacjom dostępu
> do bazy to jakaś masakra, jak chces zprojektować np. aplikacje mobilne w
> takim trybie) i większą skalowalność. Wyobrażasz sobie takie API facebooka
> realizowane z dostępem "na bazie"?

Nie, nie wyobrażam sobie takiego API facebooka.
Nie samym facebukiem świat żyje.

> Takie grzebanie po bazie to mi się wydaje charakterystyczne dla aplikacji
> księgowych na Windowsa,

Świat się nie kończy na wtyczce do internetu.

> które instalowały na desktopie bazę, nie udostępniały
> API, a wszelkie inne programy "wdrażane" wymagały specjalistów od modyfikacji
> tejże bazy. Koszmarek.

Zaskoczę Cię, są też takie, gdzie serwer bazy danych stoi na osobnym
sprzęcie i mają api.
Co nie zmienia faktu, że zapewnianie integralności logicznej
dokumentów/wpisów w bazie z poziomu aplikacji klienckich to pomysł co
najmniej średni.

>> Dodatkowo, jeżeli potrzebna jest jakaś zmiana, to zmianę wykonujesz w
>> jednym miejscu, w bazie, a nie we wszystkich aplikacjach klienckich.
>
> No chyba że zmiana jest niekompatybilna

No chyba, że zmiana jest kompatybilna i nie musisz zmieniać wszystkich
aplikacji klienckich.

>i wtedy trzeba wszysktie aplikacje
> klienckie aktualizować, bo baza nie umożliwia porządnego wersjonowania.

A co przeszkadza w wersjonowaniu skryptów migracyjnych?
Są też pomocne narzędzia:
https://docs.microsoft.com/en-us/sql/ssdt/how-to-use-schema-compare-to-compare-different-database-definitions?view=sql-server-2017

"The results of the comparison appear as a set of actions that must be
taken with the target to make it the same as the source. Once the
comparison is complete you can update the target directly (if the target
is a project or a database) or generate an update script that has the
same effect.

The differences between source and target appear in a grid for easy
review. You can drill into and review each difference in the results
grid or in script form. You can then selectively exclude specific
differences.

You can save comparisons either as part of a SQL Server Database project
or as a standalone file. You can also set options that control the scope
of the comparison and aspects of the update. Then you can save the
comparison so that you can easily repeat the same comparison later or
use it as the starting point for new comparison."

> [...]
>
>> To tak w skrócie i na szybko, że jednak triggery i procedury składowane
>> czasem się przydają.
>
> Błędne założenia (że dostęp do bazy mają jakieś dziwne aplikacje końcowe,
> to i błędne wnioski.

Błędne założenie, że nie istnieją aplikacje końcowe z dostępem do bazy,
prowadzą do błędnych wniosków, że triggery i procedury składowane nie są
w bazie danych potrzebne. A już stwierdzenie, że są złe bo się ich
gdzieśtam nie używa jest co najmniej dziwne.

Pozdrawiam
Piotr

[Wojciech Bancer]

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.

To co pisałem o triggerach odnosiło się do świata serwerowo-webowego,
nie do desktopowych aplikacjach klienckich przeznaczonych do działania
w intranecie. 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ł).

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.

Jak masz merytoryczne argumenty dlaczego we współczesnym systemie webowym
trigger byłby lepszy w użyciu od API, to chętnie posłucham, ale dyskusja
o "desktopach" to jak dyskusja o rowerach na grupie samochodowej. Nie
ten świat.

--
Wojciech Bańcer
wojciec...@gmail.com

[Marek S]

W dniu 2019-04-24 o 21:19, Borys Pogoreło pisze:

>> Ja skomentowałem jedynie Twoje słowa dotyczące tego, iż w dobrym
>> ORMowym tonie jest stosowanie nie robiących nic użytecznego zapytań
>> przed wykonaniem właściwych. Bo tak odebrałem, co napisałeś
>> tłumacząc powyższe.
>
> W ORM-owym tonie jest załadowanie danych do obiektu, *bo tak działa
> ORM*.

Sam napisałeś, że niekoniecznie tak działa i można śmiało używać SQL w
tymże ORM i krzywda mu się nie stanie.

Ty również mnie zrozum, że nie ma mojej zgody na 200% narzut obciążenia
bazy danych ze strony spartaczonej idei ORM, szczególnie gdy można w nim
banalnie rozwiązać tenże problem bez rezygnacji z samego ORM. Jak dla
mnie podejście "bo tak działa ORM" jest równoznaczne z "jestem leniem
informatyki i mam gdzieś wydajność nawet gdy to tylko 3 linijki kodu".
Sam mi pokazałeś jak łatwo naprawić te błędy założeń ORM. Zamierzam
pójść tą drogą.

--
Pozdrawiam,
Marek

[Marek S]

W dniu 2019-04-24 o 20:01, Wojciech Bancer pisze:

> Nie, nie, nie, nie. Nie zrozumiałeś. To co napisałem to:
> Zamiast przyspieszyć _moze_ 2x procesy w bazie np. przez dołożenie trigerów,
> wolę mieć opcję stabilnej obsługi zarówno 10, 100 jak i 1000+ userów "na raz")
> bez straty wydajności, w zależności od potrzeb, przez auto-skalowalne rozwiązania.

Ok, czuję intencję.
BTW
Jak tworzysz podkreślenia? Próbowałem _ przed i za, próbowałem __ i
kiszka. Być może więcej wyrazowych wyrażeniach próbowałem. Nie pamiętam już.

>> Ja preferuję inne podejście:
>> zoptymalizować bazę, a gdy już więcej się nie da - wtedy zająć się
>> infrastrukturą sprzętową. Tego nie zmienię w sobie.
>
> No i właśnie. Projektujesz system który "ma ścianę" i to dość blisko.

Czy jest coś w tym nagannego, że z wyciskam z serwera max. ilość
operacji/s? Może inaczej: proponujesz pousuwać wszelkie optymalizacje z
bazy, jak np. indeksy, po to by być daleko od ściany i mieć świadomość,
że można dużo poprawić w tejże bazie?

> Problem w tym, że na razie "beztroski" to wydajesz się Ty, w angażowaniu
> ORMa bez zrozumienia idei za nim stojących.

Nie beztroski lecz uczący się. Jednakże już w tym wątku dostałem
wytyczne jak "naprawić" ideę ORM w zakresie usuwania/aktualizacji
rekordów poprzez banalnie proste zabiegi na udostępnionych przez ORM
mechanizmach. Mam na myśli łatanie niedostatków poprzez stosowanie
querybuildera etc.

> I nawet nie chciało Ci się zajrzeć do manuala tegoż ORMa, prawda?
> Bo byś znalazł rozdziały dot. wydajności, batch processingu itp.

Jestem w trakcie czytania dokumentacji. Na bieżąco pytam o to, czego nie
rozumiem. Wyssałeś z palca moje podejście pomimo iż w poprzednich
wątkach wyraźnie pisałem iż raczkuję dopiero i potrzebuję podpowiedzi.
Otrzymałem, doczytam i wdrożę w testowym projekcie.

>> To ja wiem. To jest korzystanie z SQLa, do którego z awersją podchodzisz
>> r=traktując go jako raka w ORMie.
>
> Gdzie Ty tam widzisz SQL? o.O
> To jest wg Ciebie SQL?
> ---
> $qb = $em->createQueryBuilder();
> $qb->delete('Services', 's');
> $qb->where('s.project = :project');
> $qb->setParameter('project', $project);
> ---

Kompletnie nie znam querybuildera a widzę (być może fałszywie) to, co
poniżej. Zgaduję, że Services odnosi się do nazwy entity a ta do tabeli
o tej samej nazwie. Więc:

"DELETE FROM services s WHERE s.project=$project"

Czy źle odczytuję powyższe?

> Ciekawe. Jaki dialekt wiesz może?

Coś w rodzaju mowy od tyłu: niby słowa są znane... ale takie trochę inne.

Ale zgodziłem się już wcześniej, że jest to użyteczne narzędzie, które
pozwoli mi na unikniecie kosztownych DELETE'ów. Oczywiście po zapoznaniu
się wcześniejszym z batch processingiem. Bo być może to też będzie
świetnym mechanizmem do optymalizacji zapytań hurtowych.

--
Pozdrawiam,
Marek

[Borys Pogoreło]

Dnia Thu, 25 Apr 2019 22:49:33 +0200, Marek S napisał(a):

> Ty również mnie zrozum, że nie ma mojej zgody na 200% narzut obciążenia
> bazy danych ze strony spartaczonej idei ORM, szczególnie gdy można w nim
> banalnie rozwiązać tenże problem bez rezygnacji z samego ORM.

Aż tak często usuwasz rekordy w bazie by miało to jakiekolwiek wymierne
znaczenie, kosztem przejrzystości kodu?

Już się zdecydowałeś na ORM i związane z nim kompromisy, w tym spory narzut
między modelem a bazą. A jeszcze niedawno tak narzekałeś na ideę Query
Buildera.

> Jak dla mnie podejście "bo tak działa ORM" jest równoznaczne z "jestem
> leniem informatyki i mam gdzieś wydajność nawet gdy to tylko 3 linijki
> kodu". Sam mi pokazałeś jak łatwo naprawić te błędy założeń ORM.

Dlaczego tak autorytatywnie uważasz, że to są błędy?

--
Borys Pogoreło
borys(#)leszno,edu,pl

[Kviat]

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

[Wojciech Bancer]

On 2019-04-25, Marek S <pr...@spamowi.com> wrote:

>> Nie, nie, nie, nie. Nie zrozumiałeś. To co napisałem to:
>> Zamiast przyspieszyć _moze_ 2x procesy w bazie np. przez dołożenie trigerów,
>> wolę mieć opcję stabilnej obsługi zarówno 10, 100 jak i 1000+ userów "na raz")
>> bez straty wydajności, w zależności od potrzeb, przez auto-skalowalne rozwiązania.
>
> Ok, czuję intencję.
> BTW
> Jak tworzysz podkreślenia? Próbowałem _ przed i za, próbowałem __ i
> kiszka. Być może więcej wyrazowych wyrażeniach próbowałem. Nie pamiętam już.

Przez dodanie _ na początku i na końcu wyrazu (bez spacji).

>>> Ja preferuję inne podejście:
>>> zoptymalizować bazę, a gdy już więcej się nie da - wtedy zająć się
>>> infrastrukturą sprzętową. Tego nie zmienię w sobie.
>>
>> No i właśnie. Projektujesz system który "ma ścianę" i to dość blisko.
>
> Czy jest coś w tym nagannego, że z wyciskam z serwera max. ilość
> operacji/s?

Wygląda jak klasyczna niepotrzebna optymalizacja.
Zamieniasz też " na ', żeby zyskać 2 sekundy czasu serwera w rok?

> Może inaczej: proponujesz pousuwać wszelkie optymalizacje z
> bazy, jak np. indeksy, po to by być daleko od ściany i mieć świadomość,
> że można dużo poprawić w tejże bazie?

Wszysktie? Nie. Nadmiarowe, stworzone "na wszelki wypadek"? Tak.
To co robisz nosi wszelkie znamiona premature optimization i unnecessary
optimization. Niby jest wydajnej, ale różnicy nikt tak realnie nie zobaczy,
a Ty tracisz na tym czas.

>> Problem w tym, że na razie "beztroski" to wydajesz się Ty, w angażowaniu
>> ORMa bez zrozumienia idei za nim stojących.
>
> Nie beztroski lecz uczący się. Jednakże już w tym wątku dostałem
> wytyczne jak "naprawić" ideę ORM w zakresie usuwania/aktualizacji
> rekordów poprzez banalnie proste zabiegi na udostępnionych przez ORM
> mechanizmach. Mam na myśli łatanie niedostatków poprzez stosowanie
> querybuildera etc.

Query builder *nie* jest żadnym łataniem, ani też żadnym SQLem.
Jest narzędziem do budowania zapytań.
Jak chciałbyś odpytywać bazę inaczej?
Nie wszystko na bazie sprowadza się do robienia pojedynczych zapytań
i działania na pojedynczych obiektach.

>>> To ja wiem. To jest korzystanie z SQLa, do którego z awersją podchodzisz
>>> r=traktując go jako raka w ORMie.
>>
>> Gdzie Ty tam widzisz SQL? o.O
>> To jest wg Ciebie SQL?
>> ---
>> $qb = $em->createQueryBuilder();
>> $qb->delete('Services', 's');
>> $qb->where('s.project = :project');
>> $qb->setParameter('project', $project);
>> ---
>
> Kompletnie nie znam querybuildera a widzę (być może fałszywie) to, co
> poniżej. Zgaduję, że Services odnosi się do nazwy entity a ta do tabeli
> o tej samej nazwie. Więc:
>
> "DELETE FROM services s WHERE s.project=$project"

No nie. Query builder zbuduje zapytanie DQL:
https://www.doctrine-project.org/projects/doctrine-orm/en/2.6/reference/dql-doctrine-query-language.html

Uwalnie Ciebie od znajomości struktury (nazw kolumn kluczy, nazw tabeli),
bo sam to ogarnia na podstawie otworzonej przez Ciebie relacji z obiektami
Entities.

A potem ten DQL zostanie przetworzony na coś w stylu:
DELETE FROM services s WHERE s.project_id = " . $project->getId(); // jeśli $project to obiekt
DELETE FROM services s WHERE s.project_id = " . $project; // jeśli $project to prymityw (liczba lub string)

ale już bez Twojego udziału.
Ale tak g gdzieś ostatecznie pod spodem jest wynik w postaci SQL.
Przecież musi być, bazy danych inaczej nie gadają.

Zauważ, że:
- nie znasz tej nazwy tabeli (doctrine sam ją "ogarnia"
na podstawie tego jak zdefiniowałeś entity)
- do $project wstawiasz obiekt entity lub id, a doctrine
sam sobie poradzi z tym by to miało dla niego sens
sam też zna nazwę kolumny, na podstawie relacji jaka
była utworzona w entity

--
Wojciech Bańcer
wojciec...@gmail.com

[Wojciech Bancer]

On 2019-04-25, Kviat <Kviat> wrote:

[...]

>> Ciachnąłem, bo dyskutujemy o dwóch różnych światach.
> Myślałem, że dyskutujemy o triggerach/sp.

Tak, dyskutujemy, ale wszystko ma jakiś kontekst.
Tutaj raczej domyślnie należy założyć że nie dyskutujemy o aplikacji
desktopowej (skoro mowa o Symfony i Doctrine).

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

[...]

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

Semantyka. Wady triggerów pozostają ich wadami, ale w warunkach "desktopowych"
nie wymyślono jeszcze zgrabnego rozwiązania, więc się one utrzymują.

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

Tak, wiem. Podałem Ci też przykład aplikacji mobilnych. Nadal.

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

W electronie (taki chrome embedded) tych ograniczeń nie masz i z poziomu
takiej przeglądarki możesz korzystać z ww modułów i słać zapytania do bazy
bezpośrednio [1]).

[...]

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

Oczywiście że mają. Już pisałem, serwery baz, są elementem który się *najtrudniej*
skaluje "wszerz" (i wielokrotnie pisałem o jakiej wydajności piszę - nie o jako tej
rozumianej przez umiejętność obsługi dużych grup użytkowników i stosunkowo łatwy/automatyczny
mechanizm skalowania tego). A zarówno master-slave, czy partycjonowanie wprowadzi takie
same opóźnienia triggerów (czyli eliminuje ich jedyną, "zaletę" szybkości komunikacji),
bez eliminowania wad triggerów.

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

I jak myślisz, jak Ci to zadziała na sklepie wielkości Amazona?

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

Piszemy o różnych rodzajach wydajności.

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

Ja też nie wspominam o aplikacjach klieckich, więc bądź łaskaw
nie używać argumentów, których nie stosowałem.

[...]

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

O popatrz. I zaraz odkryjesz dlaczego mongodb w ostatnich latach stało
się tak popularne. :) A jak pogrzebiesz trochę dalej, to zobaczysz dlaczego
coś takiego jak elasticsearch ma raację bytu.

I dlaczego ostatnio dodawane do platform cloud zarządzalne przez providera
bazy cloud (Amazon DynamoDB, Google Firebase, Azure CosmosDB) są właśnie
bazami nie-relacyjnymi, na których nie odpalisz wbudowanych triggerów.

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

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

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

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

https://cloud.google.com/functions/
https://aws.amazon.com/lambda/

i w zależności od zapotrzebowania dostanę od 1 do 1000 instancji,
albo i więcej. Bez robienia czegokolwiek.

Albo (jak potrzebujesz) jesteś w stanie udostępniać dane klientom w czasie
rzeczywistym bez potrzeby odpytywania przez klienta:

https://firebase.google.com/docs/database/

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.

--
Wojciech Bańcer
wojciec...@gmail.com

[Borys Pogoreło]

Dnia Fri, 26 Apr 2019 01:57:09 +0200, Kviat napisał(a):

> 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 no, w teorii jest. Podejrzewam, że require('node-mysql') czy coś
podobnego ma szansę zadziałać. Na szczęście nikt raczej na to nie wpadł ;)

Za to w świecie noSQLi rzeźbienie z poziomu przeglądarki bezpośrednio po
bazie jest na porządku dziennym (choć bliżej temu do key/value storage,
więc ryzyko dużo mniejsze).

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

Tak po prawdzie to właśnie w tym kierunku to poszło wraz z modą na noSQL.
Czyli skalowalne składowisko danych bez relacji i bez schemy, a często
nawet bez ACID, za to z szybkim dostępem. Ma to swoje zastosowania, ale w
większości przypadków korzysta się z nich w ramach hype driven development,
a nie realnych potrzeb.

--
Borys Pogoreło
borys(#)leszno,edu,pl

[Kviat]

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

[Wojciech Bancer]

On 2019-04-26, Borys Pogoreło <bo...@pl.edu.leszno> wrote:

[...]

>> 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 no, w teorii jest. Podejrzewam, że require('node-mysql') czy coś
> podobnego ma szansę zadziałać. Na szczęście nikt raczej na to nie wpadł ;)

Nie jest, są ograniczenia wynikające z trybu sandbox przeglądarki.
Zadziała w electronie.

> Za to w świecie noSQLi rzeźbienie z poziomu przeglądarki bezpośrednio po
> bazie jest na porządku dziennym (choć bliżej temu do key/value storage,
> więc ryzyko dużo mniejsze).

Oczywiście ze nie leci bezpośrednio (tylko zazwyczaj przez API, które to
waliduje). To że bez dodatkowych (niepotrzebnych) przeszktałceń formatu,
to już inna sprawa.

--
Wojciech Bańcer
wojciec...@gmail.com

[Wojciech Bancer]

On 2019-04-26, Kviat <Kviat> wrote:

[...]

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

Ja napisałem, że w dzisiejszym świecie "w którym zapotrzebowanie
na dane", przetwarzane coraz szybciej oraz ich ilość rośnie w zastraszającym
tempie z roku na rok, to już jest wada.

A Ty jako kontr-przykład podajesz mi architekturę rodem z lat 90-tych,
intranetu i mówisz "u mnie działa". Jasne. Działa. Co nie znaczy
że owa architektura nie ma wad o których pisałem. Po prostu te
wady są akceptowalne w konkternych rozwiązaniach (jeszcze).

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

I dlaczego tak jest, jak myślisz?

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

A zastanowiłeś się dlaczego nie mają? Dlaczego model "otwarci
do świata" się nie sprawdził?

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

Dobrze. Czy myślisz, że wystarczy w sklepie pokroju żabki, jak ten będzie
zautomatyzowany i będzie *musiał* wiedzieć że klient wychodzący przez
kasę automatyczną nosi to i to, zabrane z półki tamtej i siamtej,
dokonać rozliczenia tego klienta i ewentualnie dokonać korekty jak
klient postanowi się rozmyślić?

Pierwsze sklepy już gdzieś tam się pojawiają. Co będzie za 5-10 lat?
A może chciałbyś mieć dane o pozycji klienta z telefonem w czasie
rzeczywistym poprzez urządzenia IoT, by serwować mu dopasowany content
w sklepie? Albo sterować urządzeniami domowymi/firmowymi w reakcji
na zdarzenia rzeczywiste?

Do tego wszystkiego model "centralny serwer + triggery" klęknie.
Po prostu.

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

Ale dlaczego potrzebuje? Czyż nie jest wydajniej mieć monolityczny
serwer z triggerami i wszystko "w jednej maszynie"? Takie można odnieść
wrażenie po tym jak zachwalałeś triggery oraz ich optymalność.

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

Jeszcze. Ale odpowiedzialne projektowanie *aplikacji webowej* musi
przewidywać pewien rozwój sytuacji. Inaczej będziesz jak nasza klasa
i pan gąbka z błędem typu error 500.

Architektura oparta o monolityczne serwery i triggery jest zwyczajnie zamknięta
do małej skali. _Zmiana_ wymaga przepisania logiki. Architektura oparta o
ORM (i zdarzenia), może i jest jednostkowo wolniejsza, ale w razie potrzeby
w łatwy sposób zostać rozbudowana "w bok", by spełnić nagłe wymagania
obciążeniowe. I równie szybko może być ściągnięta w dół (bo się zapotrzebowanie
skończyło).

Weź takie obciążenie np. na black friday. Ja dostawię 3-4, 10, 15 maszyn
i się wyrobię. Jak przestanąć być potrzebne, to zejdą w dół. A storage mam
stosunkowo tani i niezwykle szybki (bo nie pilnuje wszystkiego czego nie musi
sam robić).

A jaką Ty masz wizję? Dostawimy 10 serwerów, zrobimy migrację, a jak przestanie
być potrzebne, to migrujemy ponownie? Wszystko ręcznie, z olbrzymim wysiłkiem
czasowym Bez żadnej automatyki?

O ile *koszt* projektowania aplikacji w jeden i drugi sposób jest podobny,
to poprzez ograniczanie logiki siedzącej na bazie masz potem dużo istotnych
korzyści - mniejszy jest koszt przepisania aplikacji z ORM do ODM niż koszt
przeniesienia logiki z bazy do aplikacji.

Mniejszy jest też koszt optymalizacji konkretnych bottlenecków "na aplikacji"
niż na bazie (bo masz mnóstwo alternatyw od zapewnienia cache w pamięci,
rozładowania ruchu poprzez load balancery, kontroli że np. pojedynczy
użytkownik nie może wykonać > 10 żądań na sekundę (throttling pattern),
tworzenia kolejek i priorytetów (a nie wyłącznie obsługi fifo).

a to wszystko możesz stosować na różnych poziomach infrastruktury,
połączonej w logiczną strukturę z aplikacją (podejście IaaC) i zebrane
w jednym logicznym miejscu.

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

Właśnie odwrotnie. Tam *gdzie nie musisz* żyłować wydajności pojedynczej
maszyny, nie stosujesz niepotrzebnej optymalizacji (takiej która potem blokuje
ewentualne drogi do przodu), ale projektujesz system tak by był na potencjalne
potrzeby otwarty.

*Nie oznacza to*, że musisz od razu zakładać że będziesz miał ruch 100k userów
godzinę. Ale w miarę możliwości powinieneś projektować system tak, żeby
niewielkim kosztem zmian móc to zrobić.

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

Ale (poza desktopami), to wszyscy chyba się przerzucili z triggerów/sp,
na inplementacje w aplikacjach. Nie tylko Amazon i Google.

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

Oczywiście że ma i będzie (bo apetyt na dane rośnie). Zobacz sobei IoT,
ML, segmenty Big Data.

A tak swoją drogą, to zauważ, że te wszystkie klasyczne aplikacje księgowe
o których mówisz "ostały się" głównie w większych przedsiębiorstwach,
bo tam koszty zmian są znaczące, a ludzie do tych systemów są już
przyzwyczajeni i przeszkoleni.

Ale w takim sektorze mikro-przedsiębiorstw, jedno-osobowych DG,
zamiast instalowanej wypaśnie aplikacji z serwerem bazy masz coraz
bardziej popularne serwisy typu infakt, wfirma, itp.

I już teraz te serwisy mają więcej możliwości niż desktopowe aplikacje
będą miały kiedykolwiek (dla tej grupy). Masz więc i odczytywanie/procesowanie
faktur z PDF (rozpoznawanie obrazów), masz automatyczne wysyłanie przypomnień
na maila, integracje z allegro/ceneo/magazynami *różnych* sklepów po API,
systemami płatności, bankami, wysyłaniem maili do klientów, zarządzaniem
windykacją, automatycznym przeliczaniem kursów walut, CRM, aplikacje/wersje
mobilne, automatyzacją wystawiania i wysyłka faktur seryjnych (Rachmistrz
to już potrafi?) i bardzo szybkie wprowadzanie nowinek dostępnych
*u wszystkich na raz* (np. weryfikacja numerów VAT kontrahentów).
A i masz możliwość integracji z własnymi systemami, np. by sklep XYZ
wystawiał sam fakturę, nawet jeśli ten XYZ jest Twoim własnym i autorskim
rozwiązaniem (bo jest dostępne proste API i nie trzeba się zagłębiać
w rozwiązywanie zależności na > 100 tabelach w bazie). I to wszystko
dużo szybciej i taniej niż desktopowe wersje oferowały kiedykolwiek.

--
Wojciech Bańcer
wojciec...@gmail.com

[Borys Pogoreło]

Dnia Fri, 26 Apr 2019 17:18:19 +0200, Wojciech Bancer napisał(a):

> Pierwsze sklepy już gdzieś tam się pojawiają. Co będzie za 5-10 lat?
> A może chciałbyś mieć dane o pozycji klienta z telefonem w czasie
> rzeczywistym poprzez urządzenia IoT, by serwować mu dopasowany content
> w sklepie? Albo sterować urządzeniami domowymi/firmowymi w reakcji
> na zdarzenia rzeczywiste?

Ale to nie są zadania dla triggerów czy procedur, skoro już o tym mowa.

> Ale dlaczego potrzebuje? Czyż nie jest wydajniej mieć monolityczny
> serwer z triggerami i wszystko "w jednej maszynie"? Takie można odnieść
> wrażenie po tym jak zachwalałeś triggery oraz ich optymalność.

Zjedź z przykładami z top 10 światowego internetu, bo to trochę mało
reprezentatywne. Inna skala, inne problemy. Choć może weźmy przykład
takiego Instagrama, powinien pasować do załozonej przez Ciebie skali. Ich
bazy korzystają z procedur PL/PGSQL do generowania unikalnych i
bezkolizyjnych identyfikatorów. Bo tak było prościej, niż dopisywać i
utrzymywać kolejną dedykowaną usługę.

> Jeszcze. Ale odpowiedzialne projektowanie *aplikacji webowej* musi
> przewidywać pewien rozwój sytuacji. Inaczej będziesz jak nasza klasa
> i pan gąbka z błędem typu error 500.

To jest przypadek skrajny, zupełnie oderwany od rzeczywistości. Ile znasz
innych serwisów, które odniosły tak gwałtowny sukces (i jednocześnie tak
bardzo położyły temat od strony technicznej)?

> O ile *koszt* projektowania aplikacji w jeden i drugi sposób jest podobny,

Co najwyżej w średnich i dużych firmach IT, w których siedzą ludzie znający
się na wielu rzeczach, a cena dla klienta końcowego jest i tak za
roboczogodzinę. A wydaje mi się, że cały czas piszesz z takiej właśnie
perspektywy, firmy tworzącej rozwiązania dla dużych klientów, których stać
na wdrożenie za kwoty sześciocyfrowe i większe.

Pomijasz za to ogromną rzeszę mniejszych firm, których potrzeby są na tyle
niskie, że "typowe" rozwiązania są dla nich wytarczające z dużym zapasem.
Oni nie potrzebują automatycznego postawienia dodatkowych podów w trakcie
Black Friday, bo nie wygenerują takiego obciążenia. A jeśli w perspektywie
5-10 lat powiększą swój biznes 10 razy, to rzeczona baza dalej nie będzie
miała z tym problemu.

I to też nie są klienci, którzy będą wdrażać ML / Big Data, bo ich na to
zwyczajnie nie stać, tylko co najwyżej skorzystają z istniejącej usługi.

> Mniejszy jest też koszt optymalizacji konkretnych bottlenecków "na aplikacji"
> niż na bazie (bo masz mnóstwo alternatyw od zapewnienia cache w pamięci,
> rozładowania ruchu poprzez load balancery, kontroli że np. pojedynczy
> użytkownik nie może wykonać > 10 żądań na sekundę (throttling pattern),
> tworzenia kolejek i priorytetów (a nie wyłącznie obsługi fifo).
>
> a to wszystko możesz stosować na różnych poziomach infrastruktury,
> połączonej w logiczną strukturę z aplikacją (podejście IaaC) i zebrane
> w jednym logicznym miejscu.

Brzmi pięknie i zgodnie ze sztuką, ale dodaj jeszcze ile kostuje stworzenie
takiej aplikacji i utrzymanie na takiej infrastrukturze. Ile jest firm,
które tego potrzebują i za to zapłacą?

> I już teraz te serwisy mają więcej możliwości niż desktopowe aplikacje

> będą miały kiedykolwiek (dla tej grupy). (...)

Co nie znaczy, że z tyłu nie stoi jakiś SQL napędzany procedurami.

--
Borys Pogoreło
borys(#)leszno,edu,pl

[Kviat]

W dniu 26.04.2019 o 17:18, Wojciech Bancer pisze:

> On 2019-04-26, Kviat <Kviat> wrote:
>
>
> A Ty jako kontr-przykład podajesz mi architekturę rodem z lat 90-tych,
> intranetu i mówisz "u mnie działa". Jasne.

Nic takiego nie podałem. Nie mam pojęcie dlaczego wymyśliłeś sobie
architekturę rodem z lat 90-tych.
Więc bądź łaskaw nie używać argumentów, których nie stosowałem.

> Działa. Co nie znaczy
> że owa architektura nie ma wad o których pisałem.

Bo nie ma.
Ty potrzebujesz innej architektury, bo masz inne wymagania i ja to szanuję.

> Dobrze. Czy myślisz, że wystarczy w sklepie pokroju żabki,

(...)

> Pierwsze sklepy już gdzieś tam się pojawiają. Co będzie za 5-10 lat?

Będę się martwił za 5-10 lat.
Albo jak franczyzobiorca z Żabki przyjdzie i powie, że ma 100 kilo
klientów na godzinę.

> A może chciałbyś mieć dane o pozycji klienta z telefonem w czasie
> rzeczywistym poprzez urządzenia IoT, by serwować mu dopasowany content
> w sklepie? Albo sterować urządzeniami domowymi/firmowymi w reakcji
> na zdarzenia rzeczywiste?

Zapewne 3 mln osób prowadzących jednoosobową działalność gospodarczą o
tym marzy co wieczór.
Franczyzobiorcy Żabek nie mogą spać po nocach z tego powodu.

>>> Dlaczego google używa baz nierelacyjnych do swoich wyszukiwarek (bigtable)
>>> https://cloud.google.com/bigtable/
>>
>> Bo takich potrzebuje.
>
> Ale dlaczego potrzebuje?

Bo ma takie potrzeby.

> Czyż nie jest wydajniej mieć monolityczny
> serwer z triggerami i wszystko "w jednej maszynie"?

Dla google pewnie nie jest wydajniej.

> Takie można odnieść
> wrażenie po tym jak zachwalałeś triggery oraz ich optymalność.

Za Twoje wrażenia nie odpowiadam. Nie przypominam sobie, żebym gdzieś
napisał, że dla google triggery są fajne.

> Weź takie obciążenie np. na black friday. Ja dostawię 3-4, 10, 15 maszyn
> i się wyrobię.

Nie wątpię, że w Żabkach też dostawiają 15 maszyn.

> A jaką Ty masz wizję?

Nie wiewam wizji. Trzymam się twardo rzeczywistości.

>>> 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.
>
> Właśnie odwrotnie. Tam *gdzie nie musisz* żyłować wydajności pojedynczej
> maszyny,

Ale wiesz, że współczesne maszyny, to nie to samo co maszyny z lat 90-tych?
Jedna da radę ogarnąć wiele Żabek i nie klęknie.

>> 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.
>
> Ale (poza desktopami), to wszyscy chyba się przerzucili z triggerów/sp,
> na inplementacje w aplikacjach. Nie tylko Amazon i Google.

Skoro piszesz, że wszyscy, to wszyscy. Nie mam powodów Ci nie wierzyć.

>> 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.
>
> Oczywiście że ma i będzie (bo apetyt na dane rośnie). Zobacz sobei IoT,
> ML, segmenty Big Data.

3 mln jednoosobowych działalności gospodarczych to faktycznie spory
segment zainteresowany Big Data. Firmy które zatrudniają po kilka,
kilkadziesiąt osób też pewnie dostają wypieki na twarzy na hasło Big
Data i na możliwość korzystania z pierdyliarda skalowalnych w szerz baz
danych w chmurze.
No i nie wolno zapominać o franczyzobiorcach z Żabki i Jessice
wrzucającej posty o kotkach na swoim blogu.

> A tak swoją drogą, to zauważ, że te wszystkie klasyczne aplikacje księgowe
> o których mówisz "ostały się" głównie w większych przedsiębiorstwach,
> bo tam koszty zmian są znaczące, a ludzie do tych systemów są już
> przyzwyczajeni i przeszkoleni.

No tak. Bo teraz każda osoba prowadząca działalność gospodarczą rozlicza
podatki i wystawia faktury w chmurze.
Tylko te duże firmy takie zacofane są.

Ale zaraz, skoro te duże firmy takie zacofane, to kto korzysta z tych
skalowalnych w szerz serwerów? Pewnie te wszystkie mikro i małe
przedsiębiorstwa nie są w stanie bez tego funkcjonować.

> Ale w takim sektorze mikro-przedsiębiorstw, jedno-osobowych DG,
> zamiast instalowanej wypaśnie aplikacji z serwerem bazy masz coraz
> bardziej popularne serwisy typu infakt, wfirma, itp.

Nie wątpię, że są coraz popularniejsze i ktoś z tego korzysta.
Ja nie znam nikogo, kto by z tego korzystał, albo chociaż planował z
tego korzystać.

Nie zrozum mnie źle, nie twierdzę, że są to złe rozwiązania.

> I już teraz te serwisy mają więcej możliwości niż desktopowe aplikacje
> będą miały kiedykolwiek (dla tej grupy). Masz więc i odczytywanie/procesowanie
> faktur z PDF (rozpoznawanie obrazów), masz automatyczne wysyłanie przypomnień
> na maila, integracje z allegro/ceneo/magazynami *różnych* sklepów po API,
> systemami płatności, bankami, wysyłaniem maili do klientów, zarządzaniem
> windykacją, automatycznym przeliczaniem kursów walut, CRM, aplikacje/wersje
> mobilne, automatyzacją wystawiania i wysyłka faktur seryjnych (Rachmistrz
> to już potrafi?)

Nie, nie potrafi. Rachmistrz nie potrafi wystawić nawet pojedynczej faktury.
Subiekt potrafi.

> i bardzo szybkie wprowadzanie nowinek dostępnych
> *u wszystkich na raz* (np. weryfikacja numerów VAT kontrahentów).

To Rachmistrz potrafi. Od dawna.
I wiele innych tego typu nowinek też potrafi od dawna. Łącznie z
większością wymienionych "nowinek" powyżej.

> I to wszystko
> dużo szybciej i taniej niż desktopowe wersje oferowały kiedykolwiek.

A szczytem możliwości tych całych wfirma itp. to KPiR i ewidencja
przychodów. Ani to szybsze, ani tańsze, o dzieleniu się dokumentacją o
pracownikach, finansową itd. z podmiotem zewnętrznym i wygodzie nie
wspominając. Wysyłkę jpk reklamują na stronach głównych jakby to był
przełom technologiczny na poziomie wysłania człowieka na Marsa.

Pozdrawiam
Piotr

[Wojciech Bancer]

On 2019-04-26, Kviat <Kviat> wrote:

[...]

>> On 2019-04-26, Kviat <Kviat> wrote:
>> A Ty jako kontr-przykład podajesz mi architekturę rodem z lat 90-tych,
>> intranetu i mówisz "u mnie działa". Jasne.
>
> Nic takiego nie podałem. Nie mam pojęcie dlaczego wymyśliłeś sobie
> architekturę rodem z lat 90-tych.

Bo wtedy taka zaczęła funkcjonować?

>> Pierwsze sklepy już gdzieś tam się pojawiają. Co będzie za 5-10 lat?
>
> Będę się martwił za 5-10 lat.
> Albo jak franczyzobiorca z Żabki przyjdzie i powie, że ma 100 kilo
> klientów na godzinę.

Nie 100 kilo klientów. 100k danych.
Bo sklepy chcą o klientach wiedzieć coraz więcej.

>> A może chciałbyś mieć dane o pozycji klienta z telefonem w czasie
>> rzeczywistym poprzez urządzenia IoT, by serwować mu dopasowany content
>> w sklepie? Albo sterować urządzeniami domowymi/firmowymi w reakcji
>> na zdarzenia rzeczywiste?
>
> Zapewne 3 mln osób prowadzących jednoosobową działalność gospodarczą o
> tym marzy co wieczór. Franczyzobiorcy Żabek nie mogą spać po nocach
> z tego powodu.

Najpierw mówisz, że szanujesz moje pogląday, a zaraz próbujesz wciskać
mi coś czego nie powiedziałem i z tego szydzić. Ładnie tak?

>> Czyż nie jest wydajniej mieć monolityczny
>> serwer z triggerami i wszystko "w jednej maszynie"?
>
> Dla google pewnie nie jest wydajniej.

Ale Ty powiedziałeś, że trigger jest wydajniejszym rozwiązaniem,
bo jest bliżej danych. No to jest, czy nie jest?

>> Takie można odnieść
>> wrażenie po tym jak zachwalałeś triggery oraz ich optymalność.
>
> Za Twoje wrażenia nie odpowiadam. Nie przypominam sobie, żebym gdzieś
> napisał, że dla google triggery są fajne.

Ja napisałem, że triggery są mniej wydajne bo się nie skalują "w bok".
Tylko tyle. Informacja o skalowaniu była chyba jasną wskazówką o jakim
rodzaju wydajności mowa.

>> Weź takie obciążenie np. na black friday. Ja dostawię 3-4, 10, 15 maszyn
>> i się wyrobię. Nie wątpię, że w Żabkach też dostawiają 15 maszyn.

A jak to robią, to co?
A jak zaczną mieć takie potrzeby, to co?
Przepisujemy wszystko?

>> A jaką Ty masz wizję?
> Nie wiewam wizji. Trzymam się twardo rzeczywistości.

Tak, czepiaj się słówek zamiast pisać o merytoryce,
czyli o wydajności rozwiązań.

>>>> 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.
>>
>> Właśnie odwrotnie. Tam *gdzie nie musisz* żyłować wydajności pojedynczej
>> maszyny,
>
> Ale wiesz, że współczesne maszyny, to nie to samo co maszyny z lat 90-tych?

Wiem. A mimo to potrzeby w zakresie przetwarzania danych rosną szybciej
niż następuje rozwój sprzętu.

> Jedna da radę ogarnąć wiele Żabek i nie klęknie.

Więc Ci tłumaczę, że to zależy "co" taka pojedyncza Żabka miałaby
robić. Jak zacznie się ruch z IoT i próba analizy takich danych, to nie
utrzyma i klęknie.

>>> 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.
>>
>> Oczywiście że ma i będzie (bo apetyt na dane rośnie). Zobacz sobei IoT,
>> ML, segmenty Big Data.
>
> 3 mln jednoosobowych działalności gospodarczych to faktycznie spory
> segment zainteresowany Big Data.

https://sjp.pwn.pl/sjp/przyklad;2512135.html
Ale tak, nawet te małe firmy korzystają z big data, jak angażują się w reklamy
Ad Sense, czy na Facebooku.

> Firmy które zatrudniają po kilka, kilkadziesiąt osób też pewnie dostają wypieki
> na twarzy na hasło Big Data i na możliwość korzystania z pierdyliarda skalowalnych
> w szerz baz danych w chmurze.

Jasne. W końcu żadna z firm nie korzysta z Google Analytics, czy Google Maps,
Gmaila. Każda ma własną infrastrukturę pocztową z administratorem, to przecież
jasne. Jak chcesz sprowadzać dyskusję do docinków, to sobie daruj.
Po prostu napisz, że nie chcesz więcej dyskutować.

>> A tak swoją drogą, to zauważ, że te wszystkie klasyczne aplikacje księgowe

>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

>> o których mówisz "ostały się" głównie w większych przedsiębiorstwach,
>> bo tam koszty zmian są znaczące, a ludzie do tych systemów są już
>> przyzwyczajeni i przeszkoleni.
>
> No tak. Bo teraz każda osoba prowadząca działalność gospodarczą rozlicza
> podatki i wystawia faktury w chmurze.
> Tylko te duże firmy takie zacofane są.

Nie firmy, a aplikacje księgowe, podkreśliłem.

> Ale zaraz, skoro te duże firmy takie zacofane, to kto korzysta z tych
> skalowalnych w szerz serwerów? Pewnie te wszystkie mikro i małe
> przedsiębiorstwa nie są w stanie bez tego funkcjonować.

Błąd logiczny. To że firmy korzystają z pewnych rozwiązań legacy (bo
im się nie opłaca jeszcze tego przenosić), nie oznacza że na innym polu,
nie są w stanie być innowacyjne (zwłaszcza na polu gdzie nie ma systemów
legacy).

Ale patrz, z pocztą sporo firm (i to dużych) się przeniosło.
Do gmaila, do outlooka. Gmail jest najpopularniejszym dostawcą
poczty, także tej biznesowej.

>> Ale w takim sektorze mikro-przedsiębiorstw, jedno-osobowych DG,
>> zamiast instalowanej wypaśnie aplikacji z serwerem bazy masz coraz
>> bardziej popularne serwisy typu infakt, wfirma, itp.
>
> Nie wątpię, że są coraz popularniejsze i ktoś z tego korzysta.
> Ja nie znam nikogo, kto by z tego korzystał, albo chociaż planował z
> tego korzystać.

No oczywiście, że nie znasz. :)
https://www.infakt.pl/blog-ksiegowy/14-statystyk-ksiegowosc-2018/

---
Księgowość przechodzi do internetu i smartfonów

O jakiej rewolucji technologicznej mówimy? Warto wskazać przede
wszystkim na dostępność usług księgowych “w chmurze”, w tym za
pośrednictwem smartfonów. Co istotne, usługi finansowe mogą
dzisiaj ze sobą płynnie “rozmawiać”, czego doskonałym przykładem
są szybkie płatności zintegrowane z fakturami kosztowymi
i obliczonymi kwotami podatków oraz ZUS-u.

Druga kwestia to stopniowo postępująca automatyzacja zadań
z wykorzystaniem algorytmów machine learning. Tutaj przykładem
może być “rozczytywanie” danych z dokumentów kosztowych, co niezwykle
przyspiesza księgowanie.

[...]

1. 67% księgowych wybiera księgowość “w chmurze”
Zdecydowana większość księgowych widzi świetlaną przyszłość w księgowości
online i docenia jej zalety, np. dostępność na dowolnym urządzeniu. Tak
wynika z raportu Sage, “The Practice of Now”, będącego wynikiem badania
3000 księgowych.
---

Ale oczywiście, proszę o kontrę z argumentem, że trend jest
jednak odwrotny.

> Nie zrozum mnie źle, nie twierdzę, że są to złe rozwiązania.

To po co te wyzłośliwianie się? Nie widzisz trendu, czy po prostu
w jakiś sposób Cię uraziło, że o Desktopie mówię "legacy"? Przecież
to też jest trend, który postępuje (przechodzenie w coraz większym
stopniu "do chmury").

Spotify, netflix, legimi, office (często firmom wystarczy już to
co oferuje docs.google.com), poczta, księgowość. Można już pograć
"w streamie" (nie zawsze z sukcesem). Lokalny komputer to coraz
częściej tylko końcówka do internetu i niewiele więcej.

>> I już teraz te serwisy mają więcej możliwości niż desktopowe aplikacje
>> będą miały kiedykolwiek (dla tej grupy). Masz więc i odczytywanie/procesowanie
>> faktur z PDF (rozpoznawanie obrazów), masz automatyczne wysyłanie przypomnień
>> na maila, integracje z allegro/ceneo/magazynami *różnych* sklepów po API,
>> systemami płatności, bankami, wysyłaniem maili do klientów, zarządzaniem
>> windykacją, automatycznym przeliczaniem kursów walut, CRM, aplikacje/wersje
>> mobilne, automatyzacją wystawiania i wysyłka faktur seryjnych (Rachmistrz
>> to już potrafi?)
>
> Nie, nie potrafi. Rachmistrz nie potrafi wystawić nawet pojedynczej faktury.
> Subiekt potrafi.

A no tak, trzeba kupić 2 programy i je integrować po bazie :)

>> i bardzo szybkie wprowadzanie nowinek dostępnych
>> *u wszystkich na raz* (np. weryfikacja numerów VAT kontrahentów).
>
> To Rachmistrz potrafi. Od dawna.
> I wiele innych tego typu nowinek też potrafi od dawna. Łącznie z
> większością wymienionych "nowinek" powyżej.

No kurcze, mam rachmistrza gt pod ręką (nie mój) i nie widzę tego importu
z banku, czy sprawdzenia stanu płatności online. Trzeba dokupić?

Przydałoby się też rozpoznawanie obrazów. A jak już dodaję ten wydatek
ręcznie, to nie mam tutaj wyboru waluty, więc i to muszę ręcznie
przeliczyć. A i danych w Euro nie wprowadzę, tylko muszę chyba przeliczyć
na złotówki (albo nie widzę jak).

>> I to wszystko
>> dużo szybciej i taniej niż desktopowe wersje oferowały kiedykolwiek.
>
> A szczytem możliwości tych całych wfirma itp. to KPiR i ewidencja
> przychodów.

No Ewidencje sprzedaży też widziałem. No i potrafi z EUR sam przeliczyć,
wysłać deklarację do ZUS i US, ogarnia sam JPK itp.

> Ani to szybsze, ani tańsze,

To ile kosztuje taki zestaw typu KPiR, te podstawowe kadry (no niech mi UZ rozliczy, albo UD),
i wystawianie faktur? Tak razem i rocznie? Czy może aktualizacje są bezpłatne?
Jedna licencja wystarczy, ale może da się z dostępem zdalnym (w końcu nie zawsze z domu
chcę wystawić FV).

> o dzieleniu się dokumentacją o pracownikach, finansową itd.

Wiesz, tylko jak przestałem z rachmistrza (bezpośrednio) korzystać chyba w 2014 roku,
tak nadal regularnie z Insertu do mnie dzwonią i pytają, czy może bym czegoś okazyjnie
nie kupił, albo może jednak skusił się na e-abonament do tego rachmistrza, co to już
wieki nie używam. I mimo próśb o zaprzestanie, no niestety...

A nieraz dzwonili z jakimiś "okazyjnymi" pierdołami w ogóle nie związanymi
z księgowością.

> z podmiotem zewnętrznym

No tak. Wszyscy wiemy jak wygodne są programy księgowe pod Windows.

> i wygodzie nie wspominając.

Wspomnij, ciekaw jestem. :)

--
Wojciech Bańcer
wojciec...@gmail.com

[Wojciech Bancer]

On 2019-04-26, Borys Pogoreło <bo...@pl.edu.leszno> wrote:

[...]

>> Pierwsze sklepy już gdzieś tam się pojawiają. Co będzie za 5-10 lat?
>> A może chciałbyś mieć dane o pozycji klienta z telefonem w czasie
>> rzeczywistym poprzez urządzenia IoT, by serwować mu dopasowany content
>> w sklepie? Albo sterować urządzeniami domowymi/firmowymi w reakcji
>> na zdarzenia rzeczywiste?
>
> Ale to nie są zadania dla triggerów czy procedur, skoro już o tym mowa.

Ale co konkretnie? Ja pokazuję przykłady zastosowań w których wykorzystujemy
bazy danych.

>> Ale dlaczego potrzebuje? Czyż nie jest wydajniej mieć monolityczny
>> serwer z triggerami i wszystko "w jednej maszynie"? Takie można odnieść
>> wrażenie po tym jak zachwalałeś triggery oraz ich optymalność.
>
> Zjedź z przykładami z top 10 światowego internetu, bo to trochę mało
> reprezentatywne. Inna skala, inne problemy.

https://www.forbes.pl/technologie/jak-wiele-danych-produkujemy-kazdego-dnia/4mn4w69

> Choć może weźmy przykład takiego Instagrama, powinien pasować
> do załozonej przez Ciebie skali. Ich bazy korzystają z procedur PL/PGSQL
> do generowania unikalnych i bezkolizyjnych identyfikatorów. Bo tak było prościej,
> niż dopisywać i utrzymywać kolejną dedykowaną usługę.

I korzystają też s Cassandry i redisa, żeby było szybciej.
Twitter korzystał z mysql, a korzysta z Cassandry, bo ten pierwszy
nie wyrobił.

>> Jeszcze. Ale odpowiedzialne projektowanie *aplikacji webowej* musi
>> przewidywać pewien rozwój sytuacji. Inaczej będziesz jak nasza klasa
>> i pan gąbka z błędem typu error 500.
>
> To jest przypadek skrajny, zupełnie oderwany od rzeczywistości. Ile znasz
> innych serwisów, które odniosły tak gwałtowny sukces (i jednocześnie tak
> bardzo położyły temat od strony technicznej)?

To jest oczywiście tylko przykład.
Moim podstawowym argumentem dla "małej skali" jest nadal łatwiejsze skalowanie
aplikacji webowych niż db. Skalowanie DB wymaga dużo więcej pracy i wiedzy,
do skalowania aplikacji często wystarczy wprowadzenie.

>> O ile *koszt* projektowania aplikacji w jeden i drugi sposób jest podobny,
>
> Co najwyżej w średnich i dużych firmach IT, w których siedzą ludzie znający
> się na wielu rzeczach, a cena dla klienta końcowego jest i tak za
> roboczogodzinę. A wydaje mi się, że cały czas piszesz z takiej właśnie
> perspektywy, firmy tworzącej rozwiązania dla dużych klientów, których stać
> na wdrożenie za kwoty sześciocyfrowe i większe.

A o jakich projektach mam pisać? O wdrożeniu gotowego wordpressa,
czy prestashop?

> Pomijasz za to ogromną rzeszę mniejszych firm, których potrzeby są na tyle
> niskie, że "typowe" rozwiązania są dla nich wytarczające z dużym zapasem.

Takie firmy zazwyczaj korzystają z gotowych rozwiazań, a nie piszą własne.

[...]

>> Mniejszy jest też koszt optymalizacji konkretnych bottlenecków "na aplikacji"
>> niż na bazie (bo masz mnóstwo alternatyw od zapewnienia cache w pamięci,
>> rozładowania ruchu poprzez load balancery, kontroli że np. pojedynczy
>> użytkownik nie może wykonać > 10 żądań na sekundę (throttling pattern),
>> tworzenia kolejek i priorytetów (a nie wyłącznie obsługi fifo).
>>
>> a to wszystko możesz stosować na różnych poziomach infrastruktury,
>> połączonej w logiczną strukturę z aplikacją (podejście IaaC) i zebrane
>> w jednym logicznym miejscu.
>
> Brzmi pięknie i zgodnie ze sztuką, ale dodaj jeszcze ile kostuje stworzenie
> takiej aplikacji i utrzymanie na takiej infrastrukturze. Ile jest firm,
> które tego potrzebują i za to zapłacą?

Duże? Coraz częściej. Małe? One *przechodzą* do usług, albo kupują gotowce.
Nie kupują już aplikacji na desktop, tylko subskrybcję. Nie stawiasz lokalnego
serwera poczty. Firmy gromadzą dzisiaj o wiele więcej danych, dużo taniej,
bo tego typu integracje stały się możliwe i tańsze.

A jak poczytasz o problemach wydajnościowych cokolwiek większych wdrożeń,
to zawsze i nieodmiennie jest to związane z bazą danych.

>> I już teraz te serwisy mają więcej możliwości niż desktopowe aplikacje
>> będą miały kiedykolwiek (dla tej grupy). (...)
> Co nie znaczy, że z tyłu nie stoi jakiś SQL napędzany procedurami.

Jeden przypadek znam i wiem że nie korzystają.

I jeszcze kolejny kamyczek do ogródka:

https://www.itprotoday.com/development-techniques-and-management/reasons-avoid-triggers

I moja praktyka to też potwierdza. I tak, miałem już do czynienia z dużą
ilością aplikacji w której analizując przyczyny bottlenecków, znajdowałem radosne
triggery, które ktoś włożył bo "założył", że będą szybsze, a to właśnie one kładły
serwery, nawet przy (wydawałoby się) prostych taskach.

Tak, masz rację że przy wielu zastosowaniach "jeden serwer wystarczy",
ale uważam, że łatwiej położyć ten serwer nieoptymalnym triggerem
(bo ludzie w małych wdrożeniach "nie widzą" i nie wiedzą jak
analizować takie problemy) niż nieoptymalną aplikacją. To drugie
łatwiej też zobaczyć, zanalizować i poprawić.

--
Wojciech Bańcer
wojciec...@gmail.com

[Marek S]

W dniu 2019-04-26 o 01:50, Borys Pogoreło pisze:

> Aż tak często usuwasz rekordy w bazie by miało to jakiekolwiek wymierne
> znaczenie, kosztem przejrzystości kodu?

Zależy od zlecenia. W ostatnim do 750000+ (a i 2x tyle się od czasu do
czasu zdarzało) w ciągu kilku nocnych godzin, każdego dnia. W innym
kilkadziesiąt na rok. W jeszcze innym X a kolejnym Y.

> Już się zdecydowałeś na ORM i związane z nim kompromisy, w tym spory narzut
> między modelem a bazą. A jeszcze niedawno tak narzekałeś na ideę Query
> Buildera.

Bo idea mi się nadal średnio podoba. Dużo lepszy jest sparametryzowany
raw SQL. Nie pamiętam czy uzasadniałem więc to zrobię:

- nie posiada niepotrzebnych aliasów typu ->delete() standardowych
elementów SQL'a - nie trzeba uczyć się 2x SQLa
- można w nim używać dowolnych dialektów SQL
- wygodna parametryzacja, która czyni SQL czytelnym (np. :id w miejscu
ID usera)
- tam, gdzie nie ma krytycznych wydajnościowo fragmentów aplikacji,
nadal można korzystać w tradycyjny sposób z ORM np. przy obsłudze
formularzy, gdzie pani Krysia z pewnością nie wklepie 750000 danych w
parę godzin.

>
>> Jak dla mnie podejście "bo tak działa ORM" jest równoznaczne z "jestem
>> leniem informatyki i mam gdzieś wydajność nawet gdy to tylko 3 linijki
>> kodu". Sam mi pokazałeś jak łatwo naprawić te błędy założeń ORM.
>
> Dlaczego tak autorytatywnie uważasz, że to są błędy?

Autorytatywnie... nie wiem czy to dobre określenie. To moje prywatne
zdanie. Otóż wychodzę z założenia, że nawet jeśli pracujemy przy małym
projekcie, to powinniśmy dbać o wydajność wszystkiego, co robimy. Na ile
się oczywiście da w małym projekcie. A już w szczególności należy
wystrzegać się randomowych zapytań do bazy danych, których wyniki w
ogóle nas nie interesują. Gdyby nie ten fakt, z pewnością mocno
zmieniłbym swoją opinię na temat ORM.

Zapewne mieszkając w domu chciałbyś aby włącznik światła w salonie
zwyczajnie realizował swoją funkcję. Zapewne byłbyś średnio zadowolony,
gdybyś musiał najpierw spuścić wodę w kiblu aby móc zapalić światło w
salonie. Tymczasem takie właśnie zachowanie fundujesz aplikacji / bazie
danych używając ORM. Nawiązuję do DELETE / UPDATE + niepotrzebny SELECT.
Idea jest super, ale realizacja fatalna dla tych dwóch przypadków.

Kolejną rzeczą ORM, którą rozumiem ale nie popieram to równanie w dół.
ORM ma za zadanie supportować ileś tam baz danych. Jeśli jakaś potrafi
cioś więcej niż jakakolwiek inna - wyrzucamy to coś. W konsekwencji
zostaje prymitywny SQL do dyspozycji tegoż ORM'a. W Doctrine nawet
zwykły Enum to wyzwanie - trzeba doinstalowywać bundle (!!!) ... o ile
nie korzystamy z MySQL (widocznie ta baza budzi sentyment u developerów
Doctrine).

Zwróć uwagę, że developerzy baz danych dwoją się i troją wprowadzając
przeróżne unowocześnienia. A potem po tym wszystkim przejeżdża walec z
numerami rejestracyjnymi: ORM. To też mi się nie podoba. Czyli zostaje
cofnąć technologię baz do lat 90-tych?

Wydaje mi się, że ORMy powinny przejść modernizację do standardu,
nazwijmy 2.0. Idea słuszna, ale wymagane jest rozwiązanie w/w kwestii.

--
Pozdrawiam,
Marek

[Marek S]

W dniu 2019-04-26 o 09:32, Wojciech Bancer pisze:

>> BTW
>> Jak tworzysz podkreślenia? Próbowałem _ przed i za, próbowałem __ i
>> kiszka. Być może więcej wyrazowych wyrażeniach próbowałem. Nie pamiętam już.
>
> Przez dodanie _ na początku i na końcu wyrazu (bez spacji).

Sprawdzam:
_test_
_dwa wyrazy_
_dwa_wyrazy_
_dwa-wyrazy_

> Wygląda jak klasyczna niepotrzebna optymalizacja.
> Zamieniasz też " na ', żeby zyskać 2 sekundy czasu serwera w rok?

Nie, wcale nie 2 sekundy. Pisałem wcześniej, że przy ok pół miliona
operacji (w ciągu nocy) udało mi się zaoszczędzić 2h pracy serwera
(50%). Może nawet więcej. Nie pamiętam konkretnych liczb.

A cała sprawa wzięła się stąd, że gdy parę lat temu, gdy system był
tworzony, nie przewidywano takiego sukcesu firmy. Informatycy wychodzili
dokładnie z tego samego założenia co Ty, że dla tych 10k operacji nie
będą "nadmiernie" optymalizować. A potem, zaledwie po kilku latach
obudzili się z ręką w nocniku: ojej... system się nie wyrabia przy 500k.
Mało tego... zaczęły zdarzać się upadki bazy bo Ci sami informatycy
założyli, że im więcej RAMu przydzielą w Postgresie na proces, tym,
lepiej. Rano ludzie przychodzą do pracy a tu nic nie działa bo na bazie
trwają niesłychane prace lub w ogóle leży.

Gdyby Ci informatycy wzięli się za uczciwą robotę i nawet dla
niewielkiego początkowo przedsięwzięcia postąpili zgodnie z kunsztem
programowania zwracając uwagę na detale, to problem wystąpiłby dopiero
po dojściu do możliwości serwera a nie możliwości kiepskich algorytmów.

> Wszysktie? Nie. Nadmiarowe, stworzone "na wszelki wypadek"? Tak.
> To co robisz nosi wszelkie znamiona premature optimization i unnecessary
> optimization. Niby jest wydajnej, ale różnicy nikt tak realnie nie zobaczy,
> a Ty tracisz na tym czas.

Czytaj powyżej.
Za moją "stratę czasu" dostałem niezłą kasę bo skończyły się w/w
problemy. Argument kasy mnie przekonuje dodatkowo do słuszności podejścia.

Co do w/w optymalizacji, to faktycznie praca była mrówcza. Np. zamiast
indeksować całe pole typu array() należało rozbić indeks na dwa:
przeindeksować tylko część tablicy - bo okazało się, że zdecydowana
większość zapytań właśnie o te części pytała. Podobnie było z
zapytaniami SQL. Zamiast jakiejś tam konstrukcji zastosowano inną i znów
progress wydajnościowy. Tymczasem od początku można było zrobić to
dobrze...

Zarobiłem na partactwie innych... Gdyby mieli tam ORMa, to po zdobyciu
jego podstaw... zacząłem mieć wątpliwości czy w ogóle dałoby się
cokolwiek uratować w w/w projekcie.

> Query builder *nie* jest żadnym łataniem, ani też żadnym SQLem.
> Jest narzędziem do budowania zapytań.
> Jak chciałbyś odpytywać bazę inaczej?

Raw SQL? Doctrine ma implementację czegoś takiego.

> Nie wszystko na bazie sprowadza się do robienia pojedynczych zapytań
> i działania na pojedynczych obiektach.
>

Raw SQL ma JOINy od wieków.

> No nie. Query builder zbuduje zapytanie DQL:
> https://www.doctrine-project.org/projects/doctrine-orm/en/2.6/reference/dql-doctrine-query-language.html

...i baza to zrozumie? Nie sądzę. Zawsze na końcu będzie SQL. Resztę
wypowiedzi dopiszę poniżej.

>
> Uwalnie Ciebie od znajomości struktury (nazw kolumn kluczy, nazw tabeli),
> bo sam to ogarnia na podstawie otworzonej przez Ciebie relacji z obiektami
> Entities.
>
> A potem ten DQL zostanie przetworzony na coś w stylu:
> DELETE FROM services s WHERE s.project_id = " . $project->getId(); // jeśli $project to obiekt
> DELETE FROM services s WHERE s.project_id = " . $project; // jeśli $project to prymityw (liczba lub string)

Czy to nie ja zadałem pytanie czy na wyjściu dostaniemy:
"DELETE FROM services s WHERE s.project=$project" ? :-D

Jakoś dostrzegam w tym podobieństwo :-D

> ale już bez Twojego udziału.
> Ale tak g gdzieś ostatecznie pod spodem jest wynik w postaci SQL.
> Przecież musi być, bazy danych inaczej nie gadają.

Właśnie! Kłopot jest jednak w tym, że zapytanie SQL jakie z tego się
urodzi może (nie musi) wołać o pomstę do nieba. Tak jak to było przy
UPDATE/DELETE. Nie twierdzę, bo jeszcze nie mam praktyki, ale flamastrem
na tablicy napisałbym sobie tą rzecz jako wymagającą detalicznych
obserwacji przy tworzeniu projektów by uniknąć wpadek.

> Zauważ, że:
> - nie znasz tej nazwy tabeli (doctrine sam ją "ogarnia"
> na podstawie tego jak zdefiniowałeś entity)
> - do $project wstawiasz obiekt entity lub id, a doctrine
> sam sobie poradzi z tym by to miało dla niego sens
> sam też zna nazwę kolumny, na podstawie relacji jaka
> była utworzona w entity

Tego nie musisz pisać. Ja to wiem i doceniam usprawnienie lecz w
nielicznych / licznych / bardzo licznych przypadkach może stać się
kamieniem u szyi.

Ja nie mogę powiedzieć klientowi: to nie ja spierniczyłem, to
Querybuilder dodał gratisa od siebie w postaci mega-nieoptymalnej
struktury. A indeksy w bazie? Po co to komu! Niech ORM sobie je ogarnia.

Jakbym dostał to takim komentarzu dyscyplinarkę, to wcale bym nie był
zdziwiony.

--
Pozdrawiam,
Marek

[Kviat]

W dniu 26.04.2019 o 22:26, Wojciech Bancer pisze:

> On 2019-04-26, Kviat <Kviat> wrote:
>

>>> Czyż nie jest wydajniej mieć monolityczny
>>> serwer z triggerami i wszystko "w jednej maszynie"?
>>
>> Dla google pewnie nie jest wydajniej.
>
> Ale Ty powiedziałeś, że trigger jest wydajniejszym rozwiązaniem,
> bo jest bliżej danych. No to jest, czy nie jest?

"Architektura oparta o ORM (i zdarzenia),
może i jest jednostkowo wolniejsza,

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

ale w razie potrzeby w łatwy sposób zostać rozbudowana "w bok","

Od dłuższego czasu próbuję Ci wytłumaczyć, że jest wydajniejszym
rozwiązaniem dla kogoś, kto nie ma potrzeby skalowalności "w bok".
A Ty mnie próbujesz przekonać, że wszyscy mają taką potrzebę i już.

>>> Weź takie obciążenie np. na black friday. Ja dostawię 3-4, 10, 15 maszyn
>>> i się wyrobię. Nie wątpię, że w Żabkach też dostawiają 15 maszyn.
>
> A jak to robią, to co?
> A jak zaczną mieć takie potrzeby, to co?
> Przepisujemy wszystko?

https://www.wiadomoscihandlowe.pl/artykuly/zabka-oferta-franczyzowa,41676
"ŚREDNIA POWIERZCHNIA SPRZEDAŻY SKLEPU: 61 mkw."

Poważnie uważasz, że franczyzobiorca Żabki będzie miał w przyszłości
potrzebę na "dane o pozycji klienta z telefonem w czasie rzeczywistym

poprzez urządzenia IoT, by serwować mu dopasowany content w sklepie"?

Sklep ma 6x10m...
Nie wątpię, że za jakiś czas dokładność GPS w telefonie wzrośnie do 1
cm, ale mimo tego nie będzie wiedział, czy klient przystanął przy
proszku do prania, żelkach, czy maszynie do hot-dogów.

>>>> 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.
>>>
>>> Oczywiście że ma i będzie (bo apetyt na dane rośnie). Zobacz sobei IoT,
>>> ML, segmenty Big Data.
>>
>> 3 mln jednoosobowych działalności gospodarczych to faktycznie spory
>> segment zainteresowany Big Data.
>
> https://sjp.pwn.pl/sjp/przyklad;2512135.html

?

> Ale tak, nawet te małe firmy korzystają z big data, jak angażują się w reklamy
> Ad Sense, czy na Facebooku.

Że co?
Żeby wrzucić reklamę na fejsa muszę mieć "skalowalny wszerz" serwer?

>> Firmy które zatrudniają po kilka, kilkadziesiąt osób też pewnie dostają wypieki
>> na twarzy na hasło Big Data i na możliwość korzystania z pierdyliarda skalowalnych
>> w szerz baz danych w chmurze.
>
> Jasne. W końcu żadna z firm nie korzysta z Google Analytics, czy Google Maps,
> Gmaila.

I dlatego każda z tych firm, żeby skorzystać z Google Maps albo wysłać
maila przez Gmaila musi mieć "skalowalny wszerz" serwer.

> Każda ma własną infrastrukturę pocztową z administratorem, to przecież
> jasne. Jak chcesz sprowadzać dyskusję do docinków, to sobie daruj.

Powyższe argumenty przekonały mnie, że faktycznie najwyższy czas
zakończyć dyskusję.

Pozdrawiam
Piotr

[Wojciech Bancer]

On 2019-04-27, Kviat <Kviat> wrote:

[...]

>>>> Czyż nie jest wydajniej mieć monolityczny
>>>> serwer z triggerami i wszystko "w jednej maszynie"?
>>>
>>> Dla google pewnie nie jest wydajniej.
>>
>> Ale Ty powiedziałeś, że trigger jest wydajniejszym rozwiązaniem,
>> bo jest bliżej danych. No to jest, czy nie jest?
>
> "Architektura oparta o ORM (i zdarzenia),
> może i jest jednostkowo wolniejsza,
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> ale w razie potrzeby w łatwy sposób zostać rozbudowana "w bok","
>
> Od dłuższego czasu próbuję Ci wytłumaczyć, że jest wydajniejszym
> rozwiązaniem dla kogoś,

Czy to w jakiś sposób unieważnia moje stwierdzenie (które podkreśliłeś)?
Nie. Przyjąłem twój argument do wiadomości, ale pokazuję jakie są obecnie
*trendy* które przemawiają za tym by być ostrożnym z takim pewnym siebie
szafowaniem "nie potrzebuję <tup>!".

> kto nie ma potrzeby skalowalności "w bok".
> A Ty mnie próbujesz przekonać, że wszyscy mają taką potrzebę i już.

Nie. Próbuję powiedzieć, że *mogą* i należy projektować rozsądnie,
a nie tam "gdzie najprościej" i po najmniejszej linii oporu. I chcę
Ci pokazać, że rynek bardzo dynamicznie idzie w tą stronę. A Ty
się niepotrzebnie wyzłośliwiasz.

Ludzie też mogą pisać w php korzystając ze "spaghetti code" i pisząc
w noatniku. Ale to nie znaczy że takie coś jest właściwe, biorąc pod
uwagę istniejące trendy i przewidywalną przyszłość.

[...]

> Poważnie uważasz, że franczyzobiorca Żabki będzie miał w przyszłości
> potrzebę na "dane o pozycji klienta z telefonem w czasie rzeczywistym
> poprzez urządzenia IoT, by serwować mu dopasowany content w sklepie"?
> Sklep ma 6x10m...

No właśnie tak. Bo to zmierza do całkowitej automatyzacji sprzedaży
i pozbycia się potrzeby posiadania kasjerów. O proszę, masz tu:

https://gloswielkopolski.pl/bio-family-poznan-pierwszy-bezobslugowy-supermarket-w-polsce-bedzie-czynny-w-kazda-niedziele/ar/13563136
https://epoznan.pl/news-news-91804-Zabka_chce_otwierac_automatyczne_sklepy_bez_tradycyjnych_kas

To jest coś co się *już* dzieje, ale nie na masową skalę, bo właśnie
trzeba systemy dopasować do takiej wydajności.

>>>> Oczywiście że ma i będzie (bo apetyt na dane rośnie). Zobacz sobei IoT,
>>>> ML, segmenty Big Data.
>>>
>>> 3 mln jednoosobowych działalności gospodarczych to faktycznie spory
>>> segment zainteresowany Big Data.
>>
>> https://sjp.pwn.pl/sjp/przyklad;2512135.html
>
> ?

Podałem Ci _przykłady_ technologii które generują zapotrzebowanie na dane,
a ty mi walisz zgryźliwym komentarzem, że 3 mln jednoosobowych działalności
nie znajdzie tego zastosowania.

Więc po pierwsze podałem _przykład_, po drugie te 3 miliony _już korzysta_.
I im więcej usług będzie "migrowało" do chmury, tym bardziej architektura
będzie zmierzała w stronę działania na infrastrukturze wirtualnej i w modelu
który opisałem.

Takie usługi jak "cloud function" już teraz pozwalają Ci trzymać dużej
wielkości site dla małej firmy (np. coś w stylu: https://acloud.guru/
z możliwością skalowania na poziomie milionów i rocznymi kosztami użycia
na poziomie kilku dolarów.

I nie trzeba mieć firmy z Top 10 aby taką architekturę wdrożyć, tylko
architektra który rozumie co te technologie oferują.

>> Ale tak, nawet te małe firmy korzystają z big data, jak angażują się w reklamy
>> Ad Sense, czy na Facebooku.
>
> Że co?
> Żeby wrzucić reklamę na fejsa muszę mieć "skalowalny wszerz" serwer?

Tak. Nie "osobiście", ale owszem, do tego to zmierza (facebook musi mieć,
a jak nie facebook to taka platforma która umożliwi Ci analizę i obróbkę
danych które potem do tego facebooka wpuścisz).

Rynek zmierza do tego że możesz mieć stronę, aplikację i możliwości analityczne
*bez* inwestowania w serwery *o ile* potrafisz dopasować do tego architekturę.
I nagle jako mały przedsiębiorca nie musisz mieć serwera SQL, który kosztuje
X miesięcznie. Ani nawet serwera WWW, który kosztuje drugie tyle. Do swojej
strony możesz budować rozpoznawanie mowy, syntezator mowy, czy rozpoznawanie
obrazów bez inwestowania w farmę SQL, tylko poprzez wpięcie się do usługi.
Po API, a nie po bazie. Cloud otwiera się też na małe firmy, ale niesie
za sobą wymagania architektoniczne.

Oczywiście możesz się uprzeć i np. integrować "część rzeczy" na API,
część rzeczy "na triggerach" (wszystko wolno), ale to jest zwyczajnie
zły model projektowania (logika biznesowa rozproszona do tego stopnia,
że w końcu nie będzie wiaodomo jaki komponent odpowiada za co).

>>> Firmy które zatrudniają po kilka, kilkadziesiąt osób też pewnie dostają wypieki
>>> na twarzy na hasło Big Data i na możliwość korzystania z pierdyliarda skalowalnych
>>> w szerz baz danych w chmurze.
>>
>> Jasne. W końcu żadna z firm nie korzysta z Google Analytics, czy Google Maps,
>> Gmaila.
>
> I dlatego każda z tych firm, żeby skorzystać z Google Maps albo wysłać
> maila przez Gmaila musi mieć "skalowalny wszerz" serwer.

Widzę, że kompletnie nie rozumiesz o czym piszę.

To zmierza do tego by firma nie musiała mieć serwera.
Pod warunkiem, że masz odpowiednią architekture.

[...]

--
Wojciech Bańcer
wojciec...@gmail.com

[Kviat]

W dniu 27.04.2019 o 13:58, Wojciech Bancer pisze:

> On 2019-04-27, Kviat <Kviat> wrote:
>
> [...]
>
>>>>> Czyż nie jest wydajniej mieć monolityczny
>>>>> serwer z triggerami i wszystko "w jednej maszynie"?
>>>>
>>>> Dla google pewnie nie jest wydajniej.
>>>
>>> Ale Ty powiedziałeś, że trigger jest wydajniejszym rozwiązaniem,
>>> bo jest bliżej danych. No to jest, czy nie jest?
>>
>> "Architektura oparta o ORM (i zdarzenia),
>> może i jest jednostkowo wolniejsza,
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> ale w razie potrzeby w łatwy sposób zostać rozbudowana "w bok","
>>
>> Od dłuższego czasu próbuję Ci wytłumaczyć, że jest wydajniejszym
>> rozwiązaniem dla kogoś,
>
> Czy to w jakiś sposób unieważnia moje stwierdzenie (które podkreśliłeś)?

Wręcz przeciwnie.
Podkreśla to, co sam stwierdziłeś. Że w pewnym zakresie stosowalności
jest wolniejsza.

> Nie. Przyjąłem twój argument do wiadomości, ale pokazuję jakie są obecnie
> *trendy* które przemawiają za tym by być ostrożnym z takim pewnym siebie
> szafowaniem "nie potrzebuję <tup>!".

Nie przekonuje mnie argument, że skoro czegoś nie potrzebuję, to jednak
potrzebuję, bo jeszcze nie wiem, że potrzebuję albo nie wiem, że będę
potrzebował, bo są takie trendy <tup>.

>> kto nie ma potrzeby skalowalności "w bok".
>> A Ty mnie próbujesz przekonać, że wszyscy mają taką potrzebę i już.
>
> Nie. Próbuję powiedzieć, że *mogą* i należy projektować rozsądnie,
> a nie tam "gdzie najprościej" i po najmniejszej linii oporu. I chcę
> Ci pokazać, że rynek bardzo dynamicznie idzie w tą stronę.

Nie. Próbujesz powiedzieć, że skoro *mogę* mieć potrzebę latania
samolotem, to powinienem rozsądnie kupić samolot żeby już teraz jeździć
nim do pracy. Oczywiście nie namawiasz do kupna od razu gigantycznego
samolotu, tylko taki mały, skalowalny w szerz. To nie ważne, że do pracy
mam 5 km, ważne, że teraz jest taki trend.
Prościej, szybciej, taniej i *wydajniej* dojadę rowerem. A jak mi
łańcuch spadnie, to go sam założę, bez wynajmowania armii specjalistów
od zakładania łańcucha. A jak będę chciał przelecieć się samolotem, to
sobie kupię bilet na samolot.

> A Ty
> się niepotrzebnie wyzłośliwiasz.

Na poparcie swoich argumentów przytaczasz przykłady z Żabkami,
mikro-firmami itp., które tylko potwierdzają to co piszę i upierasz się,
że wszyscy oni potrzebują takich rozwiązań, których nie potrzebują.

>> Poważnie uważasz, że franczyzobiorca Żabki będzie miał w przyszłości
>> potrzebę na "dane o pozycji klienta z telefonem w czasie rzeczywistym
>> poprzez urządzenia IoT, by serwować mu dopasowany content w sklepie"?
>> Sklep ma 6x10m...
>
> No właśnie tak. Bo to zmierza do całkowitej automatyzacji sprzedaży
> i pozbycia się potrzeby posiadania kasjerów. O proszę, masz tu:

I jak tu się nie wyzłośliwiać skoro sam prowokujesz?
Do pomieszczenia 6x10m ilu wejdzie klientów równocześnie? 20? 30?
Średnio wypasiony współczesny smyrofon ma wystarczającą moc, żeby
obsłużyć taką automatyzację sprzedaży, łącznie ze śledzeniem w czasie
rzeczywistym przy której półce przystanął na dłużej klient.

> To jest coś co się *już* dzieje, ale nie na masową skalę, bo właśnie
> trzeba systemy dopasować do takiej wydajności.

Niektóre trzeba, niektórych nie trzeba.

> Podałem Ci _przykłady_ technologii które generują zapotrzebowanie na dane,
> a ty mi walisz zgryźliwym komentarzem, że 3 mln jednoosobowych działalności
> nie znajdzie tego zastosowania.

Bo nie znajdzie. To nie oni potrzebują tych rozwiązań o których piszesz,
tylko podmioty, które będą im świadczyć usługi. Takie jak Google,
Fejsbuk...

> Więc po pierwsze podałem _przykład_, po drugie te 3 miliony _już korzysta_.

Jak korzysta, skoro nie korzysta?
Mam kilku znajomych prowadzących jednoosobową działalność i żaden z nich
nie czuje potrzeby stawiania infrastruktury serwerowej w chmurze żeby
napisać posta na fejsbuku.

>>> Ale tak, nawet te małe firmy korzystają z big data, jak angażują się w reklamy
>>> Ad Sense, czy na Facebooku.
>>
>> Że co?
>> Żeby wrzucić reklamę na fejsa muszę mieć "skalowalny wszerz" serwer?
>
> Tak. Nie "osobiście", ale owszem, do tego to zmierza (facebook musi mieć,
> a jak nie facebook to taka platforma która umożliwi Ci analizę i obróbkę
> danych które potem do tego facebooka wpuścisz).

No nareszcie.

> Widzę, że kompletnie nie rozumiesz o czym piszę.

Wzajemnie.

Pozdrawiam
Piotr

[Wojciech Bancer]

On 2019-04-27, Kviat <Kviat> wrote:

[...]

> Nie przekonuje mnie argument, że skoro czegoś nie potrzebuję, to jednak
> potrzebuję, bo jeszcze nie wiem, że potrzebuję albo nie wiem, że będę
> potrzebował, bo są takie trendy <tup>.

Ale rozmawiamy na poziomie trendów, podejściu do programowania,
a nie pojedynczych potrzeb. Czy _teraz_, w 2019 roku, _nie wiedząc_
jaki będzie zakres stosowania danego rozwiązania, wielkość projektu,
potencjalne przyszłe zastosowania polecisz komuś pisanie w spaghetti
code? Czy _teraz_, w 2019 roku, _nie wiedząc_ jaki będzie zakres stosowania
danego rozwiązania, wielkość projektu, potecjalne przyszłe zastosowania,
plecisz komuś w ciemno optymalizację na triggery?

To co we własnym zakresie robisz samodzielnie, to Twój zakres, Twoja
odpowiedzialność, Twoja kasa. Ale czy polecisz w ciemno innej osobie?
Bo o takiej sytuacji mowa w sytuacji dyskusji na grupie.

[...]

>> No właśnie tak. Bo to zmierza do całkowitej automatyzacji sprzedaży
>> i pozbycia się potrzeby posiadania kasjerów. O proszę, masz tu:
>
> I jak tu się nie wyzłośliwiać skoro sam prowokujesz?
> Do pomieszczenia 6x10m ilu wejdzie klientów równocześnie? 20? 30?
> Średnio wypasiony współczesny smyrofon ma wystarczającą moc, żeby
> obsłużyć taką automatyzację sprzedaży, łącznie ze śledzeniem w czasie
> rzeczywistym przy której półce przystanął na dłużej klient.

Tak się składa, że jestem w jeden taki projekt zaangażowany, wiem ile
to danych generuje (już teraz, w początkowej fazie). Nie mogę dokładnej
liczby zdradzić, ale rząd wielkości, to są setki skompresowanych GB
miesięcznie (i nie są to obrazki). I tak, te dane są istotne i nie
możesz ich wywalić w kosmos.

[...]

>> Więc po pierwsze podałem _przykład_, po drugie te 3 miliony _już korzysta_.
>
> Jak korzysta, skoro nie korzysta?
> Mam kilku znajomych prowadzących jednoosobową działalność i żaden z nich
> nie czuje potrzeby stawiania infrastruktury serwerowej w chmurze żeby
> napisać posta na fejsbuku.

Przykład z konkretną formą (1-os DG) dotyczył księgowości
i był tylko przykładem (utraty pola przez aplikacje desktopowe).
Rozciągając to jak to robisz pokazujesz, że nie chcesz dyskutować
merytorycznie, tylko "mi dojebać", pokazujesz złą wolę.

Czy Ci twoi znajomi mają potrzebę stawiania maszyny z bazą SQL?
Czy ten argument jest jakkolwiek istotny w dyskusji o trendach
w branży IT, potencjalnych rozwiązaniach i architekturach rozwiązań?

Tak, zdaję sobie sprawę że fryzjer nie musi korzystać z żadnej
infrastruktury IT, ale nie o fryzjerach tu rozmawiamy, tylko o
firmach (nawet w skali mikro), które chcą korzystać z rozwiązań IT.

Kiedyś do poczty musiałeś stawiać serwer, teraz już nie musisz.
Teraz wchodzimy w etap, że nawet do *własnych customowych* rozwiązań
nie musisz stawiać dużych maszyn i serwerowni. O ile architektura
tego co projektujesz jest właściwa. Co też jest dobre dla startupów
i mikrofirm.

[...]

>> Widzę, że kompletnie nie rozumiesz o czym piszę.
>
> Wzajemnie.

Nie. Ja Cię rozumiem. Ale natrafiam na ścianę z Twojej strony,
bo ilekroć chcę Ci wyjaśnić (albo doprecyzować) o czym piszę,
albo prostować niejasności, to starasz się to obrócić albo
w złośliwość, albo w wyliczankę przykładów nie na temat.

Nie chcesz "zrozumieć" i tyle i nie jest to brak wiedzy, tylko
mam wrażenie ze konkretne czepialstwo i zła wola z Twojej
strony. Więc faktycznie zakończmy i każdy wróci do swojego
świata.

--
Wojciech Bańcer
wojciec...@gmail.com

[Roman Tyczka]

On Sat, 27 Apr 2019 16:44:56 +0200, Wojciech Bancer wrote:

>>> Widzę, że kompletnie nie rozumiesz o czym piszę.
>>
>> Wzajemnie.
>
> Nie. Ja Cię rozumiem. Ale natrafiam na ścianę z Twojej strony,
> bo ilekroć chcę Ci wyjaśnić (albo doprecyzować) o czym piszę,
> albo prostować niejasności, to starasz się to obrócić albo
> w złośliwość, albo w wyliczankę przykładów nie na temat.
>
> Nie chcesz "zrozumieć" i tyle i nie jest to brak wiedzy, tylko
> mam wrażenie ze konkretne czepialstwo i zła wola z Twojej
> strony. Więc faktycznie zakończmy i każdy wróci do swojego
> świata.

Bardzo fajny, ale i niestety bolesny dla niektórych wątek. Jestem także z
obozu aplikacji desktopowych i serce rwie się do bronienia tego fortu, ale
rozsądek i obserwacja stoją za tym co pisze Wojtek. Imho trochę przesadza z
tym olewaniem optymalizacji, nie skupianiu się na drobnostkach typu SQL czy
kod niospopoziomowy, a o zastępowaniu tego dostawianiem serwerów (który to
prezes, Comarcha? twierdził, że każdego specjalistę można zasatąpić
skończoną liczbą studentów - tak mi się skojarzyło) - ale w ogólnym
rozrachunku jego jechanie po bandzie jest bliżej przyszłości niż to co
reprezentuje obóz przeciwny.
Czy tego chcemy czy nie to systemy stają się coraz bardziej skomplikowane,
stawia się im coraz więcej wymagań, przetwarzają coraz więcej informacji a
hardware tanieje. Oczywiście nie można olewać algorytmiki, matematyki i
zdrowego rozsądku, bo braku podstaw i głupoty nawet setką serwerowni się
nie naprawi, ale zgodnie z regułą pareto wystarczy 20% nakłady by uzyskać
80% efektu, a te 20% to gotowe klocki w postaci chmur, bibliotek,
frameworków - uniwersalnych, więc nie zawsze zbyt wydajnych, ale tanich,
skalowalnych i wystarczających do realizacji zadań.
Druga kwestia to sam desktop. On choćby nie wiem jak zaklikać rzeczywistość
jest na równi pochyłej w dół, będzie jeszcze z nami jakiś czas, ale udział
systematycznie spada i będzie spadał, nie ma odwrotu, absolutnie bez szans.
Całe IT idzie w wirtualizację, emulację, interpretację bo to upraszcza
proces produkcji i dystrybucji oprogramowania, a prostota jest konieczna by
ułomny z natury człowiek był to w stanie robić. Dziś już nie tylko garść
geniuszy i zapaleńców się tym zajmuje, ale rzesza ludzi, dla których to
tylko praca, to musi być relatywnie proste dla ogółu, a rzeczami
niskopoziomowymi i naprawdę trudnymi, na których to wszystko stoi, zajmują
się intelektualne elity zatrudnione w googlach, amazonach czy innych
majkrosoftach.

Można się z tym nie zgadzać lub na to obrażać, ale to nie zahamuje ani
odrobiny tego pędu i wywoła jedynie frustrację u niepogodzonego z faktami.

Sam mam już bliżej do emerytury niż do matury, ale zaczynam uczyć się z
oporami JS i jego otoczenia, bo wiem, że za chwilę zostanę w ręką w nocniku
lub będę zajmował się utrzymywaniem trupów przy życiu (starych systemów
desktopowo-serwerowych) - a tego nie chcę.


ps. nie uważam, że serwery SQL są miepotrzebne i trzeba je do /dev/null'a
wsadzić, jest i będzie dla nich zawsze zastosowanie, bo imho nie jest tak,
że cały świat to docelowo będzie jedno wielkie big data. Tzn. będzie, ale
na zasadzie łączenia w jeden wielk zbiór wszystkich malukich źródeł danych,
a te małe źródła to będą także serwery SQL.

--
pozdrawiam
Roman Tyczka

[Wojciech Bancer]

On 2019-04-28, Roman Tyczka <noe...@because.no> wrote:

[...]

> Czy tego chcemy czy nie to systemy stają się coraz bardziej skomplikowane,
> stawia się im coraz więcej wymagań, przetwarzają coraz więcej informacji a
> hardware tanieje. Oczywiście nie można olewać algorytmiki, matematyki i
> zdrowego rozsądku, bo braku podstaw i głupoty nawet setką serwerowni się
> nie naprawi, ale zgodnie z regułą pareto wystarczy 20% nakłady by uzyskać
> 80% efektu, a te 20% to gotowe klocki w postaci chmur, bibliotek,
> frameworków - uniwersalnych, więc nie zawsze zbyt wydajnych, ale tanich,
> skalowalnych i wystarczających do realizacji zadań.

Tu trochę się wetnę, bo mam wrażenie że moje słowa są źle interpretowane.

Nie pisałem "nie optymalizować", tylko wyważyć i przesunąć ciężar
optymalizacji, nie robić "nadmiernej optymalizacji" ani "przedwczesnej",
ani w złym miejscu.

W dzisiejszych czasach zarówno kompilatory jak i frameworki potrafią
zrobić samodzielnie własną optymalizację i to w 99% dużo lepiej niż
przeciętny programista (ilu z nas ogarnie specyficzne własności nowoczesnych
procesorów i zastosuje odpowiednie optymalizacje pod nie?). Tylko trzeba
poprawnie tych kompilatorów /frameworków używać.

Kompilator C++ wygeneruje optymalniejszy kod niż człowiek ręcznie
dziubiący assemblera.

PHP4 był "sam z siebie" o wiele mniej wydajniejszy niż PHP5.0
A potem był php 5.3, 7+ - każdy z nich często niesie większe
zmiany wydajności aplikacji w dużo większym stopniu niż
najbardziej wymyślne poprawki uruchamianego kodu.

Doctrine nie puści setek zapytań za każdym razem kiedy je
puścimy, tylko przeprowadza wewnętrzną analizę i optymalizacje.
Jak już zapytałeś o jakiś obiekt przez find, to drugi raz
zapytanie do bazy nie pójdzie. Update do obiektów które się
nie zmieniły, nie zostaną wysłane "do bazy".

Ilu programistów stać na takie optymalizacje jak wyżej przy
każdym możliwym fragmencie gdy używają SQL? I o ile mniej
wydajna jest wtedy ich praca?

Warto poczytać:
https://www.doctrine-project.org/projects/doctrine-orm/en/2.6/reference/unitofwork.html

I z każdą wersją kolejnych bibliotek dzieje się coraz więcej "pod maską".
Tak, w szczególnych przypadkach można mieć potrzebę na robienie tego inaczej,
w drobnym fragmencie bardziej wyszukanie, ale jest to już od dawna na zasadzie
"wyjątku" a nie "reguły".

Więc z dużym prawdopodobieństwiem, o ile Twój *algorytm* nie jest
wadliwy i nie ma wyjechanej w kosmos złożoności, to nie musisz się
skupiać na bajtowych mikro-optymalizacjach, dopóki z systemu nie
przyjdzie sygnał "że gdzieś jest za ciasno".

Odnośnie moich argumentów o infrastrukturze:
Infrastruktura jest obecnie skalowalna i dużo tańsza niż jescze
10 lat temu i o wiele szybciej dostępna. Używałem tego w przykładzie
skokowych obciążeń (o których wiemy, albo umiemy je przewidzieć) a nie
jako remedium na nieprzemyślane algorytmy.

Ale niestety trzeba wyważyć koszt pomiędzy coraz wyższymi stawkami
programistów, coraz bardziej wysokopoziomowym kodem, a coraz niższymi
stawkami za skalowalną infrastrukturę.

[...]

> ps. nie uważam, że serwery SQL są miepotrzebne i trzeba je do /dev/null'a
> wsadzić, jest i będzie dla nich zawsze zastosowanie, bo imho nie jest tak,
> że cały świat to docelowo będzie jedno wielkie big data. Tzn. będzie, ale
> na zasadzie łączenia w jeden wielk zbiór wszystkich malukich źródeł danych,
> a te małe źródła to będą także serwery SQL.

Nigdy nie pisałem że nie będzie. :)

Dyskusja poszła w stronę pokazywania w jaką zmierzają coraz bardziej
wydajne systemy, żeby wyraźnie pokazać trudności skalowania serwerów
SQL, ale przecież zaczęła się od tematu "gdzie lepiej optymalizować
w aplikacji (tu: opartej o doctrine) czy na bazie (tu: triggery)"
i dlaczego Doctrine ma swoje mechanizmy jako alternatywę dla
wspomnianych triggerów.

SQL z nami jeszcze długo będzie. COBOL też jest tu i ówdzie.
A sam mam dostęp do 30-letnich systemów w perlu i aplikacji
PHP której development zaczął się w 2002 roku i jest używana
do dzisiaj.

PS. A desktopowcy powinni patrzeć w stronę PWA, osobiście uważam,
że desktop będzie powoli ewoluował w podobne hybrydy (tam gdzie
będzie potrzebny dostęp do natywnego hardware i będą ograniczenia
przeglądarkowe).

--
Wojciech Bańcer
wojciec...@gmail.com

[Wojciech Bancer]

On 2019-04-26, Marek S <pr...@spamowi.com> wrote:

[...]

>> Wygląda jak klasyczna niepotrzebna optymalizacja.
>> Zamieniasz też " na ', żeby zyskać 2 sekundy czasu serwera w rok?
>
> Nie, wcale nie 2 sekundy. Pisałem wcześniej, że przy ok pół miliona
> operacji (w ciągu nocy) udało mi się zaoszczędzić 2h pracy serwera
> (50%). Może nawet więcej. Nie pamiętam konkretnych liczb.

No nie obraż się, ale pokazujesz że nie masz na tyle ogólnej współczesnej
wiedzy odn. architektury systemów by obiektywnie ocenić gdzie optymalizacja
mogłaby być najlepsza. Może masz rację, ale może nie. Może niekoniecznie
optymalizacja powinna skupiać się na triggerach, może lepsze byłoby
przemodelowanie procesu importu danych.

> A cała sprawa wzięła się stąd, że gdy parę lat temu, gdy system był
> tworzony, nie przewidywano takiego sukcesu firmy. Informatycy wychodzili
> dokładnie z tego samego założenia co Ty, że dla tych 10k operacji nie
> będą "nadmiernie" optymalizować. A potem, zaledwie po kilku latach
> obudzili się z ręką w nocniku:

*Zaledwie* po kilku latach? Kilka lat w IT to przepaść.

No sorry, ale to brzmi jakby:
a) zrobili to co trzeba (wszystko działało prawidłowo przez kilka lat)
b) ktoś zarządzający w firmie "zapomniał" napomknąć / zainicjować zmiany
w aplikacji zanim zaczął się problem wydajnościowy. Albo nie przewidział
go.

> ojej... system się nie wyrabia przy 500k.

A miał się wyrabiać przy pisaniu tej aplikacji?

> Mało tego... zaczęły zdarzać się upadki bazy bo Ci sami informatycy
> założyli, że im więcej RAMu przydzielą w Postgresie na proces, tym,
> lepiej.

Czyli Ci sami ludzie to programiści robiący za ekspertów DBA,
administratorzy systemów i baz danych i co jeszcze? :)

> Gdyby Ci informatycy wzięli się za uczciwą robotę i nawet dla
> niewielkiego początkowo przedsięwzięcia postąpili zgodnie z kunsztem
> programowania zwracając uwagę na detale, to problem wystąpiłby dopiero
> po dojściu do możliwości serwera a nie możliwości kiepskich algorytmów.

A ja widzę typowe błędy zarządcze.
No ale idąc dalej, to jak myślisz, jak ktoś oceni Twoją pracę "za kilka
lat", jak firma rozwinie się jeszcze bardziej, dostawi się jeszcze
kilka maszyn i jednak wyjdzie, że optymalizacje które zrobiłeś teraz
już nie działają i mimo dostawienia maszyn system nadal się czka?

Ciekawe czy Twój następca wystawi Ci taką samą laurkę jak Ty swoim :)

>> Wszysktie? Nie. Nadmiarowe, stworzone "na wszelki wypadek"? Tak.
>> To co robisz nosi wszelkie znamiona premature optimization i unnecessary
>> optimization. Niby jest wydajnej, ale różnicy nikt tak realnie nie zobaczy,
>> a Ty tracisz na tym czas.
>
> Czytaj powyżej.
> Za moją "stratę czasu" dostałem niezłą kasę bo skończyły się w/w
> problemy. Argument kasy mnie przekonuje dodatkowo do słuszności podejścia.

Pisaliśmy o jednorazowym imporcie (i optymalizacji tego) a Ty płynnie
przeszedłeś do tłumaczenia że cały system był niewydajny "bo coś".

> Co do w/w optymalizacji, to faktycznie praca była mrówcza. Np. zamiast
> indeksować całe pole typu array() należało rozbić indeks na dwa:
> przeindeksować tylko część tablicy - bo okazało się, że zdecydowana
> większość zapytań właśnie o te części pytała. Podobnie było z
> zapytaniami SQL. Zamiast jakiejś tam konstrukcji zastosowano inną i znów
> progress wydajnościowy. Tymczasem od początku można było zrobić to
> dobrze...

Rzecz w tym że "dobrze" ma więcej niż jedną postać.
I to jest przedmiotem dyskusji w tym wątku.

>> Query builder *nie* jest żadnym łataniem, ani też żadnym SQLem.
>> Jest narzędziem do budowania zapytań.
>> Jak chciałbyś odpytywać bazę inaczej?
>
> Raw SQL? Doctrine ma implementację czegoś takiego.

Czyli chcesz używać ORM bez zalet ORM i z wadami ORM.
Fascynyjące :) Poczytaj o Unit of Work, o cache,
o tym jak się pracuje z obiektami:

https://www.doctrine-project.org/projects/doctrine-orm/en/2.6/reference/working-with-objects.html
https://www.doctrine-project.org/projects/doctrine-orm/en/2.6/reference/unitofwork.html
https://www.doctrine-project.org/projects/doctrine-orm/en/2.6/reference/caching.html

>> Nie wszystko na bazie sprowadza się do robienia pojedynczych zapytań
>> i działania na pojedynczych obiektach.
> Raw SQL ma JOINy od wieków.

I co z tego?

>> No nie. Query builder zbuduje zapytanie DQL:
>> https://www.doctrine-project.org/projects/doctrine-orm/en/2.6/reference/dql-doctrine-query-language.html
>
> ...i baza to zrozumie? Nie sądzę. Zawsze na końcu będzie SQL. Resztę
> wypowiedzi dopiszę poniżej.

No to znowu, po co Ci ORM?

>> Uwalnie Ciebie od znajomości struktury (nazw kolumn kluczy, nazw tabeli),
>> bo sam to ogarnia na podstawie otworzonej przez Ciebie relacji z obiektami
>> Entities.
>>
>> A potem ten DQL zostanie przetworzony na coś w stylu:
>> DELETE FROM services s WHERE s.project_id = " . $project->getId(); // jeśli $project to obiekt
>> DELETE FROM services s WHERE s.project_id = " . $project; // jeśli $project to prymityw (liczba lub string)
>
> Czy to nie ja zadałem pytanie czy na wyjściu dostaniemy:
> "DELETE FROM services s WHERE s.project=$project" ? :-D
>
> Jakoś dostrzegam w tym podobieństwo :-D

No to znowu, po co Ci ORM jak chcesz pisać SQLe?

> Tego nie musisz pisać. Ja to wiem i doceniam usprawnienie lecz w
> nielicznych / licznych / bardzo licznych przypadkach może stać się
> kamieniem u szyi.
>
> Ja nie mogę powiedzieć klientowi: to nie ja spierniczyłem, to
> Querybuilder dodał gratisa od siebie w postaci mega-nieoptymalnej
> struktury. A indeksy w bazie? Po co to komu! Niech ORM sobie je ogarnia.

Ale to *TY* spierniczasz bo nie rozumiesz narzędzia które używasz,
a starasz się go używać tak jakby go nie było i był czysty SQL.

> Jakbym dostał to takim komentarzu dyscyplinarkę, to wcale bym nie był
> zdziwiony.

Ja też.

--
Wojciech Bańcer
wojciec...@gmail.com

[Kviat]

W dniu 28.04.2019 o 14:18, Wojciech Bancer pisze:

> SQL, ale przecież zaczęła się od tematu "gdzie lepiej optymalizować
> w aplikacji (tu: opartej o doctrine) czy na bazie (tu: triggery)"

Może pamięć mam krótką, ale dobrą:

"Triggery i procedury wbudowane nie służą tylko i wyłącznie do celów
optymalizacyjnych."

Pozdrawiam
Piotr

[Wojciech Bancer]

Wątek dot. triggerów początkowo zaczął się tego co pisałem
(i tego że Marek S nie mógł obsłużyć triggerów przez Doctrine),
a zdryfował na kilka torów, m.in. ten o którym piszesz
(ale też wracał do wydajności, skalowalności, specyficznych
różnic desktop-web itd).

--
Wojciech Bańcer
wojciec...@gmail.com

[Marek S]

W dniu 2019-04-28 o 14:50, Wojciech Bancer pisze:

>> Nie, wcale nie 2 sekundy. Pisałem wcześniej, że przy ok pół miliona
>> operacji (w ciągu nocy) udało mi się zaoszczędzić 2h pracy serwera
>> (50%). Może nawet więcej. Nie pamiętam konkretnych liczb.
>
> No nie obraż się, ale pokazujesz że nie masz na tyle ogólnej współczesnej
> wiedzy odn. architektury systemów by obiektywnie ocenić gdzie optymalizacja
> mogłaby być najlepsza.

Ależ zgadzam się w 100%!

> Może masz rację, ale może nie. Może niekoniecznie
> optymalizacja powinna skupiać się na triggerach, może lepsze byłoby
> przemodelowanie procesu importu danych.

Przemodelowałem obie te rzeczy. Modyfikacja algorytmu importu też
wniosła pozytywny wpływ, ale nie aż tak spektakularny.

Dobra, załóżmy, że jestem kretynem i metodą prób i błędów spowodowałem
zaoszczędzenie czasu pracy serwera. Wpisywałem jedynie przypadkowe znaki
z klawiatury. Po dwóch miliardach prób nawet zadziałało. Co z tego wynika?

>> ojej... system się nie wyrabia przy 500k.
>
> A miał się wyrabiać przy pisaniu tej aplikacji?

Oczywiście, ze nie. Nikt nie zakładał tak dużego sukcesu firmy w
pozyskiwaniu klientów.

I o to mi właśnie chodzi. Współczesny informatyk, wg Twojego opisu, to
bezmózgi rzemieślnik, który jedynie jest w pełni świadom swoich
niedomagań i w związku z tym implementuje byle jaki kod - aby tylko
działał w trakcie testów i zaraz po uruchomieniu produkcyjnym. Chwilę
potem może się walić... bo nie było w założeniach rzetelności jego
pracy. Jeśli można napisać kod dobrze lub źle, nawet jeśli podobna ilość
czasu jest na to potrzebna, to lecimy w wariant "źle".

Szerze mówiąc, przyznaję Ci rację w tym zakresie. Nierzadko przysłuchuję
się rozmowom rekrutacyjnym i to jest niestety cechą frameworkowców.
Czasem nie wiedzą czym protecetd różni się od public... To cytat z dziś.

>> Gdyby Ci informatycy wzięli się za uczciwą robotę i nawet dla
>> niewielkiego początkowo przedsięwzięcia postąpili zgodnie z kunsztem
>> programowania zwracając uwagę na detale, to problem wystąpiłby dopiero
>> po dojściu do możliwości serwera a nie możliwości kiepskich algorytmów.
>
> A ja widzę typowe błędy zarządcze.

Bo kłopot jest w tym, że zarząd zwykle nie wie czym jest baza danych,
API, PHP i inny informatyczny bełkot. Tu pełna zgoda. Jednakże nie
bardzo znajduję w tym wszystkim preferowane przez Ciebie wykorzystywanie
ich niewiedzy na rzecz własnego lenistwa.

> No ale idąc dalej, to jak myślisz, jak ktoś oceni Twoją pracę "za kilka
> lat", jak firma rozwinie się jeszcze bardziej, dostawi się jeszcze
> kilka maszyn i jednak wyjdzie, że optymalizacje które zrobiłeś teraz
> już nie działają i mimo dostawienia maszyn system nadal się czka?
>
> Ciekawe czy Twój następca wystawi Ci taką samą laurkę jak Ty swoim :)

Zajebisty jesteś w tym momencie. :-D Zakładasz zatem, że dobrze napisana
wyszukiwarka Google powinna działać na przydomowym serwerze. Mało tego,
dostawienie Facebooka i Pinteresta też nie powinno wnieść istotnego
obciążenia dla CPU :-D Aha... i łącze 1Mbps spokojnie wydoli.

A jak nie wydoli ... to będziemy pisać laurki na to, że jakiś kmiot
informatyczny nie jest w stanie pchać przez łącze 1Mbps 10.000x tyle.

Tylko pogratulować takiego podejścia.

>> Co do w/w optymalizacji, to faktycznie praca była mrówcza. Np. zamiast
>> indeksować całe pole typu array() należało rozbić indeks na dwa:
>> przeindeksować tylko część tablicy - bo okazało się, że zdecydowana
>> większość zapytań właśnie o te części pytała. Podobnie było z
>> zapytaniami SQL. Zamiast jakiejś tam konstrukcji zastosowano inną i znów
>> progress wydajnościowy. Tymczasem od początku można było zrobić to
>> dobrze...
>
> Rzecz w tym że "dobrze" ma więcej niż jedną postać.
> I to jest przedmiotem dyskusji w tym wątku.

Tyle tylko, że Ty wymagasz przekroczenia barier fizyki aby nie było
beznadziejnie.

>>> Query builder *nie* jest żadnym łataniem, ani też żadnym SQLem.
>>> Jest narzędziem do budowania zapytań.
>>> Jak chciałbyś odpytywać bazę inaczej?
>>
>> Raw SQL? Doctrine ma implementację czegoś takiego.
>
> Czyli chcesz używać ORM bez zalet ORM i z wadami ORM.
> Fascynyjące :)

Próbujesz naginać teraz moje wypowiedzi do tego by pasowały do Twoich
szyderstw. Ja planuję używać SQL do insertów/update'ów w sekcjach
wymagających wydajności.

> Poczytaj o Unit of Work, o cache,
> o tym jak się pracuje z obiektami:

Sugerujesz, że są próby ratowania koncepcyjnej niedoróbki ORM w
kolejnych segmentach Doctrine?

> https://www.doctrine-project.org/projects/doctrine-orm/en/2.6/reference/working-with-objects.html
> https://www.doctrine-project.org/projects/doctrine-orm/en/2.6/reference/unitofwork.html
> https://www.doctrine-project.org/projects/doctrine-orm/en/2.6/reference/caching.html

Poczytam, ale nie wszystko na raz. Krok za krokiem przemierzam i testuję
famework.

>> ...i baza to zrozumie? Nie sądzę. Zawsze na końcu będzie SQL. Resztę
>> wypowiedzi dopiszę poniżej.
>
> No to znowu, po co Ci ORM?

Pisałem już: do wszystkiego, co nie musi być wydajne, bo jest za to
wygodne. Np. zwykłe formularze fantastycznie proso się integruje z
Doctrine. Ich wydajność może być tragiczna - nikt tego nie zauważy nawet.

> Ale to *TY* spierniczasz bo nie rozumiesz narzędzia które używasz,
> a starasz się go używać tak jakby go nie było i był czysty SQL.

Mam nadzieję, że doznam jakiegoś olśnienia i uznam, że 2 zapytania SQL
(z czego wynik pierwszego jest ignorowany) są bardziej wydajne niż jedno.

--
Pozdrawiam,
Marek

[Wojciech Bancer]

On 2019-04-29, Marek S <pr...@spamowi.com> wrote:

[...]

> I o to mi właśnie chodzi. Współczesny informatyk, wg Twojego opisu, to

I tutaj stop. Nie wg mojego opisu. Twojego opisu, przeinaczonego z moich
słów. I w dodaktu nieudolnie. Nie chce mi się tego już kolejny raz
prostować, ani w tym trybie dyskutować.

Mam wrażenie, ze nie przyszedłeś tu się uczyć czegokolwiek, tylko skrytykować
podejście stosowane w danym frameworku/-ach i utwierdzać się w przekonaniu,
jak to Ty zajebiście postępujesz już od lat.

--
Wojciech Bańcer
wojciec...@gmail.com

[Borys Pogoreło]

Dnia Fri, 26 Apr 2019 23:58:56 +0200, Marek S napisał(a):

> Zależy od zlecenia. W ostatnim do 750000+ (a i 2x tyle się od czasu do
> czasu zdarzało) w ciągu kilku nocnych godzin, każdego dnia.

To rób to wsadowo, a nie sztuka po sztuce ORM-em.

> - nie posiada niepotrzebnych aliasów typu ->delete() standardowych
> elementów SQL'a - nie trzeba uczyć się 2x SQLa
> - można w nim używać dowolnych dialektów SQL
> - wygodna parametryzacja, która czyni SQL czytelnym (np. :id w miejscu
> ID usera)

To nie są zalety, tylko przyzwyczajenie.

> - tam, gdzie nie ma krytycznych wydajnościowo fragmentów aplikacji,
> nadal można korzystać w tradycyjny sposób z ORM np. przy obsłudze
> formularzy, gdzie pani Krysia z pewnością nie wklepie 750000 danych w
> parę godzin.

Podobnie jak nikt Ci nie broni używać SQL korzytając z ORM.

> Autorytatywnie... nie wiem czy to dobre określenie. To moje prywatne
> zdanie. Otóż wychodzę z założenia, że nawet jeśli pracujemy przy małym
> projekcie, to powinniśmy dbać o wydajność wszystkiego, co robimy. Na ile
> się oczywiście da w małym projekcie. A już w szczególności należy
> wystrzegać się randomowych zapytań do bazy danych, których wyniki w
> ogóle nas nie interesują. Gdyby nie ten fakt, z pewnością mocno
> zmieniłbym swoją opinię na temat ORM.

ORM zrobi tylko tyle, o ile go poprosisz. "Randomowe zapytania" nie
pojawiają się same z siebie. I nie, hydracja obiektów nie jest "randomowym
zapytaniem".

> Kolejną rzeczą ORM, którą rozumiem ale nie popieram to równanie w dół.
> ORM ma za zadanie supportować ileś tam baz danych. Jeśli jakaś potrafi
> cioś więcej niż jakakolwiek inna - wyrzucamy to coś. W konsekwencji
> zostaje prymitywny SQL do dyspozycji tegoż ORM'a. W Doctrine nawet
> zwykły Enum to wyzwanie - trzeba doinstalowywać bundle (!!!) ... o ile
> nie korzystamy z MySQL (widocznie ta baza budzi sentyment u developerów
> Doctrine).

Bo ENUM to zło.
http://komlenic.com/244/8-reasons-why-mysqls-enum-data-type-is-evil/

> Zwróć uwagę, że developerzy baz danych dwoją się i troją wprowadzając
> przeróżne unowocześnienia. A potem po tym wszystkim przejeżdża walec z
> numerami rejestracyjnymi: ORM. To też mi się nie podoba. Czyli zostaje
> cofnąć technologię baz do lat 90-tych?

Czyli narzekasz, że narzędzie ujednolicające interfejsy baz danych robi to,
co powinno. ORMy mają swoje ograniczenia, jeśli Ci przeszkadzają, to nie
używasz. A mam wrażenie, że próbujesz na siłę użyć tego narzędzia.

--
Borys Pogoreło
borys(#)leszno,edu,pl