On Thursday, August 1, 2019 at 1:41:58 PM UTC+2, Maciej Sobczak wrote:
> > Skąd Wasze opory przed robieniem takich automatów jeśli oszczędzają one
> > 90% czasu na klepanie SQL-i?!?
>
> Stąd, że przy prostych systemach pisanie SQLi prawie w ogóle nie zajmuje czasu,
więc nie ma sensu inwestować, żeby tam coś zaoszczędzić; a przy skomplikowanych
systemach niczego się nie zaoszczędzi automatyzacją.
> Co więcej, nawet przy Twoim rozwiązaniu z dziedziczeniem klas możesz napotkać na
opór programisty przed wprowadzaniem optymalizacji - wyobraź sobie, że jakiemuś
SQLowi bardzo by pomogło jedno dodatkowe słowo (np. hint na użycie konkretnego
indeksu, co jest częstym przypadkiem) - w Twoim rozwiązaniu, żeby to jedno słowo
dopisać do zapytania, trzeba stworzyć dodatkowy byt w postaci klasy dziedziczącej.
Zależnie od polityki zarządzania kodem, to może być konieczność dodania nowego pliku.
Dalej być może zmiana skryptu budującego. Itd. Znam przypadek, kiedy to właśnie
programista stawiał opór po tym, jak wcześniej sam poprosił admina o zdiagnozowanie
słabej wydajności programu i admin po diagnozie zarekomendował drobną zmianę SQLa a
na tą drobną zmianę programista nie miał procesu, bo mu framework (akurat w Javie)
wszystko "automatyzował".
>
> Napisz uczciwie SQLa. Nawet krótkiego.
>
> --
> Maciej Sobczak * http://www.inspirel.com

Pracowałem zarówno na sqlu osadzanym bezpośrednio w kodzie (z różnym zestawem funkcji

wspomagających, rzecz jasna, nie chodzi o to aby łączyć się z bazą po
soketach), jak i na różnych maperach i warstwach pośrednich. Nie wyrobiłem
sobie zdania że jedno z tych rozwiązań jest wyraźnie lepsze lub gorsze.
Na pewno w przypadku gdy pracowałem blisko sqla w kodzie, to łatwiej mogłem
dopisać funkcje które z punktu widzenia projektu były przydatne, a jakiś
framework/biblioteka niekoniecznie je oferował.

Pozdrawiam