Symfony/Doctrine: Variationen von Entitäten

Question

Entschuldigung für die Ungenauigkeit, aber ich bin verwirrt, wie man dieses Datenbankproblem beschreibt. Ein Teil davon ist ein Datenbank-Design-Problem, der andere Teil ist, wie man die Doctrine ORM und Symfony Form Builder-Engine dafür effizient verwendet. Lassen Sie mich versuchen zu erklären:

Meine Datenbank enthält Reparaturen für Handys. Jede Reparatur ist nur für ein Mobiltelefon vorgesehen. Einige Handys haben jedoch unterschiedliche Farben. Während einige Reparaturen (wie Batteriewechsel) für alle Geräte gelten, haben einige (wie Display-Ersatz) unterschiedliche Preise abhängig von der Farbe des Geräts. Es sollte möglich sein, im Menü repair die Farbe jeder Reparatur anzugeben (wählen Sie eine, viele oder alle).

Mein aktueller DB-Design sieht wie folgt aus:

Aber das erlaubt mir nicht, die Farbe des Gerätes von der Reparatur Entity zugreifen zu können, wie Sie die Farbe eine direkte Beziehung zum Gerät hat, nicht zu reparieren. Also brauche ich eine komplexere Datenbank, die das iPhone immer noch als ein einzelnes Produkt behandelt, aber kann verschiedene Reparaturen zu seinen vielen Varianten sowie Karte Universalreparaturen zu alle Varianten zuordnen.

Sollte ich eine Join-Tabelle (repair_device_color) verwenden, die aus 3 IDs besteht? Scheint nicht hübsch. Und was ist der effizienteste Weg dies mit dem Doctrine ORM abzugleichen? Sollte ich Datenvererbung verwenden?

Answer 1

auf einer realen Welt zu reparieren Szenario Je, wo man könnte die Farbe des Gerätes durch Änderung Körper ändern, Sie möchten vielleicht devices_colous_repairs statt einer Vereinigung zusätzliche 3-Einheit erhalten:

1. device_attributes (Many-To -on mit Gerät)
2. device_repair_attrbutes (Many-To-One mit Reparatur-IDs nur, wenn das Attribut in der Reparatur-Prozess geändert.
3. Zusätzliche repair_billing Rechnung Kosten zu speichern, wie pro Standard/attrib ändern. (Many-To-One mit Repariere IDs mit optionalem Fremdschlüssel mit device_repair_attrbutes wo zutreffend.

Nur ein Vorschlag zur Normalisierung der Daten.

Answer 2

Ich wollte Ihnen eine gute Antwort geben, also brauchte ich ein bisschen Zeit, um meine Antwort zu erstellen. Dies ist vielleicht nicht perfekt, aber es wird Ihnen eine Idee geben. Das Digram, das Sie angegeben haben, ist übrigens kein ER-Diagramm.

Ich habe dies in Excel erstellt und kopiert und als Bild gespeichert. Die Tabellennamen und die ORM-Annotation sind wichtig.

Zum Beispiel finden Sie ein "Gerät" Entity mit dem Dateinamen als "src/AppBundle/Entity/Device.php" in üblichen Weise erstellen. Für die Arrays müssen Sie eine Funktion __construct() in der Entity-Klasse hinzufügen.

Als Beispiel ist es das, was der Code wie für die Geräte-Entity aussehen:

<?php 

// src/AppBundle/Entity/Device.php 
namespace AppBundle\Entity; 

use Doctrine\Common\Collections\ArrayCollection; 
use Doctrine\ORM\Mapping as ORM; 

/** 
* @ORM\Entity 
* @ORM\Table(name="device") 
*/ 
class Device 
{ 
    /** 
    * @ORM\Id 
    * @ORM\Column(name="device_id", type="integer") 
    * @ORM\GeneratedValue(strategy="AUTO") 
    */ 
    protected $device_id; 

     /** 
    * @ORM\Column(name="model", type="string", unique=true) 
    */ 
    protected $model; 

    /** 
    * @ORM\OneToMany(targetEntity="Part", mappedBy="part_device") 
    */ 
    protected $parts = null; 

... 

    public function __construct(){ 
     // This is an array of parts. 
     $this->parts = new ArrayCollection(); 

     // Create the other arrays too. 
     $this->repairs = new ArrayCollection(); 
     $this->customers = new ArrayCollection(); 
    } 

    /* 
    * This should automatically be generated by the command. 
    * php bin/console doctrine:generate:entities AppBundle/Entity/Device 
    */ 
    public function addPart($part){ 
     $this->parts[] = $part; 
    } 
} 

Hoffentlich Sie den Rest herausfinden können.Aber ich denke, das ist ein guter Anfang.