[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]

1. Zacznijmy od tego, że filmy i aktorzy tworza relację wiele-do-wielu, wiele-do-jednego.
2. O jaki konkretny ORM chodzi?

[WebCM]

1. Masz napisane wiele-do-jednego (n:1).
2. O wszystkie - jak to jest w dobrze napisanych ORM - a konkretny przypadek to framework Phalcon.

[Crozin]

Miało być: [...] tworzą relację wiele-do-wielu, NIE wiele-do-jednego..

Żeby było dobrze powinno być:

[PHP] pobierz, plaintext 
class Film {
  private $id;    // id
 
  private $title; // string
 
  private $actors; // array[Actor], czy jakaś obiektowa kolekcja, np. ArrayColection[Actor] z Doctrine
}
 
class Actor {
  private $id;
 
  private $firstName;
  private $lastName;
 
  private $films; // ponownie, tablica/kolekcja jednak tym razem obiektów Film
}
[PHP] pobierz, plaintext 

Do tego, każda z tych klas powinna mieć zestaw funkcji get/set/has/add/etc dla każdej z właściowości.

[viking]

Ale w sumie masz to dokładnie opisane w dokumentacji http://docs.phalconphp.com/en/latest/refer...-between-models więc jaki jest problem? Skoro już wykorzystujesz jakiś FW to w pierwszej kolejności postaraj się szukać rozwiązań dla niego specyficznych.

[WebCM]

W Doctrine i ORM-ach w Javie klucze obce są mapowane na obiekty:

[JAVA] pobierz, plaintext 
public class Aktor
{
    private int ID;
    private String imie;
    private Film film; //uprośćmy, że aktor gra tylko w 1 filmie
}
 
//Do ID filmu odwołujemy się tak
aktor.getFilm().getID()
 
//Ostatecznie z publicznymi polami
aktor.film.ID
[JAVA] pobierz, plaintext 

Prawda, że proste? Twórcy Phalcona obrali inną ścieżkę. Czy właściwą? Pole film otrzyma ID powiązanego rekordu zamiast obiektu klasy Film. W przykładach nazwy tabel i klas są w liczbie mnogiej. Najlepiej pokażę do na przykładach:

[PHP] pobierz, plaintext 
$aktor = Aktorzy::findFirst($id);
$nazwa_filmu = $aktor->filmy->nazwa; //filmy - nazwa klasy
$id_filmu = $aktor->film_id; //film_id - nazwa kolumny w tabeli
$id_filmu = $aktor->film; //a jak sobie nazwiemy tak kolumnę
[PHP] pobierz, plaintext 

Nie trzeba żadnych adnotacji i plików konfiguracyjnych. Wystarczy tylko ustawić wirtualne klucze obce, bo tego Phalcon sam nie odczyta z bazy. Oczywiście wszystko możemy zmienić po swojemu, a nawet dodać aliasy dla nazw pól i relacji. Tu powstają pytania:

1. Czy w porządnym ORM potrzebujemy pól z ID powiązanych rekordów?
2. Czy z tego powodu zmieniać nazwy kolumn z "film" na "filmId" lub "film_id"?

[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.

[WebCM]

Phalcon jest podatny na SQL Injection w ograniczonym zakresie. Przykład:

[PHP] pobierz, plaintext 
//localhost/kontroler/akcja/1=1
public function akcjaAction($id)
{
  $user = User::findFirst($id);
}
[PHP] pobierz, plaintext 

Rozwiązania tego problemu:

1. Sprawdzać, czy $id zawiera cyfry - ctype_digit
2. Ręcznie ustawić ścieżki w klasie Router, aby parametr zawierał tylko cyfry
3. Napisać własne metody typu User::getById($id) i tam zadbać o bezpieczeństwo