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

1468

Академия утверждает, что имена таблиц должны быть единичными для сущности, атрибуты которой они хранят.

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

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

Мне остаться или идти?

ProfK
источник
Дуп ранее именования таблиц базы данных, множественного или единственного числа , но эта привлекла больше внимания.
2012 года
7
Я удивлен, что все больше людей не говорят: это определяется тем, что представляет собой один ряд. В одной базе данных у меня может быть таблица, строки которой представляют один-единственный виджет, а другая, которая имеет отношение «один ко многим» с этой таблицей, означает, что строки представляют множество виджетов. Без этого теряется выразительность.
andygavin
1
Я просто хочу добавить, что во всех этих обсуждениях, пожалуйста, обратите внимание, что таблица ни в коем случае не формирует или формирует то же самое как класс. Таблица - это набор элементов определенного типа, которые можно сортировать, запрашивать и т. Д. По отдельным свойствам. Класс - это структура для описания свойств и поведения определенного типа. В терминах ОО-кодирования закрывающее представление таблицы представляет собой набор объектов (независимо от того, какой ORM вы можете использовать). Это, безусловно, самый высокий рейтинг в Google по этому вопросу, поэтому, хотя вопрос закрыт, страница все еще имеет значение.
1
Я хотел бы перейти к общей практике экосистемы, в которой вы работаете. Например: В Node.js ORM, такие как Bookshelf.js или Objection.js, в основном основаны на "Knex.js". И в документации "Knex.js" вы найдете имена таблиц во множественном числе. Так что я бы пошел на множественное число в этой области. Источник: knexjs.org/#Schema-createTable
Бенни Нойгебауэр,
2
Да, я согласен. Имеет смысл иметь таблицу пользователей и одновременно называть ее «AppUser». Также имеет смысл иметь таблицу правил, применимых к конкретному типу пользователей, и называть ее «UserRules»
Arindam

Ответы:

242

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

Том Х
источник
7
Согласен. OrgUsers, AppUsers, все, чтобы избежать использования ключевого слова.
MikeW
7
-1. Пользователи таблиц (и стран, языков) могут использоваться в нескольких приложениях одновременно.
OZ_
129
Разве связывание имени схемы не устранит путаницу? AppName1.Users, AppName2.Users?
Зо
7
Я не согласен с префиксом таблицы - возможно, это должна быть схема? - но я согласен с «более информативным названием». Даже такой простой вещи, как «AppUser», будет достаточно, не вступая во все дебаты о пространстве имен.
7
Этот принятый ответ является скорее побочным комментарием и не отвечает на вопрос.
Вильями,
1827

У меня был тот же вопрос, и после прочтения всех ответов здесь я определенно остаюсь с SINGULAR, причины:

Причина 1 (Концепция). Вы можете подумать о сумке с яблоками типа «AppleBag», не имеет значения, содержит ли она 0, 1 или миллион яблок, это всегда одна и та же сумка. Таблицы - это просто контейнеры, имя таблицы должно описывать, что она содержит, а не сколько данных она содержит. Кроме того, понятие множественного числа больше относится к разговорной речи (фактически, чтобы определить, существует ли один или несколько).

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

  • Клиент
  • порядок
  • пользователь
  • Положение дел
  • Новости

Причина 3 . (Эстетика и порядок). Особенно в сценариях мастер-детали, он лучше читается, лучше выравнивается по имени и имеет более логичный порядок (сначала мастер, потом второй):

  • 1.Order
  • 2.OrderDetail

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

  • 1.OrderDetails
  • 2.Orders

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

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

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

Причина 5 . (Глобализация). Мир становится меньше, у вас может быть команда разных национальностей, не у всех есть английский как родной язык. Для программиста, не являющегося носителем английского языка, было бы легче думать о «Репозитории», чем о «Репозитории» или «Статусе» вместо «Статусы». Наличие единичных имен может привести к меньшему количеству ошибок, вызванных опечатками, сэкономить время, не думая «это ребенок или дети?», Следовательно, повышая производительность.

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

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

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

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

  • Пользователь> LoginUser, AppUser, SystemUser, CMSUser, ...

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

Nestor
источник
625
Бьюсь об заклад, если вы положите ярлык на ящик для носков, вы бы назвали его «Носки».
Крис Уорд
73
Definetelly. Трудно получить один стандарт, который работает для всех и для всех, важно то, что работает для вас. Это работает для меня, и здесь я объяснил почему, но, опять же, это для меня, и я нахожу это очень удобным.
Нестор
451
Крис, более важный вопрос: почему вы должны следовать правилам именования баз данных, когда называете ящик для носков?
Кайл Клегг
83
Этот ответ требует больше похвалы. Здесь обсуждается множество практических причин, которые я применяю к тому, почему я предпочитаю единичные имена. Альтернативные дискуссии о правильном языке применительно к множествам носят философский характер и скрывают реальную точку зрения. Singular просто работает лучше.
Джейсон
299
У меня дома есть ящик для носков, а не ящик для носков. Если бы это была база данных, я бы назвал ее таблицей «Sock».
jlembke
260

Если вы используете инструменты Object Relational Mapping или сделаете это в будущем, я предлагаю Singular .

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

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

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

Брайан Боатрайт
источник
48
Я проголосовал против, и я скажу вам, почему, потому что я не согласен. ORM по своей природе - это картография. Каждый инструмент ORM, который я когда-либо использовал, поддерживает указание имени таблицы, которая будет использоваться для сущности, если она отличается от имени сущности. Это важно, потому что вся причина, по которой мы отображаем реляционные базы данных, заключается в том, что мы можем легко создавать специальные запросы и отчеты с формами, отличными от нашей объектной модели. В противном случае мы бы все просто использовали базы данных объектов / документов.
Джошперри
25
ORM не должен диктовать имена объектов, на которые они отображаются. Смысл ORM - это абстракция объекта, дающего эту гибкость.
barrypicker
19
В моем мире я стараюсь использовать непротиворечивые имена во всем проекте, чтобы не тратить время на размышления о том, есть ли у этого экземпляра конец или нет. Тот факт, что ORM может переименовывать и быть независимым, не означает, что это помогает вашим коллегам-разработчикам.
Джон Николас
2
Некоторые ORM (как и многие инструменты программирования) имеют поведение по умолчанию, которое генерирует реализации без конфигурации ... с преимуществом ПРОДУКТИВНОСТИ. Таким образом, создание класса Employee без явного сопоставления приведет к созданию таблицы Employee по умолчанию
user919426
1
@barrypicker. Множественные имена не просто выглядят глупо в коде ORM. Множественное число также плохо выглядит в SQL, особенно когда речь идет об уникальном атрибуте. Кто никогда не писал выберите user.id из пользователей? Или, может быть ... от пользователей осталось присоединиться к thingy.user_id = user.id ...?
Сэмюэль Даниэльсон
219

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

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

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

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

Ian Mackinnon
источник
37
Наверное, самый логичный аргумент по этому вопросу, который я когда-либо видел, и я рад, что провел это время на латыни. +1 точно.
52
Ну, мне явно нужно пополнить свой словарный запас.
TJ Biddle
19
+1 Видите, это те ответы, которые нужны Интернету больше. Безупречные доказательства, использующие богатый словарный запас для выполнения совершенной логики.
OCDev
8
Я приму это к сведению в следующий раз, когда буду программировать на латыни. Тем временем пользователи перейдут в таблицу пользователей, а клиенты - в таблицу клиентов.
Caltor
8
Убежден - это не отражено. Интересно заметить , что после всего этого времени, популярные выборов «единственное число» и «множественное число» является как неправильно!
Стюарт
126

Какое соглашение требует, чтобы таблицы имели единичные имена? Я всегда думал, что это были множественные имена.

Пользователь добавлен в таблицу Users.

Этот сайт согласен:
http://vyaskn.tripod.com/object_naming.htm#Tables

Этот сайт не согласен (но я не согласен с этим):
http://justinsomnia.org/writings/naming_conventions.html


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

Майкл Харен
источник
46
При применении теории множеств к таблицам, любой экземпляр в наборе является представителем набора, поэтому Apple - это набор Apple, он не зависит от того, сколько яблок в наборе - это Apple со многими экземплярами. «Мешок» с яблоками не становится «мешком», если в нем много яблок.
ProfK
89
Что делать, если у вас есть сумка с 5 яблоками внутри? Вы называете это мешок с яблоком? или мешок яблок?
Кристофер Махан
26
Я думаю, что теория заключается в том, что набор называется яблоки. Единственное яблоко - все еще «набор яблок» - хотя набор с единственным экземпляром. Несколько яблок также являются «набором яблок».
Марк Брэкетт
26
@ Кристофер, если смысл сумки - держать яблоки и только яблоки, то это «яблочная сумка», независимо от того, содержит ли она 1 яблоко, 100 яблок или нет яблок.
Ян Маккиннон
14
@ Ян: Это потому, что таблица является общей и может быть сравнена с транспортным контейнером (может содержать почти все, от ящиков для яблок до ящиков на мотоциклах Harley Davidson). Вы говорите: грузовой контейнер с апельсинами, а не оранжевый грузовой контейнер. Вы говорите: грузовой контейнер с автозапчастями, а не грузовой контейнер с автозапчастями. Если вы создали собственную структуру данных, предназначенную для хранения данных только определенного типа, например, названий яблок, и назвали ее «кунгабого», то у вас может быть яблочное кунгабоко. Я знаю, о чем ты думаешь, но сначала подумай о мешочке с шарами и пойми разницу в значении.
Кристофер Махан
79

Как насчет этого в качестве простого примера:

SELECT Customer.Name, Customer.Address FROM Customer WHERE Customer.Name > "def"

против

SELECT Customers.Name, Customers.Address FROM Customers WHERE Customers.Name > "def"

SQL в последнем звучит более странно, чем первый.

Я голосую за единственное число .

джеймс
источник
50
В этом примере да, но на практике это никогда не будет написано так. У вас будет псевдоним таблицы, так что это будет больше похоже наSELECT C.Name, C.Address FROM Customers WHERE Customers.Name > 'def'
Майкл Харен
+1, (год спустя) Вы привели ТЕРРИФИЧЕСКИЙ пример того, как единственное число имеет смысл. Это несколько религиозные дебаты. Несколько лет назад я обратился к единственному лицу архитектором данных, который был на много лет старше меня, и мне это показалось правильным (после того, как мне потребовалось много убедительных изменений).
Крис Адранья
24
Я думаю, что sql звучит лучше во множественном числе. У вас не будет имен таблиц для каждого столбца, почему вы так сильно любите печатать. ВЫБЕРИТЕ Имя, Адрес ОТ Клиентов, ГДЕ Имя> «def» Вы выбираете из пула клиентов, где имя больше, чем def.
Jamiegs
6
Как насчет использования псевдонима / AS, чтобы обойти эту проблему? ВЫБЕРИТЕ Customer.Name, Customer.Address ОТ Клиентов КАК Клиент Customer WHERE Customer.Name> "def"
Джеймс Хьюз
1
Второй звучит намного лучше, единственное звучит как тот, кто не говорит по-английски.
HLGEM
61

Я твердо убежден, что в диаграмме отношений сущностей сущность должна быть отражена в единственном названии, аналогично имени класса в единственном числе. После создания имя отражает его экземпляр. Таким образом, с базами данных сущность, когда она превращена в таблицу (совокупность сущностей или записей), является множественной. Сущность, Пользователь превращается в таблицу Users. Я бы согласился с другими, кто предположил, что имя пользователя может быть улучшено до сотрудника или что-то более подходящее для вашего сценария.

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

Адам Карр
источник
3
Мне особенно нравится комментарий оператора SQL. Использование единственного числа здесь не кажется интуитивно понятным для читателя.
hochl
2
Отличное замечание по поводу ERD. Я подозреваю, что именно поэтому, для того, кто видит мир глазами DBA, единственное наименование имеет смысл. Я подозреваю, что они не получают, как вы указываете, разницу между сущностью и их совокупностью.
Уильям Т. Маллард
1
Таблица не является набором записей; таблица - это определение того, как выглядит запись. Это - разъединение, которое, кажется, имеют все множественное число / единственное число людей.
Богатый Ремер
Я не согласен с комментарием оператора SQL. Что делать, если вы хотите присоединиться к Users.Id
hashtable
1
Один old_lady имеет много кошек ИЛИ old_ladies есть кошки. Я думаю, что ERD лучше читать во множественном числе. И таблица сущностей, таблицы имеют много сущностей, поэтому я снова думаю, что множественное число звучит хорошо.
user3121518
39

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

Причина? Тот факт, что на английском языке есть неправильное множественное число, как мышь ⇒ мыши и овцы ⇒ овцы . Затем, если мне нужна коллекция , я просто использую мышки или овец и продолжаю.

Это действительно помогает выделиться множеству, и я могу легко и программно определить, как будет выглядеть коллекция вещей.

Итак, мое правило таково: все единично, каждая коллекция уникальна с добавлением s . Помогает с ORM тоже.

Пауло Фрейтас
источник
7
как насчет слова, оканчивающегося на 's'? Если у вас есть таблица под названием «Новости» (просто в качестве примера), как бы вы назвали сбор новостей? Newss? Или вы бы назвали стол «Новый»?
Энтони
18
Я бы назвал таблицу NewsItem и коллекцию NewsItems.
Пепельная Машина
5
Что если вам придется проверять орфографию всего кода, иначе он не скомпилируется;)?
Хэмиш Грубиджан
2
ORM не должен диктовать имена объектов, на которые они отображаются. Смысл ORM - это абстракция объекта, дающего эту гибкость.
barrypicker
16
@HamishGrubijan тогда прекратите использовать Word для написания своего кода! ;)
Валентино Вранкен
37

ИМХО, имена таблиц должны быть во множественном числе как у Клиентов .

Имена классов должны быть единичными, как Customer, если они сопоставляются со строкой в таблице Customers .

Гульзар Назим
источник
33

Единственное число. Я не покупаю никаких аргументов, которые являются наиболее логичными - каждый человек считает свои предпочтения наиболее логичными. Неважно, что вы делаете, это беспорядок, просто выберите соглашение и придерживайтесь его. Мы пытаемся сопоставить язык с очень нерегулярной грамматикой и семантикой (обычный разговорный и письменный язык) с очень регулярной (SQL) грамматикой с очень специфической семантикой.

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

Таким образом, AppUserотношение говорит, какие объекты AppUsers.

AppUserGroupОтношение говорит мне , какие объекты являютсяAppUserGroups

AppUser_AppUserGroupОтношение говорит мне , как AppUsersи AppUserGroupsсвязаны между собой .

AppUserGroup_AppUserGroupОтношение говорит мне , как AppUserGroupsи AppUserGroupsсвязаны (т.е. группы членов группы).

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

Тогда в моем коде и в схеме базы данных я использую единственное число. В текстовых описаниях я в конечном итоге использую множественное число для повышения читабельности - затем использую шрифты и т. Д., Чтобы отличить имя таблицы / отношения от множественного числа s.

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

Jacob Lorensen
источник
1
точно. главное, что многие люди здесь не знают, это то, что они называют ... вы даете имя отношению (одна запись в таблице), а не набор записей в таблице.
Александр Мартини
3
Не могу не согласиться больше. «Выберите * из списка« Пользователи, имя которых равно «J%» », потому что я выбираю всех пользователей, имя которых начинается с« J ». Если вы утверждаете, что хотите написать «... где User.Name like ...», просто используйте псевдоним. По той же причине я говорю: «Дайте мне пару из всех доступных носков».
Марк А. Донохью,
Если бы я был именно таким, то имя моей таблицы было бы sock_pair
Мануэль Эрнандес
@AlexandreMartini Точно. Как некоторые люди, которые называют одну запись в таблице «отношение».
Нуно Андре
31

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

Мы делаем это для обеспечения единообразия как между архитектурой базы данных, так и архитектурой приложения, исходя из базового понимания, что таблица Users представляет собой набор значений User так же, как коллекция Users в артефакте кода представляет собой набор объектов User .

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

Пауло Фрейтас
источник
8
Я согласен .. почему несоответствие между кодом и хранилищем? Я никогда не назову коллекцию пользовательских объектов «Пользователь» в коде ... так зачем мне называть таблицу так? Это не имеет никакого смысла. Когда я читаю рассмотренные выше рассуждения об этом, они фокусируются на сущности, а не на таблице ... в моей памяти есть различие между тем, что в таблице, и самой таблицей.
Джейсон
Как вы справляетесь с именем таблицы, например, companiesгде в других таблицах вызывается поле ссылки company_id? Хотя оно написано правильно, оно кажется непоследовательным для тех, кто требователен к соглашениям об именах таблиц.
Джейк Уилсон
1
Помня, что единственное число companiesявляется company, и что этот идентификатор является ссылкой на единичный элемент. В коде это не должно беспокоить нас больше, чем в английском.
Дэвид
22

Лично я предпочитаю использовать множественные имена для представления набора, это просто «звучит» лучше для моего отношения.

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

Прочитав все споры в этой теме, я пришел к одному выводу:

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

кто то
источник
Неразумно использовать такое соглашение в реляционном модельном мире, особенно когда вы описываете отношения между объектами, например, «Каждая команда может иметь только одного главного тренера и множество вторичных тренеров», что описано: Team-> MainCoach, Team - >> SecondaryCoach
noonex
16

Единственное число. Я бы назвал массив, содержащий группу объектов представления пользовательских строк, «пользователи», но таблица - это «таблица пользователей». Думать о таблице как о не более чем наборе строк, которые в ней содержатся, неверно, IMO; таблица представляет собой метаданные, а набор строк иерархически привязан к таблице, а не к самой таблице.

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

хаос
источник
Наверное, каждому свое. Таблица реляционной базы данных по определению является заголовком (то есть метаданными с именами атрибутов) и набором кортежей, соответствующих заголовку. Вы можете сосредоточиться на метаданных, тогда как другие сосредоточатся на кортежах. :-)
Билл Карвин
Эй, User_Table - это имя, которое мне нравится! :)
Камило Мартин
3
ORM не должен диктовать имена объектов, на которые они отображаются. Смысл ORM - это абстракция объекта, дающего эту гибкость.
barrypicker
1
Я смотрю на это так ... если вы создаете массив / список / словарь чего-либо в коде, я ставлю на то, что вы называете его во множественном числе того, что оно содержит. Если вы используете ORM для абстрагирования своей базы данных, таблицы представлены в виде некоторой коллекции, так почему бы вы не относились к ним иначе? Использование названий в единственном числе может звучать хорошо, но вы всегда боретесь со своим инстинктом того, что таблица содержит много одного и того же, как это делает коллекция в коде. Почему несоответствие?
Джейсон
@Jason: Пожалуйста , сравнить и сопоставить, как эти вещи читать: 1) $db->user->row(27), $db->product->rows->where(something) 2) $db->users->row(27), $db->products->rows->where(something).
хаос
16

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

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

Таблица машин будет иметь название машины, а каждый ряд - это машина. Я признаю, что указание таблицы вместе с полем table.fieldявляется наилучшей практикой, а наличие имен таблиц в единственном числе более читабельно. Однако в следующих двух примерах первый имеет больше смысла:

SELECT * FROM cars WHERE color='blue'
SELECT * FROM car WHERE color='blue'

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

Randy
источник
9
Разве это не конвенция в RoR тоже? Множественные имена для таблиц и Singular для классов ORM? Имеет много смысла для меня. Стол называется «автомобили», потому что он имеет много экземпляров «автомобиль», а класс называется «Автомобиль», потому что он будет содержать один экземпляр автомобиля!
Сап
@Sap Небольшое исправление последней части вашего предложения. Класс «Автомобиль» - это абстрактный тип данных, представляющий реальный автомобиль. Будет ли он содержать один экземпляр или несколько, зависит от того, как он используется.
просит
Посмотрим правде в глаза, таблица carявляется определение структуры одного автомобиля. Если вы посмотрите на структуру таблицы, то она, в основном, будет выдавать «id int, color string etc»: скажем, у вас есть таблица car_vendor(или для вашей множественной версии это будет cars_vendor) с внешним ключом cars_id?! что это за глупое дерьмо? это не car_id не нужно , чтобы заставить меня думать. Singular сильно предпочитается мной
Toskan
4
Мне очень нравится этот ответ! Позволь мне объяснить. Если коллекция есть carи вы хотите все, что от этого car, blueто результат должен быть примерно таким tire, mirror, engine. И тогда это сбивает с толку, потому что все результаты partsот car. Поэтому имя таблицы должно быть carparts(или car_parts, CarPartsкак вам угодно)
arnoudhgz
Любой разработчик базы данных, который применяет особые имена таблиц, в основном объявляет войну любым разработчикам приложений Ruby on Rails, которые могут вступить в контакт с этой базой данных в будущем. Строгое требования Rail к единичным словам для классов и к множественным именам для таблиц обеспечивают много мощного поведения во многих драгоценных камнях в экосистеме Ruby. Поэтому, даже если вы думаете, что единственное звучит лучше, ради совместимости вам следует придерживаться множественного числа. Я полагаю, что это верно и для многих других объектно-реляционных картографов.
Келси Ханнан
15

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

По иронии судьбы, я мог бы сделать Userисключение и вызвать его Usersиз-за USER (Transac-SQL) , потому что я тоже не люблю использовать скобки вокруг таблиц, если мне это не нужно.

Я также хотел бы назвать все столбцы идентификаторов как Id, а не ChickenIdили ChickensId(что с этим делают парни во множественном числе?).

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

Евгений Йокота
источник
8
Мы, парни во множественном числе, либо назовем столбец «id» «id», как вы, либо «singular_id». Я считаю, что таблицы должны быть во множественном числе (думать о них как о массивах), но имена столбцов должны быть единичными (атрибуты одного элемента).
mpen
plu_ral / PluRal для имен таблиц, singular_id / singularId для первичных ключей.
hochl
14

Мы применяем аналогичные стандарты, когда при написании сценариев мы требуем [] в отношении имен и, где это уместно, квалификаторов схемы - в первую очередь это делает ваши ставки против будущих захватов имен синтаксисом SQL.

SELECT [Name] FROM [dbo].[Customer] WHERE [Location] = 'WA'

Это спасло наши души в прошлом - некоторые из наших систем баз данных работали более 10 лет от SQL 6.0 до SQL 2005 - намного дольше, чем предполагалось.

stephbu
источник
Похоже на ритуальное самобичевание. Случались ли какие-нибудь подобные перехваты имен?
Кжетил С.
13

Таблицы: множественное число

Несколько пользователей перечислены в таблице пользователей.

Модели: единственное число

Единственный пользователь может быть выбран из таблицы пользователей.

Контроллеры: множественное число

http://myapp.com/users будет перечислять несколько пользователей.

В любом случае, это мое мнение.

Эндрю
источник
1
Ближе к моему пониманию, но мое мнение состоит в том, что хранение таблицы несколькими пользователями фактически является случайным, и что любой отдельный пользователь представлен таблицей, или, скорее, отношением, которое представляет собой набор кортежей, представляющих сущность User.
ProfK
Я думаю, что склонен согласиться с этим. Меня смущает только то, почему модели должны быть единичными? Только если модель касается только одного пользователя. Если бы я запрашивал базу данных, чтобы получить всех пользователей, мне нужно было бы получить доступ к модели? Для единственного экземпляра не имеет смысла извлекать все записи, например: $ user-> get_all () // не имеет смысла
PM7Temp
12

Я фанат названий таблиц в единственном числе, поскольку они делают мои диаграммы ER с использованием синтаксиса CASE более легкими для чтения, но, читая эти ответы, я чувствую, что они никогда не завоевывали популярность? Я лично люблю это. Существует хороший обзор с примерами того, насколько удобными могут быть ваши модели, когда вы используете имена таблиц в единственном числе, добавляете глаголы действий к своим отношениям и составляете хорошие предложения для каждого отношения. Это все немного излишне для базы данных из 20 таблиц, но если у вас есть БД с сотнями таблиц и сложным дизайном, как ваши разработчики поймут это без хорошей читаемой диаграммы?

http://www.aisintl.com/case/method.html

Что касается префиксов таблиц и представлений, я абсолютно ненавижу эту практику. Дайте человеку никакой информации, прежде чем давать ему, возможно, плохую информацию. Любой, кто просматривает БД на предмет объектов, может довольно легко отличить таблицу от представления, но если у меня есть таблица с именем tblUsers, по какой-то причине я решу реструктурировать в будущем две таблицы, с целью объединить их, чтобы не сломать старый код. Теперь у меня есть представление с именем tblUsers. На данный момент у меня остались две не привлекательные опции, я оставляю представление, названное с префиксом tbl, что может запутать некоторых разработчиков, или вынудит переписать другой слой, средний уровень или приложение, чтобы ссылаться на мою новую структуру или имя viewUsers. Это сводит на нет большую часть ценности взглядов ИМХО.

Шейн Делмор
источник
1
Хороший пример ловушки префикса имен объектов с квалификатором 'type'!
Кенни Эвитт
12

Система tables/viewsсамого сервера ( SYSCAT.TABLES, dbo.sysindexes, ALL_TABLES, information_schema.columnsи т.д.) почти всегда во множественном числе. Я думаю, для последовательности я последую их примеру.

Мишель
источник
Microsoft - то, чем они являются прежде всего по деловым причинам (и часто неэтичным причинам), последние логические причины. Единственная причина, по которой я следую за ними, заключается в том, что они большая горилла, и все остальные идут по этому пути. Когда у меня есть выбор, я выбираю другой путь.
Брюс Патин
1
Следует отметить, что information_schemaявляется частью стандарта ИСО / МЭК 9075-11, стандарта SQL. И да, он использует множественные имена таблиц / представлений.
Пауло Фрейтас
10

Если мы посмотрим на MS SQL Server'sсистемные таблицы, их имена, присвоенные Microsoft, находятся в plural.

Системные таблицы Oracle названы в singular. Хотя некоторые из них во множественном числе. Oracle рекомендует множественное число для определяемых пользователем имен таблиц. Это не имеет большого смысла, что они рекомендуют одно и следуют другому. То, что архитекторы этих двух гигантов программного обеспечения назвали свои таблицы, используя разные соглашения, тоже не имеет особого смысла ... В конце концов, что это за ребята ... Кандидаты наук?

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

Например, когда мы говорим:

select OrderHeader.ID FROM OrderHeader WHERE OrderHeader.Reference = 'ABC123'

может быть б / к каждый IDвыбирается из определенной строки ...?

Ричард
источник
1
Microsoft - то, чем они являются прежде всего по деловым причинам (и часто неэтичным причинам), последние логические причины. Единственная причина, по которой я следую за ними, заключается в том, что они большая горилла, и все остальные идут по этому пути. Когда у меня есть выбор, я выбираю другой путь.
Брюс Патин
Две вещи. Во-первых, вы обычно не будете использовать имена таблиц и напишите «select ID FROM OrderHeaders WHERE Reference =« ABC123 », потому что вы« выбираете все идентификаторы из OrderHeaders, где что-то верно », но если бы вам пришлось использовать имена таблиц из-за присоединиться или что-то еще, вы бы использовали псевдоним, как так ... 'выберите OrderHeader.ID ИЗ OrderHeaders как OrderHeader ГДЕ OrderHeader.Reference =' ABC123 '
Марк А. Донохо
9

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

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

Практическая последовательность иногда является лучшим стандартом ... :)

my2cents ---

Borzio
источник
9

Возможные альтернативы:

  • Переименуйте таблицу SystemUser
  • Используйте скобки
  • Сохраните имена таблиц во множественном числе.

ИМО с использованием скобок - технически самый безопасный подход, хотя он немного громоздок. IMO - это 6 из одного, полдюжины из другого, и ваше решение действительно сводится к личным / командным предпочтениям.

Дейв Маркл
источник
2
Мне нравится ваша идея префикса, но я бы назвал ее SystemUser.
ProfK
9

Мое мнение заключается в семантике в зависимости от того, как вы определяете свой контейнер. Например, «мешок яблок» или просто «яблоки» или «мешок яблок» или «яблоко».

Пример: таблица «колледж» может содержать 0 или более колледжей Таблица «колледж» может содержать 0 или более колледжей

a "student" table can contain 0 or more students 
a table of "students" can contain 0 or more students.

Я пришел к выводу, что либо это хорошо, но вы должны определить, как вы (или люди, взаимодействующие с ним) будут подходить при обращении к таблицам; «стол топора» или «стол хз»

jleviaguirre
источник
8

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

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

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

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

Мне нравится использовать префиксы ограниченным образом (tbl для имен таблиц, sp_ для имен процессов и т. Д.), Хотя многие считают, что это добавляет беспорядок. Я также предпочитаю, чтобы имена CamelBack подчеркивались, потому что при вводе имени я всегда нажимаю + вместо _. Многие другие не согласны.

Вот еще одна хорошая ссылка для руководящих принципов соглашения об именах: http://www.xaprb.com/blog/2008/10/26/the-power-of-a-good-sql-naming-convention/

Помните, что наиболее важным фактором в вашем соглашении является то, что он имеет смысл для людей, взаимодействующих с рассматриваемой базой данных. Не существует «одного звонка, чтобы управлять ими всеми», когда речь идет о соглашениях по присвоению имен.

Крис
источник
18
Игнорирование ужасов венгерской нотации. Никогда, никогда, никогда не используйте sp_ перед хранимыми процедурами, потому что MS-SQL использует это для системных хранимых процедур и рассматривает их как особые. Поскольку sp_ хранятся в основной таблице, MS-SQL всегда выглядит первым, даже если вы определяете местоположение.
Уилл Дитрих
8

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

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

helloworlder
источник
В университете меня обучают множественному числу для таблиц, у меня также есть книга, руководство по БД, третье издание 90-х годов, таблицы являются единственными; в то время как у меня также есть обновленная копия, 11e, единственное и некоторые сокращенные имена, в то время как раздел XML использует множественное число. \ n Но если вы проверите фактическое содержание для разделов RDBMS, это буквально тот же текст с некоторыми изображениями, получившими подтяжку лица. \ n «Контрольный список моделирования данных» ничего не говорит о множественном и единственном числах, просто сущности должны отображаться только на один объект, это, вероятно, то, что они пытались применить в книгах.
Марко
8

Однажды я использовал «Чувак» для таблицы «Пользователь» - такое же короткое количество символов, никакого конфликта с ключевыми словами, все же ссылка на обычного человека. Если бы я не беспокоился о душных головах, которые могли бы видеть код, я бы так и продолжил.

Брюс Патин
источник
8

Я всегда использовал единственное число просто потому, что меня этому учили. Однако, создавая новую схему недавно, впервые за долгое время, я активно решил придерживаться этого соглашения просто потому, что ... оно короче. Добавление 's' в конец каждого имени таблицы кажется мне таким же бесполезным, как добавление 'tbl_' перед каждым.

Just Some Guy
источник
7

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

(Я полагаю, что рациональное обоснование этой политики заключается в том, что для генераторов кода ORM проще создавать классы объектов и коллекций, поскольку проще создать множественное имя из единственного имени, чем наоборот)

Джеймс Керран
источник
11
Это соглашение было частью теории отношений задолго до появления ORM.
ProfK
1
ORM не должен диктовать имена объектов, на которые они отображаются. Смысл ORM - это абстракция объекта, дающего эту гибкость.
barrypicker
7

Я использую только имена существительные для имен таблиц, которые пишутся одинаково, в единственном или множественном числе:

лосиная рыба олень самолеты штаны шорты очки ножницы виды потомство

Бобби
источник
6

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

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

jerseyboy
источник