Temat: doctrine vs propel

Wojciech Sznapka:

Szymon Kapturkiewicz:
Przygotowuję zespół do pracy przy dwóch bardzo dużych projektach, które będą prowadzone równolegle. Jak do tej pory nie miałem do czynienia z Doctrine. Tylko Propel od symfony w wersji 1.0. Można ponarzekać na bardzo mozolne pisanie kodu, ale powoli do tego już przywykłem...

Zastanawiam się nad tym co byście doradzali, czy warto się przesiadać na Doctrine przy tworzeniu serwisów o oglądalności ok. 5 000 000 page views miesięcznie?

Jakie są plusy, a jakie zalety?
Nie wspominając o wciąż ubogiej bibliotece pluginów dla doctrine.

przy takiej odwiedzalności zrobiłbym raczej doctrine dla backendu (panelu administracyjnych) a dla krytycznych elementów frontendu zapytania wprost przez PDO, chyba, że porządnie zaprojektujesz cache, co byłoby bardzo wskazane.

Co do plusów:
- DQL
- DQL
- DQL
- behaviory (również pisanie własnych)
- obsługa relacji (daleko wygodniejsza niż w propelu)
i inne, których teraz ciężko mi sobie przypomnieć. W każdym bądź razie, ile razy siadam do projektu w Propelu to mi zawsze czegoś brakuje, co jest w doctrine.

btw. co rozumiesz pod pojęciem "uboga biblioteka pluginów"? Jakich konkretnie brakuje?

sam stosuje Doctrine tylko w obszarach "sporadycznej" aktywnosci - przy odpowiedniej architekturze systemy mozna swobodnie przepinac miedzy ORM a 'czystymi' zapytaniami... co do ORM'ow to ostatnie testy zajetosci pamieci wygladaly nastepujaco: doctrine + zend = ok 10 mega na skrypt, zend + PDO = 3 mega... jednak czas reakcji na poprawki, refactoring, zmiana funkconalnosci to wszystko przemawia za ORM (z mojego doswiadczenia wynika, ze koszt zmian jest znaczaco nizszy, gdy poprawiamy obszar oparty o ORM) i z tego tez powodu staram sie to dosc rozsadnie wywazyc, co gdzie i jak uzywac... wychodze z zalozenia, ze wszystko jest dla ludzi :) ram tani jak woda a procesory w cenie kukurydzy :) warto juz przy analizie biznesowej rozpatrzec, gdzie mozna uzyc ORM a gdzie nie, torche trzeba wywrozyc, moze wyciaganac z klienta wiecej niz chce... a to po to zeby sie nie wpakowac z ciezka artyleria tam gdzie wystarczy snajper ;)Krzysztof Staniszewski edytował(a) ten post dnia 11.12.09 o godzinie 00:19

Temat: doctrine vs propel

pojawiła się wersja 1.5 Propela. wprowadzono rozwiązania jak w Doctrinie;)

tutaj więcej w temacie:
http://www.propelorm.org/wiki/Documentation/1.5/WhatsNew

Temat: doctrine vs propel

Wynik ciekawego testu:





chyba w aktualnej sytuacji ( Propel 1.4 vs Doctrine 1.2 ) nie ma wątpliwości, że Doctrine to oki ale w wersji 2.0, która aktualnie jest w wersji beta;]

testy wykonane na podstawie: http://code.google.com/p/php-orm-benchmark...unk/doctr...

PHP: 5.3.1 ( ze względu na Doctrine 2 )

Temat: doctrine vs propel

Paweł Smoliński:
Całkowicie się z tobą zgadzam, ale i tak pozostanę przy Doctrine ;) Gdy używałem Propla także posiłkowałem się widokami tylko i wyłącznie po to, aby mógł korzystać z procedur składowych (a dokładniej sprawa polegała na tym, iż pewna funkcja (procedura składowa) foo(u1, u2) zwracała pewien współczynnik opisujący zależności między userem o id=u1 a userem o id=u2. Następnie musiałem wyciąć z listy userów, dla których wynik ten był mniejszy od pewnej ustalonej wartości w (czyli foo(u1, u2) < w) i wynik całej tej operacji wrzucić do

> pagera. W Proplu bez widoków jest to niewykonalne, w Doctrinie

sprawę załatwia się od ręki.
Oczywiście można unikać robienia podwójnych joinów, bawić się aliasami i tworzyć setki widoków, których można byłoby uniknąć (pod warunkiem oczywiście, iż zapomnimy o wrzucaniu do kodu czystych SQLek) ale IMHO tworzy to niepotrzebny i z reguły ciężko modyfikowalny bałagan w kodzie ;)

Przy takim podejściu jak podwójny join trzeba się jeszcze zastanowić czy nie lepiej zrobić dwóch zapytań albo zmienić przynajmniej na jeden join i subquery. Czasami jest to po prostu wydajniejsze. Ale fakt jest to temat na dużo szerszą dyskusję.

Temat: doctrine vs propel

Aleksander Wons:

Wojciech Sznapka:

bez obrazy, ale to mi od razu zalatuje na jakiś błąd logiczny, po co 1000 rekordów na raz?

3 type wyścigów w jednej kategorii. Powiedzmy, że po 25 zawodników na typ. W sezonie mamy np. 10 wyścigów. Do tego dochodzi info o najlepszym czasie okrążenia dla zawodnika w danym wyscigu. I jeszcze musimy pobrać info o klubie zawodnika, a ten co sezon może jeździć w innym klubie.

Ja też nie sądziłem, że to może tak wyglądać, ale niestety nie da się tego za bardzo przeskoczyć. Można by to nieco zoptymalizować, ale też moim zadaniem było tylko dokończyć tak, żeby działało zgodnie z życzeniem klienta.
Gdybym miał to przerabiać to na 100% zrobiłbym to inaczej niz jest. Ale to i tak nie zmienia faktu, że danych do wyciągnięcia jest po prostu dużo.

Dodaj mechanizm cachowania wyników z DB i na pewno wzrośnie dostępność strony. Bez tego wygląda, że nie da się przeskoczyć. To jest najprostszy i najszybszy sposób. Nie musisz ruszać samego projektu bazy danych i żadnych zapytań.

Temat: doctrine vs propel

Szymon Kapturkiewicz:
Przygotowuję zespół do pracy przy dwóch bardzo dużych projektach, które będą prowadzone równolegle. Jak do tej pory nie miałem do czynienia z Doctrine. Tylko Propel od symfony w wersji 1.0. Można ponarzekać na bardzo mozolne pisanie kodu, ale powoli do tego już przywykłem...

Zastanawiam się nad tym co byście doradzali, czy warto się przesiadać na Doctrine przy tworzeniu serwisów o oglądalności ok. 5 000 000 page views miesięcznie?

Jakie są plusy, a jakie zalety?
Nie wspominając o wciąż ubogiej bibliotece pluginów dla doctrine.

Tak czy siak, przy takiej ilości wejść bez jakiegoś mechanizmu cachowania się nie obejdzie. Po prostu sam serwer bazy danych będzie zamulał stronę. Na pewno przydałby się jakiś load balansing i inne takie zabiegi dla obsługi tylu wejść.

Jeśli chodzi o problem z pamięcią to w naszych czasach przy dużych projektach to nie powinien być aż taki duży problem. Wykupujesz większą maszynę w razie problemu i po kłopocie.

Osobiście pracuje na Propel od wersji 1.0. Generalnie spisuje się dobrze, aczkolwiek należy zwracać uwagę co generuje Tobie sam Propel i czy nie należy czasami skorzystać z SQL, dla lepszej wydajności.

PozdrawiamAndrzej Piotrowski edytował(a) ten post dnia 21.06.10 o godzinie 00:21

Temat: doctrine vs propel

Andrzej Piotrowski:

Dodaj mechanizm cachowania wyników z DB i na pewno wzrośnie dostępność strony. Bez tego wygląda, że nie da się przeskoczyć. To jest najprostszy i najszybszy sposób. Nie musisz ruszać samego projektu bazy danych i żadnych zapytań.

Tyle to wiem :D Tylko problem nie jest w czasie dostępu a ilości zjadanej przez Doctrine pamięci. Nawet jak wyciągnę te obiekty z cache-a to dalej będą zajmowały tyle samo pamięci :)

Temat: doctrine vs propel

Jeśli ktoś rozważa, który ORM użyć - Doctrine2 czy Propel 2, to polecam zestawienie najważniejszych cech obu ORM-ów opublikowane na blogu Vertabelo: http://www.vertabelo.com/blog/technical-articles/side-...
Jest to wyłącznie zestawienie najbardziej istotnych funkcjonalności, bez oceniania i wydawania wyroków. Warto podkreślić, że porównane zostały najnowsze wersje Doctrine i Propela, co jest o tyle ważne, że w sieci na razie bardzo trudno jest znaleźć jakiekolwiek zestawienia tych wersji.