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

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

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

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

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

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

У меня был тот же вопрос, и после прочтения всех ответов здесь я определенно остаюсь с 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, ...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

против

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

my2cents ---

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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