🚀 go-pugleaf

On 2019-04-20, Marek S <precz@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
wojciech.bancer@gmail.com

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

On 2019-04-21, Marek S <precz@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
wojciech.bancer@gmail.com

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

On 2019-04-22, Marek S <precz@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
wojciech.bancer@gmail.com

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

On 2019-04-22, Marek S <precz@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
wojciech.bancer@gmail.com

W dniu 2019-04-21 o 14:25, Wojciech Bancer pisze:
> On 2019-04-20, Marek S <precz@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.

On 2019-04-23, ww <ww@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
wojciech.bancer@gmail.com

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

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

On 2019-04-23, Marek S <precz@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
wojciech.bancer@gmail.com

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

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

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

On 2019-04-23, Marek S <precz@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
wojciech.bancer@gmail.com

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

On 2019-04-23, Marek S <precz@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
wojciech.bancer@gmail.com

W dniu 2019-04-23 o 17:13, Wojciech Bancer pisze:
> On 2019-04-23, ww <ww@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.

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

On 2019-04-24, Roman Tyczka <noemail@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
wojciech.bancer@gmail.com

On 2019-04-24, ww <ww@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
wojciech.bancer@gmail.com

W dniu 24.04.2019 o 15:13, Wojciech Bancer pisze:
> On 2019-04-24, ww <ww@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

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

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
wojciech.bancer@gmail.com

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

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

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
wojciech.bancer@gmail.com

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

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

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

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
wojciech.bancer@gmail.com

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

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

On 2019-04-26, Borys Pogoreło <borys@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
wojciech.bancer@gmail.com

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
wojciech.bancer@gmail.com

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

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

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
wojciech.bancer@gmail.com

On 2019-04-26, Borys Pogoreło <borys@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
wojciech.bancer@gmail.com

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

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

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
wojciech.bancer@gmail.com

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

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
wojciech.bancer@gmail.com

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

On 2019-04-28, Roman Tyczka <noemail@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
wojciech.bancer@gmail.com

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

On 2019-04-28, Kviat <Kviat> wrote:
> 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."

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
wojciech.bancer@gmail.com

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