Laravel - Namenskonventionen für Datenbanken, Tabellen und Spalten?

Question

Ich benutze Larovel eloquente Datenobjekte, um auf meine Daten zuzugreifen. Wie kann ich meine Tabellen, Spalten, Fremd-/Primärschlüssel usw. am besten benennen?

Ich fand, es gibt viele Namenskonventionen da draußen. Ich frage mich nur, welcher für Larovel eloquent Modelle am besten passt.

ich folgende Namenskonvention denke:

1. Singular Tabellennamen (zB: Post)
2. Singular Spaltennamen (zB: userId - Benutzer-ID in der Post-Tabelle)
3. Camel Gehäuse für mehrere Wörter in Tabellennamen (ex: PostComment, PostReview, PostPhoto)
4. Camel Gehäuse für mehrere Wörter in Spaltennamen (ex: vorName, postCategoryId, postPhotoId)

So könnte ich ähnliche Syntax im Controller verwenden.

$result = Post::where('postCategoryId', '4')->get(); 

Gibt es für diese Laravel Richtlinien empfohlen? Kann ich mit diesen Namenskonventionen fortfahren?

Wenn jemand bessere Vorschläge hat, werde ich sehr glücklich sein, sie zu hören.Vielen Dank!

Answer 1

Laravel hat eine eigene Namenskonvention. Wenn Ihr Modell beispielsweise User.php lautet, erwartet Laravel, dass sich die Klasse "Benutzer" in dieser Datei befindet. Es erwartet auch users Tabelle für User Modell. Sie können jedoch diese Konvention außer Kraft setzen, indem Sie eine Tabelleneigenschaft auf Ihrem Modell definiert, wie,

class User extends Eloquent implements UserInterface, RemindableInterface { 
     protected $table = 'user'; 
    } 

Von Laravel offiziellen Dokumentation:

Beachten Sie, dass wir nicht Eloquent nicht gesagt, welche Tabelle für unsere User-Modell zu verwenden, . Der Name der Klasse in Kleinschreibung und Plural wird als Tabellenname verwendet, sofern nicht explizit ein anderer Name angegeben wird. In diesem Fall nimmt Eloquent an, dass das Benutzermodell Datensätze in der Benutzertabelle speichert. Sie können eine benutzerdefinierte Tabelle angeben, indem Sie eine $table Eigenschaft auf Ihrem Modell definiert

Wenn Sie Benutzertabelle ID in einer anderen Tabelle als Fremdschlüssel dann verwenden, soll es schlingt Fall wie user_id so sein, dass es sein kann, wird automatisch im Falle einer Beziehung verwendet. Auch hier können Sie diese Konvention überschreiben, indem Sie zusätzliche Argumente in der Beziehungsfunktion angeben. Zum Beispiel

class User extends Eloquent implements UserInterface, RemindableInterface { 
     public function post(){ 
      return $this->hasMany('Post', 'userId', 'id'); 
     } 
    } 

    class Post extends Eloquent{ 
     public function user(){ 
      return $this->belongsTo('User', 'userId', 'id'); 
     } 
    } 

Docs for Laravel eloquent relationship

für andere Spalten in der Tabelle, können Sie sie nennen, wie Sie wollen.

Ich empfehle Ihnen, einmal durch die Dokumentation zu gehen.

Answer 2

Ich stimme nicht generell mit diesen Beispielen überein, die Sie beide direkt hier gezeigt haben.

Es ist sauber, wenn Sie sich die offizielle Laravel-Dokumentation ansehen, besonders in der Beziehungssitzung der Eloquent (http://laravel.com/docs/4.2/eloquent#relationships).

Tabellennamen sollten im Plural sein, d. H. "Benutzer" -Tabelle für Benutzermodell.

Und Spaltennamen müssen nicht in Camel Case, sondern Snake Case sein. Sehen Sie, es ist bereits beantwortet: Database/model field-name convention in Laravel?

Es ist zu gewöhnlich, Sie können sehen, es ist wie die RedBeanORM: die Snake Case für Spalten, auch wenn Sie andere versuchen. Es wird empfohlen, zu vermeiden, dass die Tabellennamen aufgrund der Methode, die Sie über das Model-Objekt aufrufen können, um auf ihre Beziehungen zuzugreifen, mit den Spaltennamen wiederholt werden müssen.

Answer 3

Die standardmäßigen Namenskonventionen für Tabellen können leicht zu Konflikten mit der Installation mehrerer Pakete führen, die im Übrigen dieselben Klassennamen haben können. Eine Lösung wäre, Tabellen wie folgt zu benennen: [vendor]. [Package]. [Class], was mit der Verwendung von Namespacing in Laravel übereinstimmt.

Bearbeitet: Die Verwendung von Punkten in Tabellennamen wird jedoch nicht empfohlen. Würde es eine alternative Konvention geben, um sicherzustellen, dass Entwickler einer modular aufgebauten Anwendung sich keine Gedanken über existierende Tabellennamen machen müssen.