ActiveRecord, ORM |
Tematy na forum Pro mogą zakładać jedynie moderatorzy. W otwartych tematach może pisać każdy, kto ma coś fachowego do powiedzenia. Wszystkie posty nie wnoszące nic do tematu będą natychmiast usuwane, a ich autorzy dostaną ostrzeżenie.
Jeśli uważasz, że jakiś temat jest warty dyskusji na tym forum, zgłoś go w temacie Propozycje.
ActiveRecord, ORM |
6.07.2007, 07:48:08
Post
#41
|
|
Grupa: Zarejestrowani Postów: 487 Pomógł: 7 Dołączył: 7.01.2004 Skąd: Warszawa Ostrzeżenie: (0%) |
Pamiętaj, że różnice implementacji przy różnych ORMach są czasami olbrzymie, zawsze możesz znaleźć swoją własną implementację bazując na dostępnych wzorcach. Wystarczy zajrzeć pod wspomniany adres.. Data Source Architectural Patterns Table Data Gateway, Row Data Gateway, Active Record, Data Mapper. Object-Relational Structural Patterns Identity Field, Foreign Key Mapping, Association Table Mapping, Dependent Mapping, Embedded Value, Serialized LOB, Single Table Inheritance, Class Table Inheritance, Concrete Table Inheritance, Inheritance Mappers. Object-Relational Metadata Mapping Patterns Metadata Mapping, Query Object, Repository. -------------------- Łukasz Dywicki
Independent Java and open source software consultant. Blog - Java, OSGi, integracja oprogramowania.. |
|
|
21.07.2007, 23:55:44
Post
#42
|
|
Grupa: Zarejestrowani Postów: 22 Pomógł: 0 Dołączył: 23.11.2004 Ostrzeżenie: (0%) |
Mnie przed ORMami odstrasza jedna rzecz. Jeżeli mam powiedzmy użytkownika, który należy do jakiejś grupy. I teraz chce dostać jego imię, nazwisko i nazwę grupy do której należy to w przybliżeniu musiałbym zrobić coś takiego: $user = new User($id); $group = $user->getGroup(); Co powoduje wykonanie dwóch selectów zamiast jednego używającego złączenia tabel. Poza tym wszędzie gdzie czytam o ORMach to zawsze podawany jest przykład taki jak powyżej, który ma być uzasadnieniem tego, że to jest fajne. Ale co w sytuacjach kiedy potrzebuję mieć zapytanie z kilkoma złączeniami, limitem, sortowaniem, funkcjami specjalnymi typu CONCAT, funkcjami agregującymi itp? Mam wtedy dla takiego zapytania zrobić perspektywę i użyć wzorca Active Record do opisania tej perspektywy? Niby tak można ale wtedy w bazie będę miał 10 razy więcej perspektyw niż tabel... ormy obsluguja transakcje,rozne rodzaje fetchingu etc... btw , zawsze mozesz zrobc RAW SQL jesli jakies zapytania przez orm robia sie bardzo uciazliwe.. |
|
|
30.07.2007, 15:53:15
Post
#43
|
|
Grupa: Zarejestrowani Postów: 5 Pomógł: 0 Dołączył: 30.07.2007 Ostrzeżenie: (0%) |
A jak Propel radzi sobie z dziedziczeniem w klasach ?
Przykladowo mam klase Contractor i dziedziczy po niej Client oraz Supplier Dostawca i klient maja wiele wspolnych pol wiec warto by bylo zastosowac tu relacje 1-1. W efekcie mamy 3 klasy w tym 2 dziedziczace i odpowiadajace im tabele. O ile nie ma problemu z np.: wstawieniem listy transakcji do klienta (ralacje 1-n) to nie wiem czy propel poradzi sobie w sytuacji kiedy to 1 klasa bedzie de facto zapisywac do 2 tabel ? Jakies doswiadczenia w tym temacie ? Moze inne ORM niz propel ? 2 temat to kwestja konwersji UML do schematu bazy danych. Googluje juz od kilku dni ale jedyne co znalazlem to MetaL. Nie dziala on jednak rewelacyjnie i konwertuje to swojego formatu a nie do schema.xml znanego z propela. |
|
|
31.07.2007, 18:56:32
Post
#44
|
|
Grupa: Zarejestrowani Postów: 793 Pomógł: 32 Dołączył: 23.11.2006 Skąd: Warszawa Ostrzeżenie: (0%) |
2 temat to kwestja konwersji UML do schematu bazy danych. Googluje juz od kilku dni ale jedyne co znalazlem to MetaL. Nie dziala on jednak rewelacyjnie i konwertuje to swojego formatu a nie do schema.xml znanego z propela. A może coś opisanego tutaj ? -------------------- Algorytmy w PHP, czy ktoś o tym słyszał?
Dlaczego tak mało kobiet programuje? ponieważ nie zajmują się głupotami. |
|
|
31.07.2007, 20:14:53
Post
#45
|
|
Grupa: Zarejestrowani Postów: 487 Pomógł: 7 Dołączył: 7.01.2004 Skąd: Warszawa Ostrzeżenie: (0%) |
A jak Propel radzi sobie z dziedziczeniem w klasach ? Propel radzi sobie z dziedziczeniem w klasach, aczkolwiek nie jest to "wypasiona" opcja. Gdyby nazywać to zgodnie z nomenklaturą jest to dziedziczenie zorganizowane na jednej tabeli z dyskryminatorem, czyli kolumną której wartości wskazują z czym mamy do czynienia. Opis wraz z diagramem UML - Single Table Inheritance. Dokumentacja Propela: Advanced Object Model. Przykładowy kod: Kod Client / \ Enterprise PrivateClient \ CompanyWorker
-------------------- Łukasz Dywicki
Independent Java and open source software consultant. Blog - Java, OSGi, integracja oprogramowania.. |
|
|
27.11.2007, 00:15:41
Post
#46
|
|
Grupa: Zarejestrowani Postów: 5 Pomógł: 0 Dołączył: 30.07.2007 Ostrzeżenie: (0%) |
Ponownie wróciłem do tematu.
Widzę, że tutaj nie za dużo się wydarzyło. Ostatnio zrobilem release tematu podczas tworzenia abstrakcyjnego kontrolera CRUD do ZF. Dziwi mnie fakt ze podczas dyskusji o ORM nikt nie wspomniał o wygodzie przy tworzeniu warstwy widoku. Przykładowo bibloteka patForms potrafi na podstawie obj. propela wygenerować nam formularz do wpisywania/edycji danych. Możemy oczywiście go dowolnie edytować w pliku XML. Obecnie stosuje zestaw Zend Framework + Propel + Smarty. Zastanawiam się jednak nad PEAR::DBObject Testowaliście obydwa pod względem wydajności, wygody użycia ? Wspomnę jeszcze o DataGrid. Co polecacie ? Propel dostarcza niby klasę pozwalającą na integrację z DataGrid z PEAR ale od razu mówie.. wersja jest przestarzała i lepiej wogóle jej nie ruszać. Ja straciłem 3 h, poznałem dokładnie budowę DataGrid iw końcu napisałem prawie od nowa klasę integrującą. Ale teraz efekt jest bardzo przyjemny. |
|
|
27.11.2007, 10:59:33
Post
#47
|
|
Grupa: Zarejestrowani Postów: 898 Pomógł: 48 Dołączył: 2.11.2005 Skąd: Poznań Ostrzeżenie: (0%) |
Myślę, że o widoku nikt nie wspomniał, bo temat nie dotyczy widoku :-)
A tak na serio to jeśli już mówimy o wygodzie projektowania aplikacji działających w oparciu o ORM to dla mnie nic nie przebije generacji paneli administracyjnych w symfony filmik Kilka linii w pliku konfiguracyjnym i masz wszystko - przeglądanie, dodawanie danych, walidację danych, łączenie danych z wielu tabel po kluczach obcych itd itp. Jak to pierwszy raz zobaczyłem to się popłakałem, że tyle czasu traciłem na takie bzdety ;-) Zwykły crud to przy tym zabawka. Inny przykład też z symfony to umieszczenie danych testowych w tabeli z pliku yml - piękna sprawa przy robieniu pierwszych testów. |
|
|
27.11.2007, 11:55:44
Post
#48
|
|
Grupa: Zarejestrowani Postów: 487 Pomógł: 7 Dołączył: 7.01.2004 Skąd: Warszawa Ostrzeżenie: (0%) |
Kwestia ORM i widoku nie wiąże się pośrednio, ponieważ kluczowe są tu metadane i informacje o strukturach z których ORM korzysta.
Propel ułatwia nam zadanie ponieważ mamy wygenerowany kod z informacjami na temat powiązań itp (bodajże katalog metadata obok innych wygenerowanych klas). W przypadku ActiveRecord informacje te są zapisane jako fragment definicji w modelu (has_many, many_to_many itp). Wystarczy zatem bezpośrednio podpiąć się pod metadane i umiejętnie je wykorzystać a nie będziemy potrzebowali generatorów. Kiedyś dawno, dawno temu dopisywałem adaptery wiążące Propel-Agavi-Smarty tak by tworzyć nowe widoki i wyszukiwarki możliwie łatwo. Dodatkowo powiązałem sobie etykiety z klas z i18n, przez co przy polach wyszukiwania nie musiałem męczyć się z dorzucaniem labeli. Robiły to za mnie po prostu pluginy dopisane do smarty. Kod, który nie jest wierną kopią tego co napisałem aczkolwiek prezentuje zbliżoną funkcjonalność.
Dodatkowym elementem, który sobie wytworzyłem było wiązanie np inputów z wartościami niektórych pól. Dzięki temu nie trzeba podawać atrybutu value, id i tak dalej, ponieważ wszystko to można wyciągnąć dynamicznie z requestu w samym pluginie.
Po stronie PHP dodałem jeszcze element który nazwałem, może niezbyt trafnie, wrapperem. Jego użycie było bardzo proste i sprowadzało się w poszczególnych akcjach do podobnego kodu:
Przy odrobinie wysiłku akcja mogła by sprowadzać się tylko do:
Napisanie takiego "czegoś" to na prawdę ciekawe zadanie a integracja z zewnętrznymi bibliotekami może dać na prawdę sporo możliwości. Np kod, który udało mi się stworzyć w końcu zaczęła używać osoba, która nie była programistą tworząc widoki od ręki bazując tylko na strukturze bazy danych. Jedyna rzecz jaką musiała potrafić to dobrze sklecić szablon Smarty. Programista wówczas pisał logikę i nie zawracał sobie głowy resztą. -------------------- Łukasz Dywicki
Independent Java and open source software consultant. Blog - Java, OSGi, integracja oprogramowania.. |
|
|
26.02.2008, 00:54:43
Post
#49
|
|
Grupa: Zablokowani Postów: 167 Pomógł: 2 Dołączył: 15.02.2004 Ostrzeżenie: (30%) |
Używam Zend Frameworka. Chciałbym oddzielić warstwę logiki biznesowej od warstwy dostępu do danych. Dla warstwy logiki biznesowej najlepiej pasowałoby zastosować wzorzec "Domain Model". Jak wykorzystać "Zend_Db_Table" wraz z "Zend_Db_Table_Row" jako warstwy dostępu do danych? Mogę prosić o praktyczne zastosowanie?
|
|
|
26.02.2008, 20:05:52
Post
#50
|
|
Grupa: Zarejestrowani Postów: 36 Pomógł: 0 Dołączył: 9.11.2003 Ostrzeżenie: (0%) |
Testowałem różne dostępne rozwiązania ORM, najlepiej moim zdaniem wypada DoctrinePHP. Jest bardzo prosty w implementacji, wygodny, ma ogromne możliwości. Także jeżeli komuś zależy na takich "ułatwieniach" to zdecydowanie polecam. Ja jednak zostanę przy pisaniu zapytań i "czystym" PDO. Powód? Pod koniec moich testów odpaliłem sobie Apache Benchmark.
Na bazie testowej (tabele: artykuly, users, tagi, artykuly_x_tagi - jakie tu panują relacje chyba widac ) porównałem wydajność dwóch aplikacji: 1) w moim frameworku (prosty mvc, sesje, pare bibliotek, widok obsluguje TemplateLite) prosta aplikacja pobierająca rekordy z bazy, zapytania w SQL poprzez PDO; 2) te same zapytania w Doctrine i wyniki wyprintowane, bez żadnej "obudowy" w postaci frameworka, także teoretycznie powinno być wydajniej Wyniki - prawie czterokrotnie większa wydajność pierwszej opcji. Wniosek - ORM to piękna rzecz, ale w dużych projektach gdzie wydajność to priorytet, lepiej sobie darować. |
|
|
27.02.2008, 10:37:16
Post
#51
|
|
Grupa: Zarejestrowani Postów: 793 Pomógł: 32 Dołączył: 23.11.2006 Skąd: Warszawa Ostrzeżenie: (0%) |
@regis87
I moim zdanie się mylisz, jak jest duży projekt bez ORM to masakra. A co do wydajności, to jak masz wiele do wielu to tak zawsze jest, ale pamiętaj że korzystając z ORM najbardziej zachłanne rzeczy można przepisać na niższy poziom, czyli wykorzystując tylko abstrakcję bazy danych. Do tego tak często nie doceniane widoki (przez większość zwane perspektywami) się przy stosowaniu ORM bardzo przydają. Bo nie można zaprzeczyć, że ORM jest bardziej obciążający niż prosty dostęp, ale tak samo programowanie obiektowe (w tym wspomniane MVC) też jest wolniejsze od proceduralnego, jednak jakoś nikt na to nie zwraca zbytniej uwagi, chyba że jest jakiś punkt gdzie wydajność siada, ale to się małe fragmenty kodu zmienia, nie całą aplikację. "Nie używajmy ORM", to prawie jakby mówić "piszmy w asemblerze". Może trochę przesadzam, ale jak się nie przestawia korzyści, i gada głupoty że w dużych projektach to lepiej bez... to mnie to irytuje. Oczywiście zawsze się znajdzie coś co musi być napisane w asemblerze, ale to są na prawdę specyficzne rzeczy, a nie typowe aplikacje. -------------------- Algorytmy w PHP, czy ktoś o tym słyszał?
Dlaczego tak mało kobiet programuje? ponieważ nie zajmują się głupotami. |
|
|
27.02.2008, 10:52:09
Post
#52
|
|
Grupa: Moderatorzy Postów: 4 465 Pomógł: 137 Dołączył: 26.03.2004 Skąd: Gorzów Wlkp. |
W 100% popieram. Za całą obiektową otoczką takiego Propela lecą zwykłe zapytania SQL, a jedynie konieczność utworzenie obiektów ze zwracanego wyniku lekko spowalnia. Lepiej zatem (jak mówi Sedziwoj) pisać z użyciem ORM, a potem jedynie odnaleźć bardzo czasochłonne operacje i je przepisać. Zauważ, że jak coś jest bardzo zasobożerne, to jest to zazwyczaj operacja na ogromnych ilościach danych na raz. Z autopsji powiem, bo dziś w nocy troszkę potestowałem, że operacje z wyszukiwaniem LIKE %xxx% na 250 000 rekordach to 3.49 s gołe zapytanie i 3.6 s Propel (wliczam utworzenie paczki z danymi).
Pozdrawiam. -------------------- To think for yourself you must question authority and
learn how to put yourself in a state of vulnerable, open-mindedness; chaotic, confused, vulnerability, to inform yourself. Think for yourself. Question authority. |
|
|
27.02.2008, 12:09:19
Post
#53
|
|
Grupa: Zarejestrowani Postów: 487 Pomógł: 7 Dołączył: 7.01.2004 Skąd: Warszawa Ostrzeżenie: (0%) |
Może w kwestii dużych projektów. Panowie nie zapominajmy, że duże projekty zazwyczaj stoją na dedykowanych maszynach, gdzie nie martwimy się tym, że nasz dostawca odetnie vhosta z racji na generowane obciążenie. Z drugiej strony - jakie są różnice czasowe, bo procentowo jest to dużo, ale czy będzie to odczuwalne dla użytkownika?
Nie pracowałem może w największych projektach, ale ilość linii kodu szła w tysiące czy też dziesiątki tysięcy. Gdyby każdy miał klepać zapytania, bo "tak jest wydajniej" to stracili byśmy na tym zbyt wiele czasu. Podstawą w takich wypadkach jest ORM i dobrze skonstruowane DAO, tak by nie pojawiały się metody duplikujące swe działania (pytanie - które DAO co może odczytywać). Zaoszczędzasz czas upraszczając sobie pracę z pozyskanymi danymi - w dalszym ciągu masz obiekty, w których możesz zawrzeć jakieś w miarę proste operacje, a nie półśrodki w postaci tablic bądź map. Chodzi o to, że gdy ORM stworzy Ci obiekt powiedzmy faktury - tworzysz metodę isPaid a w niej masz jakiś warunek. Normalnie, pisząc strukturalnie - ten warunek przerzuciłbyś do kontrolera bądź, co gorsza, widoku. Gdy coś się zmienia w sposobie uznawania płatności i masz ORM modyfikujesz tylko jedną metodę. Nie szukasz wszystkich warunków, gdzie dany typ danych się przewija. Popatrzcie proszę na ORM przez perspektywę tego, co może dać nam obiekt . -------------------- Łukasz Dywicki
Independent Java and open source software consultant. Blog - Java, OSGi, integracja oprogramowania.. |
|
|
27.02.2008, 17:22:42
Post
#54
|
|
Grupa: Zarejestrowani Postów: 36 Pomógł: 0 Dołączył: 9.11.2003 Ostrzeżenie: (0%) |
Może źle to ująłem. Mówiąc o dużych projektach nie mam na myśli bardzo rozbudowanych aplikacji z ogromną funkcjonalnością. Chodzi mi raczej o serwisy, które wystawione są na działanie bardzo dużej liczby użytkowników, a więc wywołań. Sam rozmiar bibliotek ORM daje do myślenia - po skompilowaniu DoctrinePHP do pojedyńczego pliku, zajmuje on prawie 700KB. Bez kompilacji jest jeszcze gorzej, bo wszystko rozbite jest na nie dziesiątki, ale setki plików klas. Z tego co wiem podobnie wygląda to w przypadku Propela.
Ale... jakiś czas temu trafiłem na bibliotekę realizującą wzorzec ORM, o nazwie Pork. Jest bardzo mała, szybka... trzeba to przetestować http://www.schizofreend.nl/Pork.dbObject |
|
|
27.02.2008, 17:27:41
Post
#55
|
|
Grupa: Moderatorzy Postów: 4 465 Pomógł: 137 Dołączył: 26.03.2004 Skąd: Gorzów Wlkp. |
W przypadku Propela masz kilka plików + te, które sam wygenerujesz.
Rozumiemy, o co chodzi z dużą ilością odwiedzin, ale w którym momencie upatrujesz koniec sensowności ORM? Ile odwiedzin dziennie? -------------------- To think for yourself you must question authority and
learn how to put yourself in a state of vulnerable, open-mindedness; chaotic, confused, vulnerability, to inform yourself. Think for yourself. Question authority. |
|
|
27.02.2008, 17:55:22
Post
#56
|
|
Grupa: Zarejestrowani Postów: 36 Pomógł: 0 Dołączył: 9.11.2003 Ostrzeżenie: (0%) |
Nie potrafię tego oszacować. Ale kiedy wydajność staje się problemem, w ORM w pierwszej kolejności szukałbym oszczędności...
|
|
|
28.02.2008, 00:47:10
Post
#57
|
|
Grupa: Moderatorzy Postów: 4 465 Pomógł: 137 Dołączył: 26.03.2004 Skąd: Gorzów Wlkp. |
Jeśli dysponujesz dedykowanym serwerem, to moim zdaniem problemy zaczną się gdzieś w okolicach kilkudziesięciu tysięcy odsłon dziennie. Bardzo mało serwisów osiąga takie liczby. Ja bym w tym wypadku zainwestował w jakiś cache dla modelu danych, czy nawet w cachowanie całych stron www. Dopiero gdyby to nie pomogło, szukałbym optymalizacji zapytań. Nie będę rzucał liczbami, ale np. forum.php.pl mimo, że jest popularnym, średniej klasy forum nie osiąga jeszcze pułapu, przy którym zdycha sprzęt ;p
Pozdrawiam -------------------- To think for yourself you must question authority and
learn how to put yourself in a state of vulnerable, open-mindedness; chaotic, confused, vulnerability, to inform yourself. Think for yourself. Question authority. |
|
|
28.02.2008, 18:36:04
Post
#58
|
|
Grupa: Zablokowani Postów: 167 Pomógł: 2 Dołączył: 15.02.2004 Ostrzeżenie: (30%) |
Używam Zend Frameworka. Chciałbym oddzielić warstwę logiki biznesowej od warstwy dostępu do danych. Dla warstwy logiki biznesowej najlepiej pasowałoby zastosować wzorzec "Domain Model". Jak wykorzystać "Zend_Db_Table" wraz z "Zend_Db_Table_Row" jako warstwy dostępu do danych? Mogę prosić o praktyczne zastosowanie? W sumie jakby nie było, to połączenie Zend_Db_Table_Row z DomainModel to wzorzec wypisz wymaluj.... ActiveRecord Mam pytanie do osób, które korzystają z wzroca Active Record. Czy implementujecie w nim logikę biznesową? Przykład:
|
|
|
28.02.2008, 18:40:32
Post
#59
|
|
Grupa: Zarejestrowani Postów: 493 Pomógł: 0 Dołączył: 14.06.2003 Skąd: Tomaszów Lubelski/Rzeszów Ostrzeżenie: (0%) |
@up: TAK
-------------------- |
|
|
2.03.2008, 22:49:39
Post
#60
|
|
Grupa: Zarejestrowani Postów: 36 Pomógł: 0 Dołączył: 9.11.2003 Ostrzeżenie: (0%) |
Skończyłem testy, pork.dbObject. Jest imponujący pod względem wydajności i małych rozmiarów, ale ma ten mankament, że aby obsługiwać relacje pola w tabelach muszą być nazywane według ustalonego schematu. Ten schemat tak naprawdę wymusza PRAWIDŁOWE nazewnictwo pól: pole primary nazywa się ID_obiekt, pola będące kluczami relacji mają nazwy odpowiadających kluczy primary itd... ale wiadomo jak to wygląda w praktyce, rzadko zdarzają się tak ładnie skonstruowane bazy
Autor mówi, że to właśnie takie ograniczenie pozwala na tę oszczędność kodu. Ale w planach ma dodanie funkcjonalności tworzenia relacji "ręcznie". Ten post edytował regis87 2.03.2008, 22:50:56 |
|
|
Wersja Lo-Fi | Aktualny czas: 26.09.2024 - 18:33 |