Дилемма именования таблиц: Единственное или Множественное число? [закрыто]

У меня был тот же вопрос, и после прочтения всех ответов здесь я определенно придерживаюсь ЕДИНИЧНОГО подхода по следующим причинам:

Причина 1. (Удобство). Проще придумывать названия в единственном числе, чем во множественном. Объекты могут иметь неправильные формы множественного числа или вовсе не иметь множественного числа, но всегда будут иметь форму в единственном числе (с некоторыми исключениями, например, "News").

• Customer
• Order
• User
• Status
• News

Причина 2. (Эстетика и порядок). Особенно это заметно в сценариях "мастер-деталь", где так удобнее читать и выравнивать по названию, а также иметь более логичный порядок (Сначала мастер, затем деталь):

• 1. Order
• 2. OrderDetail

По сравнению с:

• 1. OrderDetails
• 2. Orders

Причина 3. (Простота). Соединяя все воедино: названия таблиц, первичные ключи, отношения, классы сущностей... лучше работать с одним именем (в единственном числе), чем с двумя (единственное число для класса, множественное для таблицы, единственное для поля, единственное-множественное в "мастер-деталь"...)

• Customer
• Customer.CustomerID
• CustomerAddress
• public Class Customer {...}
• SELECT FROM Customer WHERE CustomerID = 100

Как только вы понимаете, что имеете дело с "Customer", вы можете быть уверены, что будете использовать одно и то же слово для всех ваших взаимодействий с базой данных.

Причина 4. (Глобализация). Мир становится все меньшим, у вас может быть команда разных национальностей, не у всех английский является родным языком. Не носителю английского языка будет проще думать о "Repository", чем о "Repositories", или о "Status" вместо "Statuses". Наличие имен в единственном числе может привести к меньшему количеству ошибок, вызванных опечатками, и сэкономить время, не заставляя задумываться "Child или Children?", что, в свою очередь, улучшает производительность.

Причина 5. (А почему бы и нет?). Это может даже сэкономить вам время на написание, сократить место на диске и даже продлить срок службы вашей клавиатуры!

• SELECT Customer.CustomerName FROM Customer WHERE Customer.CustomerID = 100
• SELECT Customers.CustomerName FROM Customers WHERE Customers.CustomerID = 103

Вы сэкономили 3 буквы, 3 байта и 3 дополнительных нажатия клавиш 😃

И, наконец, вы можете называть те, кто мешает с зарезервированными именами, например:

• User > LoginUser, AppUser, SystemUser, CMSUser,...

Или использовать пресловутые квадратные скобки [User].

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

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

Поскольку мы обычно что-то делаем со строками, почему бы не использовать имя в винительном падеже? Если у нас есть таблица, в которую мы записываем больше, чем читаем, почему бы не использовать дательный падеж? Это таблица чего-то, так почему бы не использовать родительный падеж? Мы бы этого не делали, потому что таблица определяется как абстрактный контейнер, который существует независимо от своего состояния или использования. Изменение существительного без точной и абсолютной семантической причины — это абсурд.

Использование неизменяемого существительного является простым, логичным, регулярным и независимым от языка.

Если вы используете инструменты объектно-реляционного отображения (ORM) или планируете использовать их в будущем, я бы рекомендовал Singular.

Некоторые инструменты, такие как LLBLGen, могут автоматически исправлять множественные названия, такие как Users, преобразуя их в User, не изменяя само имя таблицы. Почему это важно? Потому что при отображении вы хотите, чтобы это выглядело как User.Name, а не как Users.Name, или, что еще worse, из некоторых моих старых баз данных с именами таблиц, например, tblUsers.strName, что просто запутывает код.

Мое новое правило — оценивать, как это будет выглядеть после преобразования в объект.

Одна таблица, которая не вписывается в новое именование — это UsersInRoles. Но всегда будут те несколько исключений, и даже в этом случае это выглядит вполне хорошо, как UsersInRoles.Username.

Другие пользователи уже дали неплохие ответы по поводу "стандартов", но я хотел бы добавить следующее... Возможно, что "User" (или "Users") на самом деле не является полным описанием данных, содержащихся в таблице? Не стоит слишком увлекаться названиями таблиц и их спецификой, но, возможно, что-то вроде "Widget_Users" (где "Widget" — это название вашего приложения или сайта) было бы более уместно.

Вопрос о том, почему таблицы в базах данных именуются в единственном числе, рассматривается в контексте различных соглашений об именовании. Хотя многие люди предпочитают называть таблицы во множественном числе, существует определенное соглашение, требующее именовать таблицы в единственном числе. Это связано с тем, что каждая запись в таблице представляет собой отдельный объект, что логично отражается в названии.

На одном сайте (http://vyaskn.tripod.com/object_naming.htm#Tables) утверждается, что таблицы должны иметь имена в единственном числе, что соответствует общепринятому соглашению в некоторых средах разработки. В то же время другой сайт (http://justinsomnia.org/writings/naming_conventions.html) утверждает иное, однако я не согласен с его подходом.

Как уже упоминалось другими пользователями, эти соглашения — лишь рекомендации. Выбор соглашения, которое подойдет именно вам и вашей команде или проекту, имеет первостепенное значение. Частая смена между единственным и множественным числом, а также нерегулярное сокращение слов могут вызвать путаницу и снизить читаемость кода. Поэтому важно выбрать одно направление и придерживаться его.