Laravel - conventions de nommage des bases de données, des tables et des colonnes?
j'utilise des objets de données éloquents de laravel pour accéder à mes données, Quelle est la meilleure façon de nommer mes tables, colonnes, clés étrangères/primaires, etc.?
j'ai trouvé, il y a beaucoup de conventions de nommage. Je me demande juste quel est le meilleur costume pour les modèles éloquents de laravel.
je pense à la convention de nommage suivante:
- Singulier les noms de table (ex: la Poste)
- noms de colonnes singulières (ex: userId-user id dans le post) tableau)
- boîtier de chameau pour plusieurs mots dans les noms de table (ex: PostComment, PostReview, PostPhoto)
- boîtier Camel pour plusieurs mots dans les noms de colonnes (ex: firstName, postCategoryId, postPhotoId)
donc avec ceci, je pourrais utiliser une syntaxe similaire dans le contrôleur.
$result = Post::where('postCategoryId', '4')->get();
y a-t-il des lignes directrices Laravel recommandées à cet égard? Puis-je poursuivre avec ces conventions de nommage?
si quelqu'un a de meilleures suggestions, je serai très heureux de les entendre.Merci beaucoup!
3 réponses
Laravel a sa propre convention d'appellation. Par exemple, si le nom de votre modèle est User.php
alors Laravel s'attend à ce que la classe 'User' soit à l'intérieur de ce fichier. Elle s'attend également à users
tableau User
modèle. Cependant, vous pouvez outrepasser cette convention en définissant une propriété table sur votre modèle comme,
class User extends Eloquent implements UserInterface, RemindableInterface {
protected $table = 'user';
}
à Partir de Laravel la documentation officielle:
Notez que nous n'avons pas dit Éloquent table à utiliser pour notre modèle d'Utilisateur. Le nom minuscule, au pluriel de la classe sera utilisé comme nom de la table sauf si un autre nom est explicitement spécifié. Donc, dans ce cas, Éloquent supposera que le modèle d'utilisateur stocke des enregistrements dans la table des utilisateurs. Vous pouvez spécifier un tableau personnalisé par la définition d'un
$table
propriété sur votre modèle
si vous utilisez l'identifiant de table de l'utilisateur dans une autre table comme clé étrangère alors, il devrait être snake-case comme user_id
pour qu'il puisse être utilisé automatiquement en cas de relation. Encore une fois, vous pouvez outrepasser ce convention en spécifiant des arguments supplémentaires dans la fonction relationship. Par exemple,
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 pour Laravel éloquent de la relation
pour les autres colonnes de la table, vous pouvez les nommer comme vous voulez.
je vous suggère de passer en revue la documentation une fois.
Je ne suis pas d'accord en général avec ces exemples que vous avez tous les deux montrés ici.
Il est propre si vous jetez un oeil à l'officiel Laravel de la documentation, en particulier dans l'Éloquente de la relation session (http://laravel.com/docs/4.2/eloquent#relationships).
les noms de Table doivent être au pluriel, c.-à-d. 'users' table for User model.
et les noms de colonnes n'ont pas besoin d'être dans la boîte de chameau, mais dans la boîte de serpent. Voir c'est déjà répondu: base de données/modèle de convention des noms de champ à Laravel?
c'est trop habituel, vous pouvez voir que c'est comme le RedBeanORM: le Snake Case pour les colonnes, même si vous en essayez une autre. Et il est conseillé d'éviter de répéter les noms de table avec les noms de colonne en raison de la méthode que vous pouvez appeler à partir de L'objet Model pour accéder à leurs relations.
les conventions de nommage des tables par défaut peuvent facilement causer des conflits avec l'installation de plusieurs paquets qui peuvent avoir incidemment les mêmes noms de classe. Une solution serait de nommer les tables comme: [vendeur].[paquet.][class], ce qui est en ligne avec la façon dont le namespacing dans Laravel est appliqué.
Modifié: L'utilisation de points dans les noms de tableau n'est pas recommandée cependant. Y aurait-il une autre convention à utiliser pour s'assurer que les développeurs d'une application modulaire ne besoin de s'inquiéter des noms de table existants.