Tomasz Zadora

Tomasz Zadora programuję

Temat: Konkretny RDBMs czy PDO ?

Zapraszam do dyskusji, czy framework powinien być dedykowany konkretnemu RDBMsowi czy też powinien raczej korzystać z PDO. Za i przeciw.

W najbliższym czasie od siebie dodam coś więcej na ten temat.
Wojciech Soczyński

Wojciech Soczyński Programista
eksplorator -
blog.wsoczynski.pl

Temat: Konkretny RDBMs czy PDO ?

A może abstrakcyjna warstwa DAL ?
Tomasz Zadora

Tomasz Zadora programuję

Temat: Konkretny RDBMs czy PDO ?

Czemu nie, tylko tutaj pokornie się przyznaje, że nie wiem co to jest i na razie nie mam czasu się dokładnie dowiedzieć :)
Wojciech Soczyński

Wojciech Soczyński Programista
eksplorator -
blog.wsoczynski.pl

Temat: Konkretny RDBMs czy PDO ?

DAL (Data Access Layer) - zunifikowany interfejs do komunikacji z różnymi źródłami danych. Bazami relacyjnymi, zorientowanymi dokumentowo, obiektowo etc
Tomasz Zadora

Tomasz Zadora programuję

Temat: Konkretny RDBMs czy PDO ?

Super.

Chciałbym tylko tutaj napisać o jednej rzeczy: generator będzie miał swoją własną bazę danych zawierającą między innymi:

* listę projektów (czyli serwisów/generowanych aplikacji)

* cechą projektu jest (w moim aktualnym prywatnym generatorze) między innymi adres/połączenie do bazy danych

* generator przechowuje listę tabel i kolumn każdej tabeli wraz z meta-informacjami - np. dziedziną danych kolumny (np. varchar/decimal/etc.)

I teraz jeżeli np. dodam nową tabelę do bazy danych projektu, albo np. usunę kolumnę z jakiejś tabeli lub zrobię cokolwiek innego z bazą danych projektu, to w generatorze klikam "instrospekcja" i te dane w bazie generatora są uzupełniane.

I teraz na bazie tych danych możemy generować wiele rzeczy - np. formularze, widoki etc.

I problem polega na tym, że w tej chwili (u mnie) jest głęboka integracja z MySQL - bo mamy tam np. polecenie "SHOW TABLES" służące do introspekcji bazy i inne. Każdy silnik bazy realizuje to inaczej.

Jeżeli byłaby taka warstwa DAL to rozumiem, że w tym momencie pośredniczyła by jakoś między konkretnym silnikiem bazy a Generatorem ? (sama baza generatora mogła by być dla ułatwienia w wybranym RDBMSie).Tomasz Zadora edytował(a) ten post dnia 13.05.11 o godzinie 13:43
Wojciech Soczyński

Wojciech Soczyński Programista
eksplorator -
blog.wsoczynski.pl

Temat: Konkretny RDBMs czy PDO ?

Ja myślę, że podejście generowania czegoś z tabeli w bazie danych jest w wielu przypadkach nieakuratne. Takie coś może się sprawdza w aplikacjach typu CRUD, które sprowadzają się do zapisu/odczytu z bazy danych, natomiast każda aplikacja, która robi coś więcej bardzo szybko dochodzi do limitu takiego podejścia. Natomiast jeżeli chodzi o generowanie ogólnie z metadanych etc opartych np. o obiekty to ma sens, poszukaj sobie w necie o NakedObjects.
Tomasz Zadora

Tomasz Zadora programuję

Temat: Konkretny RDBMs czy PDO ?

Pytanie czy jedno musi wykluczać drugie.

Chciałbym aby wszystkie 3 elementy tj.:

Framework, Generator, Aplikacja mogły być niezależne od siebie.

To znaczy:

Możesz stworzyć aplikację z generatora, ale jeżeli nie chcesz, możesz tworzyć aplikację bez niego - sam generator będzie musiał być, przynajmniej na początku tak zrobiony, bo później można sobie wyobrazić sytuację, że kolejna wersja generatora jest generowana z niego samego :)

Czyli mamy sytuację, że możemy tworzyć aplikacje CRUD z generatora (+ więcej - czemu nie) albo nie.

Dodając projekt do generatora można sobie wyobrazić, że podpinanie bazy danych projektu to opcja. Generator zarządza nie tylko bazą danych ale innymi rzeczami, np. tak prostymi jak domyślny meta title/description i tym podobne.
Wojciech Soczyński

Wojciech Soczyński Programista
eksplorator -
blog.wsoczynski.pl

Temat: Konkretny RDBMs czy PDO ?

Railsy czy Django stosują następujące podejście - najpierw piszesz model (obiekty) a framework generuje Ci baze + panel administracyjny. Myślę, że to dobry punkt wyjścia, podobnie działa zdaje się Symfony.
Tomasz Zadora

Tomasz Zadora programuję

Temat: Konkretny RDBMs czy PDO ?

Też ciekawe podejście ma swoje zalety i wady, w tym przypadku to jest coś co trzeba wybrać na zasadzie albo/albo nie można mieć obydwu rzeczy.

Plusy takiego rozwiązania:

* elastyczność jeżeli chodzi o warstwę danych

Minusy:

* trudność w wykorzystywaniu specyficznych cech danej warstwy danych (np. danego RDBMS-a) i w związku z tym prawdopodobnie niższa wydajność

Mam na myśli sytuację kiedy tworzę model i jeżeli wybiorę MySQL jako warstwę danych to FW/Generator kontroluje jak będzie wyglądać ta tabela w MySQLu, w związku z tym trudno będzie skorzystać z pewnych specyficznych cech tego silnika zwiększających wydajność.

Dlatego ja optowałbym za odwróceniem tego działania: mamy wiele warstw danych do wyboru ale teraz FW/Generator analizuje daną warstwę (dany model w tej warstwie tak jak został w niej stworzony) i na jej podstawie tworzy pewien podstawowy model, który później może być rozszerzany.

To podejście trudniejsze ale moim zdaniem da lepsze efekty - z jednej strony mamy DAL lub coś bardzo podobnego z drugiej korzystamy w pełni możliwości danego silnika/warstwy.

Można sobie tutaj wyobrazić coś w rodzaju "drivera" dla danej, wybranej warstwy danych który w tym procesie pośredniczy.
Wojciech Soczyński

Wojciech Soczyński Programista
eksplorator -
blog.wsoczynski.pl

Temat: Konkretny RDBMs czy PDO ?

Ja myślę, że nie ma się co martwić tutaj o wydajność. Panel administracyjny nie musi być demonem szybkości bo i tak używa go zwykle ograniczona ilość osób. Zresztą jest taka zasada, że optymalizuje się na końcu ;)
Tomasz Zadora

Tomasz Zadora programuję

Temat: Konkretny RDBMs czy PDO ?

Tak, zgadzam się co do panelu administracyjnego.

Optymalizacja wg. mnie to coś czym warto zajmować się już na początku - inne rzeczy optymalizuje się na początku inne podczas a inne na końcu :)

Chodzi też o to aby Generator maksymalnie przyspieszał tworzenie aplikacji (realizując zasadę DRY) budując je od razu na tyle na ile to możliwe optymalnie.

Zastanawiam się też, czy nie ma problemu jeżeli na podstawie tworzonego w FW modelu jest budowana tabela SQL a ja później tą tabelę chcę dostosować/zmienić, czy przy takim podejściu nie będzie to utrudnione.
Wojciech Soczyński

Wojciech Soczyński Programista
eksplorator -
blog.wsoczynski.pl

Temat: Konkretny RDBMs czy PDO ?

Przetestuj sobie Doctrine 2. Tam masz możliwość uaktualniania schematu bazy danych po zmianach w klasie modelu, wszystko automatycznie i bezboleśnie.
Tomasz Zadora

Tomasz Zadora programuję

Temat: Konkretny RDBMs czy PDO ?

Tylko ja właśnie myślę od podejściu w inny sposób - to znaczy FW/Generator nigdy nie ingeruje w nazwijmy to "zewnętrzną warstwę danych" - czyli np. bazę danych konkretnego projektu.

Tylko i wyłącznie może z niej czytać.

To nie znaczy, że nie można w FW tworzyć dodatkowych struktur lub rozbudowywać tego co zostało odczytane z tej warstwy.

Konkretny przykład:

Stworzyłem nową tabelę "product" w bazie danych, generator wykrywa to i tworzy model "Product" całkowicie automatycznie.

I teraz w FW mogę ten model rozbudowywać, określać dodatkowe właściwości nieobecne w tabeli bazy danych.

Jeżeli w tabeli dokonam zmian - FW to wykrywa i dokonuje podstawowych zmian w modelu "Product" :)

Jest naprawdę dużo plusów wynikających z takiego podejścia.
Wojciech Soczyński

Wojciech Soczyński Programista
eksplorator -
blog.wsoczynski.pl

Temat: Konkretny RDBMs czy PDO ?

Ja wolę podejście od modelu do bazy z kilku powodów:

1. większa elastyczność
2. model lepiej oddaje świat rzeczywisty (tabele łączące nie istnieją w realnym świecie np. i nie ma potrzeby ich generować)
3. co gdy mamy bazę danych w której nie istnieje schemat - MongoDB, bazy na chmurach, CouchDb ?
4. w pliku z klasą można zapisać więcej metadanych
Tomasz Zadora

Tomasz Zadora programuję

Temat: Konkretny RDBMs czy PDO ?

Ok temat jeszcze do przemyślenia na później.
Tomasz Zadora

Tomasz Zadora programuję

Temat: Konkretny RDBMs czy PDO ?

Wojciech Soczyński:
2. model lepiej oddaje świat rzeczywisty (tabele łączące nie
istnieją w realnym świecie np. i nie ma potrzeby ich generować)

Co dokładnie przez to rozumiesz ? Taką sytuację:

Tabela X:
id (Primary Key),
name

Tabela Y:
id (PK),
name

Tabela XY:
x_id (PK),
y_id (PK)

W tej sytuacji XY to tabela łącząca - o to chodzi ?

3. co gdy mamy bazę danych w której nie istnieje schemat - MongoDB, bazy na chmurach, CouchDb ?

Osobny "driver" dedykowany danej bazie, dana baza powinna zawierać schemat w tym sensie, że istnieją w niej dane opisujące ten schemat.

4. w pliku z klasą można zapisać więcej metadanych

Moje podejście tego nie wyklucza, mam na myśli tworzenie podstawowego modelu odpowiedzialnego za komunikację między aplikacją a warstwą danych. Przy czym podstawowy (bazodanowy) model powstaje wyniku działania "driver-a" który daną bazę analizuje. W przypadku baz relacyjnych to będzie tabela, w przypadku mongodb - "dokument" etc.

I teraz można rozszerzać ten podstawowy model (Class X extends ....) albo tworzyć całkowicie nowe modele korzystające z tego podstawowego.

Generalnie to jest sprawa podejścia w jaki sposób zaczyna się tworzyć szkielet aplikacji w sensie struktur danych:

* podejście ORM/DAL - tworzymy modele, później bazę danych

* podejście które ja preferuje: tworzę najpierw bazę danych a później modele

Moje podejście powoduje, że masz od razu dość dobrze zoptymalizowaną bazę danych, dla mnie akurat to jest ważne bo w kilku projektach działam na dużych zbiorach danych.

To jest też wybór: elastyczność czy optymalizacja.

Generalnie już podjąłem pewne decyzje i później to opiszę tutaj na grupie, jednak raczej nie będziesz z nich zadowolony.

Po za tym, po co tworzyć kolejny framework podobny do innego skoro istnieje już np. Doctrine, to będzie specyficzny framework.

Przez to sytuacja będzie "zerojedynkowa" - będą tacy którym będzie się zdecydowanie nie podobał oraz tacy dla których będzie najlepszym rozwiązaniem.
Wojciech Soczyński

Wojciech Soczyński Programista
eksplorator -
blog.wsoczynski.pl

Temat: Konkretny RDBMs czy PDO ?

Tabela łącząca - tak dokładnie o to mi chodzi.
Nie neguje twojego podejścia w sensie baza pierwsza. Tak jak mówisz jest ono dobre, kiedy wykonujemy intensywne operacje na danych (przeliczamy różne rzeczy). Natomiast tam gdzie ważne są interakcje między obiektami, to się nie sprawdza. Ja rzuciłem tylko kilka haseł tutaj i generalnie widzę, w jakim kierunku zmierza twój projekt i z tego też powodu raczej się w niego nie zaangażuje. Nasze podejścia są zbyt radykalnie różne. Natomiast myślę, że wypowiadając się na tej grupie będę mógł przynajmniej wskazać trochę inny punkt widzenia ;)



Wyślij zaproszenie do