Laravel - Соглашения о присвоении имен в базе данных, таблицах и столбцах?

Question

Я использую красноречивые объекты данных laravel для доступа к моим данным, что лучший способ назвать мои таблицы, столбцы, внешние/первичные ключи и т. Д.?

Я обнаружил, что существует множество соглашений об именах. Мне просто интересно, какой из лучших подходит для ларавельных красноречивых моделей.

Я имею в виду следующее соглашение об именах:

1. Сингулярные имена таблиц (например: Post)
2. Сингулярные имена столбцов (например: идентификатор пользователя - идентификатор пользователя в почтовом таблице)
3. верблюд корпус для нескольких слов в именах таблиц (например: PostComment, PostReview, PostPhoto)
4. Верблюжий корпус для нескольких слов в именах столбцов (например: ПгвЬЫате, postCategoryId, postPhotoId)

Таким образом, я мог бы использовать аналогичный синтаксис в контроллере.

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

Есть ли рекомендации по Laravel для этого? Могу ли я продолжить эти соглашения об именах?

Если у кого-то есть лучшие предложения, я буду очень рад их услышать. Спасибо большое!

Answer 1

У Laravel есть собственное соглашение об именах. Например, если ваше имя модели - User.php, тогда Laravel ожидает, что класс «Пользователь» будет находиться внутри этого файла. Он также ожидает, что users таблица для модели User. Тем не менее, вы можете изменить это соглашение, определив свойство таблицы на вашей модели, как,

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

С Laravel официальной документации:

Обратите внимание, что мы не сказали красноречивый, какой стол, чтобы использовать для нашей модели пользователя , В нижнем регистре имя множественного числа класса будет использоваться как имя таблицы , если явно не указано другое имя. Таким образом, в этом случае Eloquent предполагает, что модель User хранит записи в таблице users. Вы можете указать пользовательскую таблицу, определив $table свойства на модели

Если Вы будете использовать пользовательский идентификатор таблицы в другую таблицу в качестве внешнего ключа, то он должен быть змеей случай как user_id, так что это может быть используемый автоматически в случае отношение. Опять же, вы можете переопределить это соглашение, указав дополнительные аргументы в функции отношений. Например,

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

Для других столбцов в таблице, вы можете назвать их, как вам нравится.

Я предлагаю вам пройти документацию один раз.

Answer 2

Я не согласен в целом с этими примерами, которые вы оба показали прямо здесь.

Это чистая информация, если вы посмотрите официальную документацию Laravel, особенно на сеансе отношений Eloquent (http://laravel.com/docs/4.2/eloquent#relationships).

Названия таблиц должны быть во множественном числе, то есть в таблице пользователей для модели пользователя.

И названия колонок не обязательно должны быть в чехле Верблюда, но в случае с Змеей. См. Ответ уже ответил: Database/model field-name convention in Laravel?

Это слишком обычное явление, что вы можете видеть, что это похоже на RedBeanORM: Снейк для столбцов, даже если вы попробуете другой. Рекомендуется избегать повторения имен таблиц с помощью столбцов из-за метода, который вы можете вызвать из объекта Model для доступа к их отношениям.

Answer 3

Соглашения об именах таблиц по умолчанию могут легко вызвать конфликты с установкой нескольких пакетов, которые могут иметь случайные имена тех же классов. Решение было бы назвать таблицы как: [vendor]. [Package]. [Class], что соответствует тому, как применяется пространство имен в Laravel.

Отредактировано: Использование точек в именах таблиц не рекомендуется. Будет ли альтернативное соглашение использовать, чтобы разработчикам модульного встроенного приложения не нужно было беспокоиться о существующих именах таблиц.