Я считаю, что стандартная практика для обозначения таблиц в MySQL заключается в использовании множественных имен.
Классы, ссылающиеся на эти таблицы, также должны быть множественными?
Например, представьте, что у вас есть таблица под названием «Пользователи», которая используется для целей аутентификации.
Эта таблица будет описана в классе сущности более или менее подобным образом с использованием доктрины ORM:
namespace Company\BlogBundle\Entity; use Doctrine\ORM\Mapping as ORM; /** * @ORM\Entity * @ORM\Table(name="Users") */ class Users { /** * @ORM\Id * @ORM\Column(type="integer", name="user_id") * @ORM\GeneratedValue(strategy="AUTO") * * @var integer $userId */ protected $userId; /** * @ORM\Column(type="string", length="255", name="first_name") * * @var string $userName */ protected $userName; ... }
Это верно?
Или должен ли класс «Пользователи» быть назван в единственном числе («Пользователь»)?
Класс, представляющий одну строку базы данных (сущность), должен иметь сингулярное имя. Поведение Doctrine 2 по умолчанию – это имя таблицы базы данных одинаково. Вы можете переконфигурировать его в каждой аннотации @Table, если хотите, но я предлагаю вам придерживаться соглашений об именах Doctrine – единственное имя для таблицы базы данных также приемлемо.
Если ваш класс должен представлять экземпляр объекта реального мира, то семантически я бы сказал, что единственная форма может быть единственной. Таблица базы данных используется для хранения нескольких элементов, поэтому там может быть выбрана множественная форма. В любом случае это не имеет большого значения, пока вы согласны.
В базе данных это множественное число, потому что это множество из них; таблицу множества пользователей. Как объект, это особая вещь; один пользователь. Обычно я придерживаюсь своих классов.
Я также подписываюсь на использование имен таблиц с сингулярным именем, потому что строка представляет один элемент таблицы так же, как объект представляет один экземпляр класса. Единственными исключениями могут быть, когда каждая строка таблицы содержит, например, сериализованные (или эквивалентные) элементы, то есть «соседи» местоположения.