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

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

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

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

  • Имена уникальных таблиц (например: Post)
  • Сингулярные имена столбцов (например: userId - идентификатор пользователя в таблице сообщений)
  • Корпус Camel для нескольких слов в именах таблиц (например, PostComment, PostReview, PostPhoto)
  • Корпус верблюда для нескольких слов в именах столбцов (например: firstName, postCategoryId, postPhotoId)

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

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

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

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

Ответы

Ответ 1

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

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

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

Обратите внимание, что мы не сказали Eloquent, какую таблицу использовать для нашей модели User.     В нижнем регистре, множественном имени класса будет использоваться имя таблицы     если другое имя не указано явно. Итак, в этом случае, Красноречивый     предположим, что модель User хранит записи в таблице пользователей. Вы можете указать     пользовательская таблица, определяя свойство $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');
        }   
    }

Документы для красноречивых отношений Laravel

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

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

Ответ 2

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

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

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

И имена колонок не обязательно должны быть в Case Camel, а в случае с Snake. См. Ответ уже ответил: Соглашение о названии поля базы данных/модели в Laravel?

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

Ответ 3

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

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