[ORM] Jak prawidłowo powiązać encje?, Klucze obce i nazewnictwo Opcje

[WebCM]

Istnieją następujące tabele w bazie:

FILMY
- ID
- tytul

AKTORZY
- ID
- film (klucz obcy do FILMY.ID)
- imie

Załóżmy następujące klasy:

[PHP] pobierz, plaintext 
class Film
{
  public $id;
  public $tytul;
}
class Aktor
{
  public $id;
  public $film; //niektóre ORM używają __get(), więc musi być private/protected
  public $imie;
}
[PHP] pobierz, plaintext 

Chcę napisać kod zgodny z przyjętymi zasadami i jednocześnie czytelny. Powstają pytania:

1. Jak nazwać kolumny, które są kluczami obcymi?

Najłatwiej nazwać kolumnę film, ale nie wszystkie ORM sobie z tym poradzą ze względu na konflikt nazw.

[PHP] pobierz, plaintext 
<?php
$wartosc = $aktor->film->tytul;
 
// jeśli pole $film jest publiczne, wystąpi błąd, bo $film zawiera ID filmu
// jeśli pole $film jest prywatne, otrzymamy tytuł filmu, jeśli ORM sobie poradzi
?>
[PHP] pobierz, plaintext 

2. Czy do klasy encji powinien trafić także ID powiązanego rekordu?

[PHP] pobierz, plaintext 
class Aktor extends Encja
{
  public $ID;
  public $filmid; //zakładając, że nazwa kolumny w bazie to filmid
  public $imie;
  private $film; //pole w zasadzie zbędne, to tylko informacja dla IDE
 
  //Niektóre ORM-y wymagają zdefiniowania powiązań między encjami
  public function inicjuj()
  {
    $this->nalezyDo('filmid', Film::class, 'ID'); //pole filmid odwołuje się do ID encji Film
  }
 
  //A także trzeba podać nazwę tabeli
  public function nazwaTabeli() { return 'AKTORZY'; }
}
[PHP] pobierz, plaintext 

Zamiast funkcji można użyć także adnotacji lub pliku konfiguracyjnego. Przykład wyżej ma pole $filmid, ale do relacji odwołujemy się poprzez metodę magiczną __get(). Czy to zbyt nie komplikuje kodu? Może większość bibliotek ORM od razu pobiera powiązane encje n:1. Czy w powyższym przypadku po odwołaniu do $filmid (lub $film z poprzednich przykładów) powinniśmy otrzymać ID filmu czy obiekt klasy Film?

PS. Co myślicie o potworkach typu Film::find()?

[Crozin]

Nie, nie potrzebujemy. Wręcz nie powinniśmy się zajmować tym jak powiązane są ze sobą obiekty w naszej hierarchii. Klucze obce to wewnętrzny mechanizm bazy danych, który nie powinien być odzwierciedlony w modelu obiektowym. Co innego ID pojedynczego obiektu - to już jest zwykła właściwość obiektu.

W Doctrine, które bardzo, bardzo mocno bazuje na JPA (Java) stosuje się model DataMapper oraz kieruje się zasadą, którą nazwałbym "pierwszeństwem modelu obiektowego, nad bazodanowym". IMHO jak do tej pory, najlepsze rozwiązanie jakie wymyślono w kwestii ORM-ów.