znaczacy > comp.lang.* > comp.lang.php

Marek S (25.12.2018, 15:54)
Witam,

Próbuje przekonac sie do ORM. Ponoc jest to szybsze i wygodniejsze. Byc
moze gdy robimy jakiegos prostego inserta do jednej tabeli i czy
selecta. Jednakze tu tez mam watpliwosci czy jest to faktycznie szybsze
niz pisanie w SQL. Nie bardzo potrafie zainfekowac sie ta idea. Oto moje
watpliwosci:

1. Pracujac w ORM musimy nauczyc sie SQL raz jeszcze - od nowa. Jest on
zapisany w jezyku PHP za pomoca funkcji. Pytanie: po co? Jest z tego
jakas korzysc? W dodatku lapie sie na tym, ze staram sie przekladac w
myslach to co pisze w ORM na jezyk zapytania SQL jakie z tego moze
powstac by uzyskac efektywnosc wykonania zlozonego zapytania. Tymczasem
szybciej byloby zwyczajnie w SQL skrobnac to samo zapytanie zamiast
kombinowac.

2. W ORM tracimy w pewnym zakresie kontrole nad tym jaki SQL z tego sie
wytworzy. Nie wiem czy jest inny sposób monitorowania wygenerowana SQL
przez ORM jak grzebanie w logach bazy danych - co mocno komplikuje
development. Nie wiem czy da sie zmusic ORM do generowania optymalnych
struktur SQL charakterystycznych dla konkretnej bazy danych. Np. z tego
co pamietam, w MySQL JOINny mogly miec tylko 1 argument a w niektórych
przypadkach w PostgreSQL JOINy z wieloma argumentami potrafily
dramatycznie zwiekszyc wydajnosc zapytania. Oczywiscie to tylko jest
przyklad ad hoc. Zapewne jesli sie zastanowic, to wiele sytuacji mozna
wymyslic.

3. Przy tworzeniu wiekszych systemów rzadko zdarza sie, ze pracujemy z
jedna tabela w sensie aktualizacji zawartosci. Np. aby móc zrobic
inserta z kompletem potrzebnych danych, to nierzadko zachodzi potrzeba
wydobycia informacji z innych tabel, przeliczenie czegos tam i w
zaleznosci od wyników zmodyfikowanie rekordów w tej i innych tabelach.
Tak wiec traktowanie ORM jako "rekordu w pojedynczej tabeli" jest mocnym
ograniczeniem. Model i tak musi grzebac w calym ekosystemie bazy danych.

Jedyna korzysc jaka dostrzegam, to mozliwosc przenoszenia projektów
miedzy jedna z 4 baz danych jaka Laravel obsluguje. Ale czy to jest
faktycznie takie istotne? Zazwyczaj nie ma potrzeby zmiany bazy.
Borys Pogorelo (26.12.2018, 18:50)
Dnia Tue, 25 Dec 2018 14:54:39 +0100, Marek S napisal(a):

> 1. Pracujac w ORM musimy nauczyc sie SQL raz jeszcze - od nowa. Jest on
> zapisany w jezyku PHP za pomoca funkcji. Pytanie: po co? Jest z tego
> jakas korzysc?


Oczywiscie, mozesz latwo modyfikowac zapytanie i przekazywac je dalej w
logice programu, która znów je modyfikuje. Prosto, latwo i przyjemnie,
zamiast robic rzezbe na stringach (która latwo robic przyrostowo, ale juz
nie w druga strone).

> 2. W ORM tracimy w pewnym zakresie kontrole nad tym jaki SQL z tego sie
> wytworzy.


I jaki widzisz w tym problem? Jesli akurat jest to ten 1% zapytan, gdzie
lepiej je napiszesz recznie, to mozesz tak robic.

> Tak wiec traktowanie ORM jako "rekordu w pojedynczej tabeli" jest mocnym
> ograniczeniem. Model i tak musi grzebac w calym ekosystemie bazy danych.


Dokladnie, bo zle to traktujesz. Eloquent potrafi duzo wiecej, niz zwykly
ORM i tu tkwi jego sila. Poczytaj o relacjach modeli i co za ich pomoca
mozna robic, to szybko przejdzie Ci ochota na dlubanie w SQL.
Marek S (26.12.2018, 22:28)
W dniu 2018-12-26 o 17:50, Borys Pogorelo pisze:
> Oczywiscie, mozesz latwo modyfikowac zapytanie i przekazywac je dalej w
> logice programu, która znów je modyfikuje. Prosto, latwo i przyjemnie,
> zamiast robic rzezbe na stringach (która latwo robic przyrostowo, ale juz
> nie w druga strone).


Ok. Tu faktycznie racja.

>> 2. W ORM tracimy w pewnym zakresie kontrole nad tym jaki SQL z tego sie
>> wytworzy.

> I jaki widzisz w tym problem? Jesli akurat jest to ten 1% zapytan, gdzie
> lepiej je napiszesz recznie, to mozesz tak robic.


Wystarczy ze ten 1% zapytan powoduje upadek serwera bazodanowego gdy
(konkretny przypadek) miliony rekordów sa przetwarzane kazdej nocy.

Wystarczy równiez, ze optymalizacja SQL skrócila w ten sposób czas
wykonywania procesu z 4h do 20 minut (równiez konkretny przypadek). W
tym przypadku zastosowalem skladnie typowa dla PostgreSQL zamiast
uniwersalnej, dzialajacej równiez na MySQL.

> Dokladnie, bo zle to traktujesz. Eloquent potrafi duzo wiecej, niz zwykly
> ORM i tu tkwi jego sila. Poczytaj o relacjach modeli i co za ich pomoca
> mozna robic, to szybko przejdzie Ci ochota na dlubanie w SQL.


Oki, tak zrobie niebawem. Jestem na poczatku tej drogi, wdrazam sie
wlasnie w Eloquenta. Byc moze powróce za jakis czas z dalszymi pytaniami.
Borys Pogorelo (27.12.2018, 00:26)
Dnia Wed, 26 Dec 2018 21:28:50 +0100, Marek S napisal(a):

>> I jaki widzisz w tym problem? Jesli akurat jest to ten 1% zapytan, gdzie
>> lepiej je napiszesz recznie, to mozesz tak robic.

> Wystarczy ze ten 1% zapytan powoduje upadek serwera bazodanowego gdy
> (konkretny przypadek) miliony rekordów sa przetwarzane kazdej nocy.


To sa skrajne przypadki, które optymalizuje sie recznie. 99% reszty to
wyciaganie komentarzy do posta czy zdjec dla profilu, ale tylko tych
majacych komentarze.
Marek S (27.12.2018, 23:05)
W dniu 2018-12-26 o 23:26, Borys Pogorelo pisze:

> To sa skrajne przypadki, które optymalizuje sie recznie. 99% reszty to
> wyciaganie komentarzy do posta czy zdjec dla profilu, ale tylko tych
> majacych komentarze.


Czy w ORM daje sie jakos ogarnac takie przypadki? Wlasnie zaangazowano
mnie do innego przedsiewziecia, w którym ta skrajnosc wystepuje (inna
firma). Najwidoczniej mam pecha do nich :-)
Wojciech Bancer (27.12.2018, 23:12)
On 2018-12-27, Marek S <precz> wrote:

[...]

>> To są skrajne przypadki, które optymalizuje się ręcznie. 99% reszty to
>> wyciąganie komentarzy do posta czy zdjęć dla profilu, ale tylko tych
>> mających komentarze.

> Czy w ORM daje się jakoś ogarnąć takie przypadki? Właśnie zaangażowano
> mnie do innego przedsięwzięcia, w którym ta skrajność występuje (inna
> firma). Najwidoczniej mam pecha do nich :-)


To zadziała?
Marek S (28.12.2018, 23:28)
W dniu 2018-12-27 o 22:12, Wojciech Bancer pisze:
> To zadziała?
>


Z pewnością, ale jest to zaniechanie ORM :-)
Borys Pogorelo (28.12.2018, 23:48)
Dnia Fri, 28 Dec 2018 22:28:46 +0100, Marek S napisal(a):

>> To zadziala?
>>

> Z pewnoscia, ale jest to zaniechanie ORM :-)


ORM to nie jest jakas swietosc - jesli w danym przypadku lepsze bedzie
recznie napisane zapytanie SQL, to nie ma przeszkód by go uzyc.

Miej tylko na uwadze, ze wynikiem zapytania select zawsze bedzie kolekcja
obiektów stdClass, nie jest latwo to zamienic na zwykla tablice
(array_pluck() nie polecam dla wiekszych zbiorów danych).
Marek S (29.12.2018, 00:29)
W dniu 2018-12-28 o 22:48, Borys Pogorelo pisze:

> Miej tylko na uwadze, ze wynikiem zapytania select zawsze bedzie kolekcja
> obiektów stdClass, nie jest latwo to zamienic na zwykla tablice
> (array_pluck() nie polecam dla wiekszych zbiorów danych).


Ok, tak tez sadzilem...

Jeszcze na koniec jedno pytanie o ORM. Czy jest jakis konwerter SQL ->
laravelowy ORM? Chodzi o to, ze o wiele latwiej napisac zlozone
zapytanie w SQL. Przy prostych strukturach nie ma problemu. Dosc czesto
potrzebne sa np. podzapytania agregujace do tworzenia kryteriów wyboru w
zapytaniu nadrzednym i inne ekwilibrystyki z wieloma JOINami wszelkiej
masci.
Borys Pogorelo (29.12.2018, 01:03)
Dnia Fri, 28 Dec 2018 23:29:11 +0100, Marek S napisal(a):

> Ok, tak tez sadzilem...
> Jeszcze na koniec jedno pytanie o ORM. Czy jest jakis konwerter SQL ->
> laravelowy ORM?


Nie spotkalem sie z czyms takim i watpie, by ktos mial potrzebe stworzenia
tak skomplikowanego narzedzia.

> Chodzi o to, ze o wiele latwiej napisac zlozone zapytanie w SQL. Przy
> prostych strukturach nie ma problemu. Dosc czesto potrzebne sa np.
> podzapytania agregujace do tworzenia kryteriów wyboru w zapytaniu
> nadrzednym i inne ekwilibrystyki z wieloma JOINami wszelkiej masci.


Prawdopodobnie wiekszosc z nich bedziesz mógl zastapic relacjami Eloquenta
i operacjami na nich.
Marek S (29.12.2018, 22:23)
W dniu 2018-12-29 o 00:03, Borys Pogorelo pisze:
> Prawdopodobnie wiekszosc z nich bedziesz mógl zastapic relacjami Eloquenta
> i operacjami na nich.


Byc moze zbyt wczesnie panikuje :-) ORM wydaje mi sie póki co sztuczny
srodowiskiem dla nieuków bazodanowych. Z drugiej strony gadalem z
kolegami programujacymi w C#, których jest drastyczna przewaga w firmie
i oni wszyscy jada w ORM. Wyrazenie SQL kojarzy im sie ze studiami niz z
czymkolwiek uzytecznym. Byc moze czas na zmiany...
irq (06.01.2019, 14:05)
W dniu sobota, 29 grudnia 2018 21:24:00 UTC+1 uzytkownik Marek S napisal:
> Byc moze zbyt wczesnie panikuje :-) ORM wydaje mi sie póki co sztuczny
> srodowiskiem dla nieuków bazodanowych. Z drugiej strony gadalem z
> kolegami programujacymi w C#, których jest drastyczna przewaga w firmie
> i oni wszyscy jada w ORM. Wyrazenie SQL kojarzy im sie ze studiami niz z
> czymkolwiek uzytecznym.


wlasnie trafnie ich nazwales

> Byc moze czas na zmiany...


.... pracy
Podobne wątki