26
votes

I'm using laravel eloquent data objects to access my data, what is the best way to name my tables, columns, foreign/primary keys etc?

I found, there are lots of naming conventions out there. I'm just wondering which one best suits for laravel eloquent models.

I'm thinking of following naming convention:

  1. Singular table names (ex: Post)
  2. Singular column names (ex: userId - user id in the post table)
  3. Camel casing for multiple words in table names (ex: PostComment, PostReview, PostPhoto)
  4. Camel casing for multiple words in column names (ex: firstName, postCategoryId, postPhotoId)

So with this, I could use similar syntax in the controller.

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

Are there any recommended Laravel guidelines for this? Can I proceed with these naming conventions?

If someone has better suggestions, I will be very happy to hear them.Thanks a lot!

4
you can use them as you need. but the problem will be you have define them properly to be used automatically in case of relations.Sougata Bose

4 Answers

35
votes

Laravel has it's own naming convention. For example, if your model name is User.php then Laravel expects class 'User' to be inside that file. It also expects users table for User model. However, you can override this convention by defining a table property on your model like,

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

From Laravel official documentation:

Note that we did not tell Eloquent which table to use for our User model. The lower-case, plural name of the class will be used as the table name unless another name is explicitly specified. So, in this case, Eloquent will assume the User model stores records in the users table. You may specify a custom table by defining a $table property on your model

If you will use user table id in another table as a foreign key then, it should be snake-case like user_id so that it can be used automatically in case of relation. Again, you can override this convention by specifying additional arguments in relationship function. For example,

    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

For other columns in table, you can name them as you like.

I suggest you to go through documentation once.

6
votes

I don't agree in general with these examples you both have shown right on here.

It is clean if you take a look at the official Laravel documentation, especially in the Eloquent's relationship session (http://laravel.com/docs/4.2/eloquent#relationships).

Table names should be in plural, i.e. 'users' table for User model.

And column names don't need to be in Camel Case, but Snake Case. See it is already answered: Database/model field-name convention in Laravel?

It is too usual you can see it is like the RedBeanORM: the Snake Case for columns, even if you try other one. And it is adviced to avoid repeating the table names with column ones due to the method you can call from the Model object to access their relationships.

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

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

The default table naming conventions can easily cause conflicts with the installation of multiple packages who may have incidentally the same class names. A solution would be to name tables as: [vendor].[package].[class], which is in line with how namespacing in Laravel is applied.

Edited: Using dots in table names is not recommended though. Would there be an alternative convention to use to ensure developers of a modular built application do not need to worry about existing table names.