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


41

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

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


Однажды у меня был сотрудник, который настаивал на том, чтобы имена таблиц были единственными, а имена представлений - множественными.
Рене Ниффенеггер

1
Есть и другие школы мысли. 1) Используйте глаголы, которые позволят выражать запросы на естественном языке, например person NAMED 'fred' EARNS 20,000(где заглавными именами являются таблицы). 2) использовать имя предприятия для множества , например PERSONNEL, PAYROLL, ORG_CHARTи т.д.
onedaywhen

3
Возможный дубликат кросс-сайта: stackoverflow.com/questions/338156/…
Ciro Santilli 事件 改造 中心 法轮功 六四 事件

Ответы:


44

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

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

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

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

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

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


2
Всегда ли это сводится к личному выбору? Что, если в одном проекте базы данных работают 2 человека, тогда один может назвать таблицы множественным числом, а другой - единственным. Нет ли веских аргументов относительно того, зачем использовать Singularили Plural?
Джон Исайя Кармона

2
@JohnIsaiahCarmona: добавил причину
gbn

3
Я согласен с использованием единственного числа как наиболее разумного. Похоже, это не популярное мнение, если вы посмотрите на подобные вопросы здесь, на SO и т. Д. Многие люди, кажется, программистски рассматривают таблицы как коллекции, которые должны иметь множественные имена. Я думаю, что, возможно, ORM могут начать ломать людей этой (плохой) привычки. Если ваши таблицы имеют множественные имена, для начала вам будет сложно различать родительские и дочерние свойства навигации и различать экземпляры и объекты коллекции для таблицы.
Джоэл Браун

4
Другая причина в пользу Singular заключается в том, что если у вас есть правило, что PK называется по имени таблицы, например, TablenameIDили TablenameCodeили tablename_id. С именами таблиц во множественном числе вы Orders.OrdersIDполучаете (что выглядит неправильно) или с тем, Orders.OrderIDгде вы используете множественное число для имен таблиц, но переходите на единственное число для префиксов столбцов.
ypercubeᵀᴹ


8

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

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

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

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

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

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


5

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

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

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

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


2
+1 хотя технически множественное число человека - это люди, и это одна из причин, почему я использую единственное число. Некоторые ORM автоматически создают таблицы для вас, и вы получаете странные сценарии, подобные этому, когда лингвистически именование не логично.
Мистер Браунстоун

5

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

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

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

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

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

...

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


1
Это слишком близко для ясности. Просто держитесь подальше от зарезервированных слов, единственного или множественного числа. Это действительно помогает при отладке сообщений об ошибках, которые взаимозаменяемо используют множество зарезервированных слов. Идеально выбирать слова из домена приложения, чтобы сделать его более подходящим для использования / пользователя.
Пользователь Emacs

что значит "слишком близко для ясности"?
Нил Макгиган

1
Это означает ненужные более высокие издержки на расшифровку сообщений об ошибках. Например, order by и orders в сообщениях об ошибках синтаксиса. Или попытаться отладить пользователя и пользователей в сообщениях об ошибках аутентификации.
Пользователь Emacs

IMO PurchaseOrder, PortalUser, UserSession лучше, чем просто Order, User, Session, так что единственное число может хорошо работать в этом сценарии
Джон Джей

1

Я считаю, что таблица 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

Имеет смысл до тех пор, пока вам не придется писать для овец в seep.get ... Изгибайте правила, будьте гибкими.
Пользователь Emacs

Правда, некоторые контейнеры - это слова с существительным, не являющимся множественным числом, например, «доступ». но можно изменить, используя: «для access_record в доступе».
Длинк

Приводит меня в смятение, когда я вижу объекты ссылок. Как насчет таблицы ссылок между книгами и авторами? «BooksAuthors» выглядит и звучит ужасно, но «BookAuthor» выглядит и звучит лучше. Затем вы попадаете в слова, которые имеют нечетные окончания для множественного числа (статусы) или являются неправильными существительными (ребенок против детей). ИМО - мир боли в глазах!
blobbles

Привет, @blobbles множественное число будет BookAuthors, а не BooksAuthors. Так что все еще выглядит естественно. BookPublishers, BookFormats и т. Д.
dlink

Читаемость всегда хорошая, но речь идет не о предложении, а о местах, из которых мы получаем данные. например table.field, так author.authorNameпрекрасно. Получить имя автора из таблицы автора. Когда есть только один автор, множественное число тоже выглядит плохо. authors.authorNameкогда есть только один автор? Это больше сбивает с толку IMO. Это, конечно, стало намного лучше, теперь мы покончили со стилем предложения mysql_ и имеем более удобные способы доступа к данным :)
Джеймс

1

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


Этот ответ на самом деле ничего не добавляет к целой теме! Вы не можете ответить на проблему, называя таблицу "заказ", например! Лично я использую французские слова, когда английский не сработает - ordre, groupe ... Всегда используйте поле комментариев вашей таблицы, чтобы объяснить свой выбор! Но действительно важно иметь соглашение и придерживаться его !
Verace

Как это ничего не добавляет? Я добавил, что единственное число - это на мой взгляд меньше работы. Если у вас другое мнение, не мое, пожалуйста, не обесценивайте мое мнение. «Заказы» не являются проблемой, проблема заключается в более сложных множественных числах, которые не являются такими, как «Категории», которые я видел с ошибками во всех видах комбинаций, вызывающих ненужную работу.
ColacX

0

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


0

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

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

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

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

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

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


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

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

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.