Abstrakty, klasy, Creole... itp, a po co to wszystko??? Opcje

[Aztech]

Wcześniej pisałem swoje stronki zupełnie bez ładu i składu, przyszedł jednak czas potężnego projektu (prac dyplomowa ) i czas zrobić to porządnie. Mam zatem pytanie:
1) czy pisać właśną klasę obsługi bazy danych czy skorzystać z gotówców, jeśli tak to z jakich?
2) do czego tak na prawdę służa CREOLE, ADODB, PEAR i czy warto je stosować w momencie kiedy tylko bedą obsługiwać mysql?
3) czy może, ktoś z forumowiczów ma własną klasę obsługującą połączenia z bazą danych i chce, może ją udostępnić, tudzież, czy może dać wskazówki, rady czego się wystrzegać podczas pisania własnej klady?

Wiem, że pytania są naiwne i część z nich porozsiewana jest po forum php5, ale mimo przeczytania sporej ilości postów w dniu dzisiejszych nie jestem w stanie ogarnąć tego wszystkiego i w jakiś sensowny sposób poukładać sobie w głowie. Więć stąd moje pytania

[mike]

1) czy pisać właśną klasę obsługi bazy danych czy skorzystać z gotówców, jeśli tak to z jakich?

Taki abstrakt, żeby był dobry potrzebuje sporego nakładu pracy co za tym idzie czasu pracy. A jest klika dobrych, więc po co wynajdywać koło po raz n-ty :?: No chyba że to bedzie pzredmiotem Twojej pracy.

2) do czego tak na prawdę służa CREOLE, ADODB, PEAR i czy warto je stosować w momencie kiedy tylko bedą obsługiwać mysql?

Abstrakt bazodanowy powinien w tej chwili oferować dwie podstawowe rzeczy:
1. Możliwość pisania pod dowolna bazę danych. Zawsze możesz emigrować na inną baze bez modyfikacji swojego kodu.
2. Ułatwienie korzystania z bazy, przy pomocy serii przydatnych funkcji oraz metod. Zwracanie wyników jako obiekty, statystyki, debugery, ..., co tylko zechesz. Uważam że warto, nawet jeśli nastawiasz się tylko na MySQL'a.
P.S. Creole, AdoDB owszem. Ale PEAR tutaj nie pasuje. Owszme jedną z bibliotek PEAR'a jest jakiś abstrakt, ale wywołanie go tu w całości to pomyłka.

3) czy może, ktoś z forumowiczów ma własną klasę obsługującą połączenia z bazą danych i chce, może ją udostępnić, tudzież, czy może dać wskazówki, rady czego się wystrzegać podczas pisania własnej klady?

Poszukaj, na pewno cos się znajdzie.
Ja osobiście polecam bardzo Creole'a oraz AdoDB. Obie są fajne, Creole podoba mi się bardziej, ale AdoDB ma więcej możliwości.



Temat wędruje na php, na php5 miejsca dla niego nie ma

[Aztech]

@mike_mech: dzieki za szybką odpowiedź
Pisanie samego abstraktu nie jest przedmiotem mojej pracy, ma on być tylko częścią całego systemu wspomagającego nauczanie na moim kierunku - taki właśnie system tworzę. Sam także wychodzę z założenia, że nie powinno się pisać coś co zostało już kiedyś przez kogoś stworzone, ale wolę popytać ludzi, którzy na codzień mają z tym styczność o opinie.

A tak przy okazji czy jest gdzieś jakiś polski kurs, manual Creola bo nie znalazłem (angielski mi nie przeszkadza, ale dłużej trwa jego przetwarzanie - czyt. zrozumienie)

@all: czekam na dalsze uwagi

Ten post edytował Aztech 23.11.2005, 00:52:29

[ikioloak]

Ad 1. zdecydowanie polecam ADODB. Z CREOLE kontaktu nie mialem wiec nie moge sie wypowiedziec

Ad 2. ADODB bardzo ulatwia pisanie skryptow z wykorzystaniem bazy, dlatego warto wg mnie go uzyc nawet jesli korzystasz tylko z mysql. i tak jak mowi mike_mech - a nuz sie okaze ze konieczna jest przesiadka na inny serwer bazodanowy.

PEAR jest to zestaw klas wspomagajacych pisanie. Korzystam z Mail_mime przy wysylaniu maili i poza jednym mankamentem (niedawno pytalem sie o ten mankament na forum) bardzo jestem z niej zadowolony. Z innych paczek poki co nie mialem potrzeby ani okazji korzystac, choc prezentuja sie na tyle ciekawie ze uwazam ze warto poznac ich mozliwosci (np. klasa Image_Graph).

Ad 3. Wydaje mi sie ze w momencie kiedy istnieja ww systemy jak dla mnie jest to wywazanie otwartych drzwi

[ActivePlayer]

Ad 2. ADODB bardzo ulatwia pisanie skryptow z wykorzystaniem bazy

No, to pochwal sie jakich featursów uzywasz... bo mi np. wystarcza GetArray();, GetRow();, GetOne(); i _ewentualnie_ EscapeArray();. Jak mozna sie domyslic, implementacja tych funkcji we wlasnym zakresie to okolo 50 linii kodu php. A adodb wazy nieporownywalnie wiecej.

[ennics]

możesz zamiast istniejących już klas abstrakcji spróbować PDO jako nowe rozwiązanie
technologincze dla php, ewentualnie zdefiniować dla niego dodatkową
abstrakcję.

[Aztech]

Zdecydowałem się na ADODB, z kilku powodów
1) ponieważ posiada polską dokumentację, przystępnie napisaną - być może ktoś będzię później modyfikował mój projekt, więc polska dokumentacja przyda się jak znalazł
2) jest w miarę przystępne, przykłady można łatwo znaleźć i istnieje już na rynku od dłuższego czasu, więc znane są jego wady/zalety/kłopoty i rozwiązania na różne bolączki
3) PDO moze się zmieniać, co jest wyraźnie zaznaczone w dokumentacji php i używać go można na własne ryzyko - a wiec nie jest w tym momencie rozwiązaniem przyszłościowym dla mnie, nie mogę bowiem pozwolić sobie na to, że w momencie, gdy na serwerze będzie inna wersja php 5.x.x niż ta pod, którą ja piszę, całość nie będzie działała (aczkolwiek sugestia co do PDO jest słuszna, zawsze można spróbować)

[bela]

Abstrakt? Obrzydliwe słowo, jakoś wolę angielski odpowiednik ;]

Nie prawdą jest, że jeśli będziesz używać db layera to nie ma problemów w przeniesieniem na inne bazy aplikacji. Wspólne jest tylko API db layera a same zapytanie mogą się bardzo różnić.

Ja używam praktycznie wyłącznie PDO, bo w przyszłości (czytaj. php > 5.1) będzie domyślnie zainstalowe razem z obsługą bazy.

[Aztech]

Ale piszesz własny abstrakt dla PDO, czy też zostawiasz tak jak jest?
Co do zapytań to masz rację, ale wtedy i tak masz dużo mniej roboty niż gdyby trzeba było zmieniać wszystko (na marginesie prawdopodobieństwo, że kedykolwiek moja praca zostanie przeniesiona na Oracle jest jak 1:10000)

Mam jeszcze jedno pytanko: czy AdoDB + Smarty nie będą za bardzo razem zamulały?

Ten post edytował Aztech 23.11.2005, 13:19:57

[bela]

Do PDO dopisywałem tylko klasę MyPDO, która pobierała z konfiguracji dane: user, hasło, host i tworzyło obiekt, i z metodą getPDO(), która zwracała obiekt PDO, bo przecież konstruktor tego nie zwróci.

Smarty + AdoDB nie będzie zamulać ;]

[SongoQ]

@mike_mech

Abstrakt bazodanowy powinien w tej chwili oferować dwie podstawowe rzeczy:
1. Możliwość pisania pod dowolna bazę danych. Zawsze możesz emigrować na inną baze bez modyfikacji swojego kodu.

I tu sie bardzo myslisz. Jesli nastawiamy sie na aplikacje dzialajace pod roznymi bazami danymi i zakladamy ze ten kod moze dzialac pod wszystkim to tak, wtedy od bazy oczekujemy tylko prostych zapytan, bez wykorzystania ich mozliwosci. Jesli stoworze sobie aplikacje np korzystajaca z funkcji plsql to powiedz mi jakim cudem uda mi sie ja przeniesc np ma mssqla czy mysqla? Bo ja jakos sobie nie wyobrazam. Dla mnie i tak najwazniejsza jest baza danych, bo tak naprawde dane sa przetwazane przez nia, a php tylko je prezentuje.

Tak naprawde nie da sie stworzyc wydajnej aplikacji z tym samym kodem pod kazda bazke. DB layer ma przedewszystkim sluzyc w latwosci wyciagania danych i zapominania o funkcjach typu pg_query, itd. Zakladanie ze jeden kod moze obsluzyc wiele baz jest bledym podejsciem, no chyba ze nie patrzysz na wydajnosc baz danych.

[mike]

@SongoQ, @bela_666 macie rację. Oczywiście.

Wiadomo, że specyfikacja SQL w różnych systemach bazodanowych jest różna i nie da się napisać uniwersjalnej aplikacji.

Można natomiast osiągnąć to dopóki używamy "uniwersalnych" możliwości bz danych i nie skupiamy się na specyficznych "bajerach".

Przy abstraktach IMO ważniejsze od przenośności (bo tak jak mówicie nie jest to tak naprawdę w 100% osiągalne), jest wygoda pracy i daoatkowe bajerki. Zliczanie zapytań, czasów zapytań, debugger, "plucie" wyjątkami, ...

[SongoQ]

Odnosnie PDO, jestem pod wrazeniem, przyznam sie nigdy nie korzystalem z tego ale z tego co http://www.oracle.com/technology/pub/artic...do_oracle5.html widze to jak dla ORACLE to bardzo polecam.

[ikioloak]

@ActivePlayer

No, to pochwal sie jakich featursów uzywasz... bo mi np. wystarcza GetArray();, GetRow();, GetOne(); i _ewentualnie_ EscapeArray();. Jak mozna sie domyslic, implementacja tych funkcji we wlasnym zakresie to okolo 50 linii kodu php. A adodb wazy nieporownywalnie wiecej.

nie zamierzam ci tutaj nic wymieniac, ale AdoDB oferuje jeszcze inne ciekawe metody o ktorych nie wspomniales.
Pewnie ze mozna sobie samemu napisac. Wszystko mozna samemu napisac. Ale po co? nie twierdze ze trzeba leciec na samych gotowcach bo to tez jest bzdura, ale generalnie nalezy sobie ulatwiac zycie.
Nie twierdze tez ze AdoDB jest najlepszym wyjsciem - innych klas nie mialem potrzeby testowac.
I podsumowujac, to ze AdoDB wazy zdecydowanie wiecej niz 50 linijek kodu nie neguje tego ze ulatwia pisanie

[Aztech]

Przyznam się szczerze, że zapytałem właśnie o AdoDB, Creole właśnie z paru powodów, które tu zostały wymienione, a w zasadzie z jednego głównego:
po co tworzyć coś, co już ktoś kiedyś napisał, co jest dobre, sprawdzone. Powiem szczerze, że bardzo ułatwi mi to pracę, bo teraz mogę się skncentrować na najważniejszej czesci mojej pracy dyplomowej nie przejmując się obsługą bazy danych i zapytaniami (a konkretnie ich prawidłową implementacją).

Mam jednak jeszcze jedno dodatkowe pytanie: mam rozumieć, że wszelkie problemy związane z bezpieczeństwem są w ADODB oraz Creole rozwiązane wzorowo??

[NoiseMc]

I właśnie tu nie jestem pewien co do ADODB jak mam wyłączone magic_quotes_gpc to nie slashuje mi automatycznie danych (nie wiem jak z PreparedStatement) z formularza muszę je ręcznie przygotowywać.
Z tego co wiem to twórcy Creole inspirowali się JDBC a tam podobno poziom zabezpieczenia przed SQL Injection jest dość wysoki.

Ten post edytował NoiseMc 23.11.2005, 16:03:23

[NuLL]

Ja powiem tylko jedno. Widziałem w firmie projekt - jakiś programista forsował Creole - tyleże dla 82 tabel w ktorych niektore mialy po 25 kolumn. Ilosc wygenerowanego kodu krotko mowiac przerazala.

EDIT:

Uppps - Bela_666 - ma racje pomylilem Creole z Propelem.

[SongoQ]

Ilosc wygenerowanego kodu krotko mowiac przerazala.

Kodu SQL?

[bregovic]

Creole to szajs, równie koszmarny co jakakolwiek konfiguracja w xml'u. ADODB jest uzyteczne dla dużych projektów, które potrzebują dużej ilości niestandardowych możliwości.

Dla prostej aplikacji znacznie łatwiej i szybciej (IMO) napisać własną małą klasę.

[mike]

Creole to szajs, (...)

Twoją opinię już znamy, a mógłbyś ją uzasadnić :?:

Ja uważam że Creole jest bardzo fajny. Bardzo lekka i przejrzysta klasa, nadająca się do małych oraz średnich projektów.
Ma bardzo przejrzysty kod napisany pod php5.

Jedyne wady/braki jakie w niej znalazłem, to:
1. Brak debugera (takiego jak w AdoDB), choć przy zastosowaniach małych i średnich nie jest to takie straszne.
2. Zły kod błędu w SQLException (...), ale można to bardzo łatwo poprawić (zaleta dobrego kodu);

Ale już niedługo IMO Creole zostanie wyparte prze PDO