Plural против единственного имени таблицы

Как я должен назвать свои таблицы при создании новой базы данных?

Singular: Clientили множественное число: Clients?

Вам решать. Просто будьте последовательны, хотя.

Лично я предпочитаю единственное число в зависимости от того, что хранится в каждой строке: «Заказ», «Продукт», «Пользователь», «Товар» и т. Д.

Это соответствует моему моделированию (через Object Role Modeling), где я использую отдельные объекты / типы.

Редактировать:

Одной из причин является то , что множественное число терпит неудачу , когда у вас есть таблицы ссылок:
Orders, Productsдал бы OrderProductsили OrdersProducts. Ни один не звучит правильно

Или таблицы истории (конечно, вы можете использовать схемы для этого):
Orders-> OrdersHistoryили (нет!) OrdersHistories? Не будет Order-> OrderHistoryбудет лучше?

Что касается единственного числа против множественного числа имен таблиц, объект, кажется спорным, но это не должно быть.

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

Все обстоит более логично для объектно-ориентированных программ, которые используют данные, если имя типа записи (и, соответственно, имя таблицы) хранится в единственном числе, поскольку оно будет соответствовать имени класса, который вы использовали бы для описания одной записи ,

Если вы затем хотите идентифицировать коллекцию в программе, вы можете использовать множественное число или, что лучше, использовать соответствующий модификатор, такой как EmployeeList или EmployeeArray.

Существует также проблема с нерегулярными множественными числами для автоматической генерации кода и программистов, которые имеют различные языковые знания или идеи о формировании множественных чисел в программе.

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

Как ответ @ gbn, я думаю, что это вопрос предпочтений, так же как и он, я рекомендую, чтобы любой ваш выбор применялся везде (по крайней мере, в этой БД). Последовательность того стоит.

Однако я предпочитаю, чтобы множественное число звучало лучше в SELECTвысказываниях:

SELECT Id, Name, Status 
FROM   Persons
WHERE  Status <> 5  --5 meaning deleted

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

«заказ» является зарезервированным словом. "заказы" не

«пользователь» - зарезервированное слово. "пользователи" не

«сессия» является зарезервированным словом. "сессий" нет

«результат» является зарезервированным словом. "результаты" не

«родственник» - зарезервированное слово. "родственников" нет

...

Это похоже на обычные слова, которые могут войти в базу данных по бизнесу. Множественные слова кажутся менее распространенными в качестве ключевых слов, чем единичные слова. Следовательно, может быть полезно использовать множественные имена таблиц, чтобы избежать конфликта с ключевыми словами SQL.

Я считаю, что таблица SQL должна иметь имена во множественном числе. Это просто читается намного лучше.

Таблицу книжных записей следует называть книгами. ORM должен использовать то же соглашение. Объект Books является коллекцией и управляет всеми записями в таблице Books. Объект Book управляет одной записью.

Это делает кодирование более естественным.

select name, publication_date from books where publication_date > '2000-01-01';

books = Books()
for book in books.get("publication_date >= '2000-01-01'"):
    print book.name

После нескольких лет работы с программированием я пришел к выводу, что плюрализация - это ненужное осложнение. Мое мнение таково, что в соответствии с философией KISS программист должен стремиться к самому ленивому и простому решению всех проблем по соображениям времени и эффективности. Таким образом, единственное число дает вам меньше работы, необходимой во всех сценариях.

Это очень личная вещь. Я использую единственную форму в течение 30 лет. Но я понимаю, почему людям нравится множественное число. Книги - авторы интересны, так как я думаю, что авторы книг не ошибаются. Книга может иметь одного или нескольких авторов. И авторы, возможно, написали одну или несколько книг (например, в соавторстве). Это также зависит от того, как вы справляетесь с книгами, написанными несколькими авторами. Я согласен с другими ответами; выберите один и будьте последовательны. Что касается зарезервированных слов вопросов. Я думаю, что это не трудно придумать имена обходных путей. user -> app_user, сессия -> app_session, заказ -> customer_order

Мы смотрим на вещи с разных точек зрения, и я думаю, что эти два лагеря определены следующим образом:

Singular («пользователь»)
Человек, который делает корреляцию между именем таблицы и тем фактом, что она представляет контейнер, который может содержать несколько строк.

Таким образом, «пользовательский контейнер» может содержать несколько строк.

Plural («пользователи»)
Человек, который не устанавливает взаимосвязь между именем таблицы и тем фактом, что он представляет контейнер. Конечно, они знают, что это контейнер, но его нет в названии.

Например, в
«картонной коробке» может быть несколько яиц, но это очевидно, так как ссылка на контейнер указана в названии, обеспечивая потенциал для нескольких яиц. Однако в единственном имени таблицы "user" ссылка на контейнер отсутствует в имени. Например, «user_container», вероятно, будет приемлемым для людей, которые предпочитают множественные имена.

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

Все это говорит, я думаю, что технически говоря единственное число является более точным, учитывая, что мы называем один контейнер, и контейнеры могут содержать несколько (или один) строк.
Людям кажется неправильным, так как они мысленно связывают имя таблицы с содержимым (множественные строки нуждаются во множественном имени), а не мысленно связывают именованный контейнер с содержимым (контейнер допускает несколько).

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

Если вы делаете проект исключительно, и нет никакой реальной причины идти тем или иным путем, делайте то, что вы считаете лучшим или просто предпочтением. Примените то же самое, когда в команде разработчиков и просто прийти к единогласному решению.