🚀 go-pugleaf

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