We keep table names singular, identifier columns are just "id" (Laravel will use that by default, so it saves us from writing explicit column names), and foreign key columns are basically tablename_id (e.g., a user_role pivot table would have user_id and role_id, which would associate with the user and role tables respectively).
I don't get it. If you're going to use a framework with its own conventions, why would you prefer to break the convention versus sticking with the default convention?
In laravel the table names are plural by default and "id" is the default primary key.
The pivot table is "derived from the alphabetical order of the related model names". So in your example it would be role_user, not user_role.
I don't get it. If you're going to use a framework with its own conventions, why would you prefer to break the convention versus sticking with the default convention?
Two reasons: 1) our developers prefer singular notation, and making developers' lives easy is a good thing, and 2) it's a simple modification to override the default convention and force singular across the board.
The pivot table is "derived from the alphabetical order of the related model names". So in your example it would be role_user, not user_role.
That was just an example for foreign key naming, I wasn't trying to be 100% accurate with Laravel's default functionality.
Singular or plural notation is completely up to the developer. Laravel is flexible enough that it can handle whatever convention is chosen, provided you update your app accordingly.
Use whichever works best for you.
I prefer standards and convention over developer opinion and preference.
As an example, I know a lot of developers who prefer $snake_case variable names. I personally do not care, but seeing as how ALOT of modern packages out there are all using $camelCase variable names now, I feel it is better to go with the flow and use $camelCase variables.
But speaking of developer happiness, isn't it a lot easier to name it plural and not worry about it versus having to do
protected $table = 'my_singular_name';
in every model?
I prefer standards and convention over developer opinion and preference.
As a web agency with a team of developers, we used our opinions and preferences to set company-wide standards and conventions. These are our style guide conventions, designed to keep our projects uniform. As a team, we decided that singular notation made more sense for us.
But speaking of developer happiness, isn't it a lot easier to name it plural and not worry about it versus having to do ... in every model?
We create a base model that extends Eloquent and modify the getTable() method to return singular instead of plural.
rickshawhobo said:
I prefer standards and convention over developer opinion and preference.
The standard of a database table's name describing a tuple in the table and not the contents of the table predates Laravel by about 20 years and likely 30 or 40 years. This is similar to the "id" primary key field standard of Laravel, which is not a DB industry standard. It has been a DB standard to be more clear with a name like <tuple>_id so that foreign keys in another table have the same name in the primary table. Programmatically that is difficult. Laravel does some things because it is a framework and it wants to be fast to setup. Not everything is the best option, but one of Laravel's strong points is that it does not stop you from implementing the standards you want.
Sign in to participate in this thread!
Laravel
Laravel News
Laracasts
Laravel Podcast