Witam!
Może mi ktoś wytłumaczyć jak działa warstwa abstrakcji? Nie jest problemem zrobić klasę DB, a w niej metody typu select, update, delete itd... Problemem nie są również transakcje. Problemem jest dla mnie jak przekazywać skomplikowane zapytania (kilka JOIN)questionmark.gif Nie wiem też czy dobrze rozumiem idee smile.gif Jako plusy widzę możliwość logowania zapytań wraz z ich czasem wykonania i ewentualne cachowanie zapytań. Ważna jest również możliwość zmiany silnika bazy. No i to jest problem smile.gif Bo jeśli (w najgorszym razie) do klasy DB dodam metode QUERY i przekazaną do metody zmienną podstawię jako argument pg_query (np) to już odpada zmiana silnika sad.gif Jaki jest sens czegoś takiego:

[PHP] pobierz, plaintext 
<?php
$result = $objDB->select("SELECT id FROM \"sesja_uzytkownika\" 
						  WHERE identyfikator_sesji_ascii = '" . $this->php_session_id . "' 
						  AND ((now() - utworzono) < ' " . $this->session_lifespan . " seconds') 
						  AND user_agent='" . $strUserAgent . "' 
						  AND ((now() - ostatnie_dzialanie) <= '".$this->session_timeout." seconds' 
							   OR ostatnie_dzialanie IS NULL)"
						);
?>
[PHP] pobierz, plaintext 

Równie dobrze mogę pisać SQL prosto w kodzie sad.gif Wydaje mi się, że dodatkowa warstwa abstrakcji dla każdej tabeli załatwi sprawę, ale też nie do końca to rozumiem smile.gif Niby, że mam wszystkie potrzebne zapytania zamknąć w metodach klasy do tej tabeli? Trochę bez sensu IHMO...

Temat był pewnie omawiany wielokrotnie, jednak nie znalazłem żadnego sensownego omówienia tematu. Patrzyłem na gotowe warstwy abstrakcji (PDO), ale tam też używa się zwykłego SQL'a... o co tu chodzi? Chciałbym unikać SQL i mieć go tylko w jednym miejscu - w warstwie abstrakcji! smile.gif Czy to aż tak wiele. Będę wdzięczny jeżeli ktoś mi to łopatologicznie wyjaśni! smile.gif

Czy przekazywanie do metody SELECT tablicy z kolumnami do pobrania plus zmienna zawierająca warunek ma sens? Czy taka funkcja może zwracać tablicę z tablicą wyników, liczbą wyników itp? Czy to jest wydajne? Co ze złożonymi zapytaniami? Czy bez osobnych klas dla każdej tabeli się nie obejdzie? BTW widzę tam masę metod...

A czytałeś o ORM i np. Propel?

No dobra! Jeśli dobrze rozumiem to każda tabela staje się obiektem. Jak jednak są realizowane złożone zapytania? jak to podane wyżej jako przykład? Czy w kalasie DB_USER_SESSION ma się znaleźć poprostu metoda getSessionID, i zwracać np 0 jeśli nie ma poprawnych wpisów? jak to się ma do wydajności ?

Sorry, że Was tak molestuje tymi moimi wątpliwościami, ale chciałbym dokładnie wiedzieć co i jak (nie chodzi mi o najlepsze, najszybsze (gotowe) rozwiązania) Chciałbym wiedzieć poprostu jak to się robi i DLACZEGO właśnie tak Z góry dziękuję za wyrozumiałość...
Pozdrawiam

I jeszcze jedna sprawa Jeśli z każdej tabeli zrobię sobię obiekt to jest pewien problem. Podoba mi się założenie, że sposób przechowywania danych nie powienien mieć związku z ich przewarzaniem. Jeśli zmienię strukturę bazy danych to co wtedy?

Poszukałem trochę To co ja uważałem za warstwe abstrakcji dla bazy to jest poprostu sterownik. To on zawiera takie metody jak SELECT,UPDATE,DELETE,COMMIT,CONNECT i zapewnia pewien interface wyższym warstwom. Co do tych wyższych warstw to dalej nic nie wiem.

Nie ma problemu. Zazwyczaj strukturę bazy definiujesz w schemacie db(w Propelu schema.xml), a tam możesz w razie zmian uzględnić je, ale nadać obiektom i metodom stare nazwy. Problem pojawia się, gdy używasz czystego SQL'a. Tak czy siak, małe modyfikacje nie są trudne do poprawy, a większe nie sprzyjają ogólnie projektowi...

Poczytaj o Propelu, to Ci się sporo rozjaśni w tej sprawie. Zajrzyj też do dokumentacji symfony i temat na Forum Pro.

Dzięki Ludvik Temat przejrzałem, wylądował w zakładkach, jutro dokładnie przeczytam... Widzisz, ja już stary jestem, wszystko lubie mieć zrobione własnoręcznie, wtedy jakoś tak lepiej się czuję Na chwilę obecną skłaniam się do połączenia mini sterownika zależnego od silnika bazy + klasy dostępowe coś jak w propelu (narazie chyba implementowane ręcznie). Myślałem też dzisiaj w pracy, żeby wykorzystać PDO (ze względu na implementację w C) w połączeniu z metodami dostępowymi. Chodzi mi o to, żeby wszystkie zapytania do bazy przechodziły przez jeden punkt. Umożliwi to logowanie zapytań, błędów, cachowanie, czasy wykonania itd. Na pewno tu jeszcze wrócę bo pytań mam masę Na chwilę obecną dziękuję wszystkim za odpowiedzi i czekam na dalsze sugestie na temat abstrakcji baz danych.
Pozdrawiam!

Wersja 1.3 Propela porzuci Creole na rzecz PDO, co powinno być dobrą rekomendacją... Co prawda, używając PDO nie usuwasz całkowicie zależności od silnika DB, ale zyskujesz na wydajności (kiedyś w PHP Solutions było porównanie i PDO wypadło bardzo dobrze) i wygodzie. Testy jednostkowe są znacznie prostsze, gdy używasz obiektów zamiast funkcji typu mysql_xxx...

Wydaje mi się, że warto użyć Propela jako podstawy i ewentualne modyfikacje wprowadzać w klasach pochodnych generowanych przez Propela. Pisanie własnego ORM mija się raczej z celem, bo jest to dosyć skomplikowane zagadnienie, gdy chcesz to zrobić porządnie.

Osobiście też czuję lekki niedosyc, bo brakuje mi implementacji Nested Sets w Propelu, która pojawi się dopiero ze wspomnianą wersją 1.3... Pojawią się też unikalne obiekty - jedna instancja na jeden wiersz z bazy, co troszkę poprawi działanie całości...

Pozdrawiam...

Myślałem o tym, że nie baza jest obiektem tylko każde zapytanie Są pewne plusy Jeśli chodzi o Nested Sets to nie rozumiem czemu to takie fajne? Co jest trudnego we własnej implementacj? Czy to rekurencyjnie czy interacyjnie (nie ma chyba takiego słowa)... Pewnie jest coś o czym nie wiem
Pozdrawiam!