Cytat
<?php
$c = new Criteria();
// Szuka wszystkich autorow o imieniu Karl
// wyłączajac tych o nazwisku Marx
$c->add(AuthorPeer::FIRST_NAME, "Karl");
$c->add(AuthorPeer::LAST_NAME, "Marx", Criteria::NOT_EQUAL);
$res = AuthorPeer::doSelect($c); // wyniki
?>
<?php
$res = $db->authors->first_name('Karl')->last_name('Marx', '!=')->value;
?>
Cytat
Myślę, że warto się zainteresować mapowaniem obiektowo relacyjnym. Ma ono tą przewagę, że z raz opisanej bazy możemy korzystać do oporu, podczas gdy rozwiązanie przedstawione powyżej wymaga każdorazowego przepisywania części kodu.
Nie bardzo wiem czy to argument za czy przeciw mojemu rozwiązaniu, ale jeden z powodów dla których nie używam rozwiązań w rodzaju Propel jest właśnie to: moje rozwiązanie, raz napisane, może być wykorzystywane do oporu, podczas gdy w przypadku Propela za każdym razem muszę przepisać ten XML.
Każde rozwiązanie ma swoje dobre strony. Propel, jak rozumiem, zapewnia bardziej formalne traktowanie bazy danych i dużo większe możliwości budowania złożonych zapytań. StraightDB zapewnia szybkie tworzenie aplikacji i dużą czytelność kodu.
Przypuszczam, że wybór jest kwestią zastosowań, ale do aplikacji internetowych, które zwykle często i szybko się zmieniają, stosowanie zdenormalizowanego opisu bazy danych może być złym pomysłem. Struktura bazy danych może być całkiem wydajnie odczytana z samej bazy, więc zapisywanie jej osobno to moim zdaniem strata czasu.
Co więcej, bardzo wiele informacji można przyjąć domyślnie -- np. wszystkie pola kończące się na "_id" możemy uznać za obce klucze, a początek ich nazwy za nazwę tabeli do której się odnoszą (np. "users_id" odnosi się do "users.id"). Przy takim założeniu automatyczne tworzenie joinów jest dość proste.
Rozwiązanie zastosowane w
Rails (i skopiowane w
Cake) to sposób na rozszerzenie funkcjonalności joinów bez stosowania dodatkowych plików. Rodzaj joina definiuje się w Modelu (MVC), np:
<?php
class Posts extends Model
{
var $belong_to = 'users';
var $have_many = 'comments';
}
?>
Składnia jest oczywiście umowna, staram się tylko żeby rozwiązania były łatwe w użyciu, wymagały jak najmniej pisania i dobrze się czytały. Większość strat wydajnościowych wynika ze złych algorytmów, a zwięzły i czytelny kod pozwala na lepsze zrozumienie algorytmu i szybsze jego zmiany.
Cytat
@SongoQ biorąc przykład z Javy - dbanie o spójność danych jest często przenoszone na aplikację. Stąd popularność Hibernate czy Castro. Nie da się zaprzeczyć, że takie rozwiązanie spowalnia aplikację, ale "coś za coś"
To pewnie kwestia zastosowań, ale wolę obciążać fronty (czyli zwykle aplikację) niż bazę, bo fronty się łatwiej skaluje.
