Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > pl.comp.lang.php > #15956 > unrolled thread

Laravel ORM czy SQL?

Back to article view | Back to pl.comp.lang.php

Contents

  Laravel ORM czy SQL? Marek S <precz@spamowi.com> - 2018-12-25 14:54 +0100
    Re: Laravel ORM czy SQL? Borys Pogoreło <borys@pl.edu.leszno> - 2018-12-26 17:50 +0100
      Re: Laravel ORM czy SQL? Marek S <precz@spamowi.com> - 2018-12-26 21:28 +0100
        Re: Laravel ORM czy SQL? Borys Pogoreło <borys@pl.edu.leszno> - 2018-12-26 23:26 +0100
          Re: Laravel ORM czy SQL? Marek S <precz@spamowi.com> - 2018-12-27 22:05 +0100
            Re: Laravel ORM czy SQL? Wojciech Bancer <wojciech.bancer@gmail.com> - 2018-12-27 22:12 +0100
              Re: Laravel ORM czy SQL? Marek S <precz@spamowi.com> - 2018-12-28 22:28 +0100
                Re: Laravel ORM czy SQL? Borys Pogoreło <borys@pl.edu.leszno> - 2018-12-28 22:48 +0100
                  Re: Laravel ORM czy SQL? Marek S <precz@spamowi.com> - 2018-12-28 23:29 +0100
                    Re: Laravel ORM czy SQL? Borys Pogoreło <borys@pl.edu.leszno> - 2018-12-29 00:03 +0100
                      Re: Laravel ORM czy SQL? Marek S <precz@spamowi.com> - 2018-12-29 21:23 +0100
                        Re: Laravel ORM czy SQL? irq <ipluta62@gmail.com> - 2019-01-06 04:05 -0800

#15956 — Laravel ORM czy SQL?

Witam,

Próbuję przekonać się do ORM. Ponoć jest to szybsze i wygodniejsze. Być 
może gdy robimy jakiegoś prostego inserta do jednej tabeli i czy 
selecta. Jednakże tu też mam wątpliwości czy jest to faktycznie szybsze 
niż pisanie w SQL. Nie bardzo potrafię zainfekować się tą ideą. Oto moje 
wątpliwości:

1. Pracując w ORM musimy nauczyć się SQL raz jeszcze - od nowa. Jest on 
zapisany w języku PHP za pomocą funkcji. Pytanie: po co? Jest z tego 
jakaś korzyść? W dodatku łapię się na tym, że staram się przekładać w 
myślach to co piszę w ORM na język zapytania SQL jakie z tego może 
powstać by uzyskać efektywność wykonania złożonego zapytania. Tymczasem 
szybciej byłoby zwyczajnie w SQL skrobnąć to samo zapytanie zamiast 
kombinować.

2. W ORM tracimy w pewnym zakresie kontrolę nad tym jaki SQL z tego się 
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 się zmusić ORM do generowania optymalnych 
struktur SQL charakterystycznych dla konkretnej bazy danych. Np. z tego 
co pamiętam, w MySQL JOINny mogły mieć tylko 1 argument a w niektórych 
przypadkach w PostgreSQL JOINy z wieloma argumentami potrafiły 
dramatycznie zwiększyć wydajność zapytania. Oczywiście to tylko jest 
przykład ad hoc. Zapewne jeśli się zastanowić, to wiele sytuacji można 
wymyślić.

3. Przy tworzeniu większych systemów rzadko zdarza się, że pracujemy z 
jedną tabelą w sensie aktualizacji zawartości. Np. aby móc zrobić 
inserta z kompletem potrzebnych danych, to nierzadko zachodzi potrzeba 
wydobycia informacji z innych tabel, przeliczenie czegoś tam i w 
zależności od wyników zmodyfikowanie rekordów w tej i innych tabelach. 
Tak więc traktowanie ORM jako "rekordu w pojedynczej tabeli" jest mocnym 
ograniczeniem. Model i tak musi grzebać w całym ekosystemie bazy danych.

Jedyna korzyść jaką dostrzegam, to możliwość przenoszenia projektów 
między jedną z 4 baz danych jaką Laravel obsługuje. Ale czy to jest 
faktycznie takie istotne? Zazwyczaj nie ma potrzeby zmiany bazy.

-- 
Pozdrawiam,
Marek

[toc] | [next] | [standalone]

#15959

Dnia Tue, 25 Dec 2018 14:54:39 +0100, Marek S napisał(a):

> 1. Pracując w ORM musimy nauczyć się SQL raz jeszcze - od nowa. Jest on 
> zapisany w języku PHP za pomocą funkcji. Pytanie: po co? Jest z tego 
> jakaś korzyść?

Oczywiście, możesz łatwo modyfikować zapytanie i przekazywać je dalej w
logice programu, która znów je modyfikuje. Prosto, łatwo i przyjemnie,
zamiast robić rzeźbę na stringach (którą łatwo robić przyrostowo, ale już
nie w drugą stronę).

> 2. W ORM tracimy w pewnym zakresie kontrolę nad tym jaki SQL z tego się 
> wytworzy. 

I jaki widzisz w tym problem? Jeśli akurat jest to ten 1% zapytań, gdzie
lepiej je napiszesz ręcznie, to możesz tak robić.

> Tak więc traktowanie ORM jako "rekordu w pojedynczej tabeli" jest mocnym 
> ograniczeniem. Model i tak musi grzebać w całym ekosystemie bazy danych.

Dokładnie, bo źle to traktujesz. Eloquent potrafi dużo więcej, niż zwykły
ORM i tu tkwi jego siła. Poczytaj o relacjach modeli i co za ich pomocą
można robić, to szybko przejdzie Ci ochota na dłubanie w SQL.

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

[toc] | [prev] | [next] | [standalone]

#15965

W dniu 2018-12-26 o 17:50, Borys Pogoreło pisze:
> 
> Oczywiście, możesz łatwo modyfikować zapytanie i przekazywać je dalej w
> logice programu, która znów je modyfikuje. Prosto, łatwo i przyjemnie,
> zamiast robić rzeźbę na stringach (którą łatwo robić przyrostowo, ale już
> nie w drugą stronę).

Ok. Tu faktycznie racja.

>> 2. W ORM tracimy w pewnym zakresie kontrolę nad tym jaki SQL z tego się
>> wytworzy.
> 
> I jaki widzisz w tym problem? Jeśli akurat jest to ten 1% zapytań, gdzie
> lepiej je napiszesz ręcznie, to możesz tak robić.

Wystarczy że ten 1% zapytań powoduje upadek serwera bazodanowego gdy 
(konkretny przypadek) miliony rekordów są przetwarzane każdej nocy.

Wystarczy również, że optymalizacja SQL skróciła w ten sposób czas 
wykonywania procesu z 4h do 20 minut (również konkretny przypadek). W 
tym przypadku zastosowałem składnię typową dla PostgreSQL zamiast 
uniwersalnej, działającej również na MySQL.

> Dokładnie, bo źle to traktujesz. Eloquent potrafi dużo więcej, niż zwykły
> ORM i tu tkwi jego siła. Poczytaj o relacjach modeli i co za ich pomocą
> można robić, to szybko przejdzie Ci ochota na dłubanie w SQL.

Oki, tak zrobię niebawem. Jestem na początku tej drogi, wdrażam się 
właśnie w Eloquenta. Być może powrócę za jakiś czas z dalszymi pytaniami.

-- 
Pozdrawiam,
Marek

[toc] | [prev] | [next] | [standalone]

#15968

Dnia Wed, 26 Dec 2018 21:28:50 +0100, Marek S napisał(a):

>> I jaki widzisz w tym problem? Jeśli akurat jest to ten 1% zapytań, gdzie
>> lepiej je napiszesz ręcznie, to możesz tak robić.
> 
> Wystarczy że ten 1% zapytań powoduje upadek serwera bazodanowego gdy 
> (konkretny przypadek) miliony rekordów są przetwarzane każdej nocy.

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.

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

[toc] | [prev] | [next] | [standalone]

#15979

W dniu 2018-12-26 o 23:26, Borys Pogoreło pisze:

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

-- 
Pozdrawiam,
Marek

[toc] | [prev] | [next] | [standalone]

#15982

On 2018-12-27, Marek S <precz@spamowi.com> 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?
https://stackoverflow.com/questions/33049511/how-to-execute-raw-queries-with-laravel-5-1

-- 
Wojciech Bańcer
wojciech.bancer@gmail.com

[toc] | [prev] | [next] | [standalone]

#15986

W dniu 2018-12-27 o 22:12, Wojciech Bancer pisze:
> 
> To zadziała?
> https://stackoverflow.com/questions/33049511/how-to-execute-raw-queries-with-laravel-5-1


Z pewnością, ale jest to zaniechanie ORM :-)

-- 
Pozdrawiam,
Marek

[toc] | [prev] | [next] | [standalone]

#15987

Dnia Fri, 28 Dec 2018 22:28:46 +0100, Marek S napisał(a):

>> To zadziała?
>> https://stackoverflow.com/questions/33049511/how-to-execute-raw-queries-with-laravel-5-1
> 
> Z pewnością, ale jest to zaniechanie ORM :-)

ORM to nie jest jakaś świętość - jeśli w danym przypadku lepsze będzie
ręcznie napisane zapytanie SQL, to nie ma przeszkód by go użyć.

Miej tylko na uwadze, że wynikiem zapytania select zawsze będzie kolekcja
obiektów stdClass, nie jest łatwo to zamienić na zwykłą tablicę
(array_pluck() nie polecam dla większych zbiorów danych).

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

[toc] | [prev] | [next] | [standalone]

#15990

W dniu 2018-12-28 o 22:48, Borys Pogoreło pisze:

> Miej tylko na uwadze, że wynikiem zapytania select zawsze będzie kolekcja
> obiektów stdClass, nie jest łatwo to zamienić na zwykłą tablicę
> (array_pluck() nie polecam dla większych zbiorów danych).

Ok, tak też sądziłem...

Jeszcze na koniec jedno pytanie o ORM. Czy jest jakiś konwerter SQL -> 
laravelowy ORM? Chodzi o to, że o wiele łatwiej napisać złożone 
zapytanie w SQL. Przy prostych strukturach nie ma problemu. Dość często 
potrzebne są np. podzapytania agregujące do tworzenia kryteriów wyboru w 
zapytaniu nadrzędnym i inne ekwilibrystyki z wieloma JOINami wszelkiej 
maści.

-- 
Pozdrawiam,
Marek

[toc] | [prev] | [next] | [standalone]

#15991

Dnia Fri, 28 Dec 2018 23:29:11 +0100, Marek S napisał(a):

> Ok, tak też sądziłem...
> 
> Jeszcze na koniec jedno pytanie o ORM. Czy jest jakiś konwerter SQL -> 
> laravelowy ORM? 

Nie spotkałem się z czymś takim i wątpię, by ktoś miał potrzebę stworzenia
tak skomplikowanego narzędzia.

> Chodzi o to, że o wiele łatwiej napisać złożone zapytanie w SQL. Przy
> prostych strukturach nie ma problemu. Dość często potrzebne są np.
> podzapytania agregujące do tworzenia kryteriów wyboru w zapytaniu
> nadrzędnym i inne ekwilibrystyki z wieloma JOINami wszelkiej maści.

Prawdopodobnie większość z nich będziesz mógł zastąpić relacjami Eloquenta
i operacjami na nich.

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

[toc] | [prev] | [next] | [standalone]

#15995

W dniu 2018-12-29 o 00:03, Borys Pogoreło pisze:
> Prawdopodobnie większość z nich będziesz mógł zastąpić relacjami Eloquenta
> i operacjami na nich.

Być może zbyt wcześnie panikuję :-) ORM wydaje mi się póki co sztuczny 
środowiskiem dla nieuków bazodanowych. Z drugiej strony gadałem z 
kolegami programującymi w C#, których jest drastyczna przewaga w firmie 
i oni wszyscy jadą w ORM. Wyrażenie SQL kojarzy im się ze studiami niż z 
czymkolwiek użytecznym. Być może czas na zmiany...

-- 
Pozdrawiam,
Marek

[toc] | [prev] | [next] | [standalone]

#16015

W dniu sobota, 29 grudnia 2018 21:24:00 UTC+1 użytkownik Marek S napisał:
> 
> Być może zbyt wcześnie panikuję :-) ORM wydaje mi się póki co sztuczny 
> środowiskiem dla nieuków bazodanowych. Z drugiej strony gadałem z 
> kolegami programującymi w C#, których jest drastyczna przewaga w firmie 
> i oni wszyscy jadą w ORM. Wyrażenie SQL kojarzy im się ze studiami niż z 
> czymkolwiek użytecznym. 

właśnie trafnie ich nazwałeś

> Być może czas na zmiany...

... pracy

[toc] | [prev] | [standalone]

Back to top | Article view | pl.comp.lang.php

csiph-web