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.