sql - practices - table name plural or singular




Дилемма имен таблиц: сингулярные и множественные имена (20)

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

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

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

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

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


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

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


Если вы используете инструменты реляционного сопоставления объектов или в будущем я предлагаю Singular .

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

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

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


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

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


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

Пользователь добавляется в таблицу «Пользователи».

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

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

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


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

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

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

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


У меня был такой же вопрос, и после прочтения всех ответов здесь я определенно остаюсь с СИНГУЛЯРНЫМ, причины:

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

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

  • Покупатель
  • порядок
  • пользователь
  • Статус
  • Новости

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

  • 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, ...

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


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

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

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

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


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

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

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

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


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

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

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

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


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

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


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

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

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


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

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

Модели: сингулярные

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

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

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

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


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

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


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

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

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

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

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

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


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

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

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

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

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

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

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


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


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

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

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

my2cents ---


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


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

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







naming-conventions