Laravel - Convenzioni di denominazione di database, tabelle e colonne?

Question

Sto utilizzando oggetti dati eloquenti di laravel per accedere ai miei dati, qual è il modo migliore per nominare tabelle, colonne, chiavi esterne/primarie ecc.?

Ho trovato, ci sono molte convenzioni di denominazione là fuori. Mi sto solo chiedendo quale si adatti meglio ai modelli eloquenti di laravel.

sto pensando di seguente convenzione di denominazione:

1. nomi di tabella singolare (es: Post)
2. nomi delle colonne singolare (es: userId - id utente nella tabella post)
3. Camel involucro più parole nei nomi delle tabelle (es: Postcomment, PostReview, PostPhoto)
4. Camel involucro per più parole nomi delle colonne (es: nome, postCategoryId, postPhotoId)

Quindi con questo, potrei usare una sintassi simile nel controller.

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

Esistono linee guida Laravel consigliate? Posso procedere con queste convenzioni di denominazione?

Se qualcuno ha suggerimenti migliori, sarò molto felice di ascoltarli. Grazie mille!

Answer 1

Laravel ha la propria convenzione di denominazione. Ad esempio, se il nome del tuo modello è User.php, allora Laravel si aspetta che la classe "Utente" si trovi all'interno di quel file. Prevede inoltre la tabella users per il modello User. Tuttavia, è possibile ignorare questa convenzione mediante la definizione di una proprietà tabella del modello di come,

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

Da laravel documentazione ufficiale:

Nota che noi non diciamo Eloquente quale tabella da utilizzare per il nostro modello User . Il nome plurale minuscolo della classe verrà utilizzato come nome tabella a meno che non venga specificato esplicitamente un altro nome. Quindi, in questo caso, Eloquent assumerà che il modello Utente memorizzi i record nella tabella degli utenti. È possibile specificare una tabella di personalizzato definendo una proprietà $table del modello

Se si intende utilizzare tabella user id in un'altra tabella come chiave esterna, allora, dovrebbe essere di serpente caso come user_id in modo che possa essere usato automaticamente in caso di relazione. Di nuovo, è possibile sovrascrivere questa convenzione specificando argomenti aggiuntivi nella funzione di relazione. Ad esempio,

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

Per le altre colonne nella tabella, è possibile assegnare loro un nome a piacere.

Ti suggerisco di consultare la documentazione una volta.

Answer 2

Non sono d'accordo in generale con questi esempi che entrambi avete mostrato proprio qui.

È pulito se si dà un'occhiata alla documentazione ufficiale di Laravel, in particolare nella sessione di relazioni di Eloquent (http://laravel.com/docs/4.2/eloquent#relationships).

I nomi delle tabelle devono essere al plurale, ovvero la tabella "utenti" per il modello Utente.

E i nomi di colonna non devono essere nel caso Camel, ma Snake Case. Vedi già risposta: Database/model field-name convention in Laravel?

È troppo comune si può vedere come RedBeanORM: il caso Snake per colonne, anche se si prova un altro. E si consiglia di evitare di ripetere i nomi delle tabelle con quelli di colonna a causa del metodo che è possibile chiamare dall'oggetto Model per accedere alle loro relazioni.

Answer 3

Le convenzioni di denominazione delle tabelle predefinite possono facilmente causare conflitti con l'installazione di più pacchetti che potrebbero avere incidentalmente gli stessi nomi di classe. Una soluzione sarebbe nominare tabelle come: [vendor]. [Package]. [Class], che è in linea con il modo in cui viene applicato lo spazio dei nomi in Laravel.

Modificato: l'uso di punti nei nomi di tabelle non è consigliato. Ci sarebbe una convenzione alternativa da usare per garantire che gli sviluppatori di un'applicazione modulare non debbano preoccuparsi dei nomi delle tabelle esistenti.