Дилемма именования таблиц: имена в единственном и множественном числе

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

Английский не является моим родным языком, может кто-нибудь дать мне пример названия Singular и Plural?

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

@andygavin ну, я работаю в системе, где единственное и множественное число смешано (возможно, как вы предлагаете, я мог бы проверить это, но я подозреваю, что это было слишком много поваров), потребовалось время, прежде чем вы все поняли (intellisense - это всегда слишком медленно для меня ...)

Одним из способов решения загадки ключевого слова было бы добавление короткого префикса, например, «t» для таблиц (tUser [s]), «v» для представлений и т. д., Но не рекомендуется для атрибутов (не нужно «aGroup» или похожие!)

Должно быть во множественном числе! List <String> names ==> StringList имен, UserCollection пользователей, Collection пользователей, UserTable пользователей, AppleBag красных яблок ... звоните в какие-нибудь колокола? имя класса будет «Пользователь», «Apple» и т. д.

Оба из них: например, у меня есть таблица с именем Users, и это нормально, тогда у меня есть таблица с именем User_Transactions, а не Users_Transactions. Затем представьте, что у вас есть эта таблица: user_categories, которая просто содержит категории, тогда у вас есть связанная таблица с именем users_categories, поскольку пользователь может быть в другой категории ... Я надеюсь, что это дает идею

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

Я бы выбрал обычную практику экосистемы, в которой вы работаете. Например: в Node.js ORM, такие как Bookshelf.js или Objection.js, в основном основаны на «Knex.js». А в документации «Knex.js» вы найдете имена таблиц во множественном числе. Так что я бы выбрал множественное число в этой области. Источник: knexjs.org/#Schema-createTable

Все наши таблицы сингулярны (каждая строка рассматривается независимо), но наша ORM делает ее множественной в нашем приложении (когда вы запрашиваете, вас обычно интересует коллекция)

ВСТАВИТЬ клиентов (имя) ЗНАЧЕНИЯ («Алиса»). Не: ВСТАВИТЬ клиента (имя) СО ЗНАЧЕНИЯМИ («Алиса»). ВЫБРАТЬ ИЗ клиентов, ГДЕ name = "Алиса". Не: ВЫБРАТЬ клиента С именем = "Алиса". УДАЛИТЬ ОТ клиентов, ГДЕ id = 1. Не: УДАЛИТЬ клиента С id = 1. ОБНОВИТЬ клиентов SET email = "[email protected]" WHERE name = "Alice". Не: ОБНОВЛЯЙТЕ клиента с помощью name = "Alice" SET email = "[email protected]".

Да, я согласен. Имеет смысл иметь таблицу пользователей и одновременно называть ее «AppUser»; также имеет смысл иметь таблицу правил, применимых к определенному типу пользователей, и называть ее «UserRules».

@Arindam "UserRule" или "UsersRule" определенно не звучит правильно в качестве названия для списка правил, связанных с пользователем. Это сильный аргумент против использования единственного числа!

Я рекомендую это руководство по стилю: sqlstyle.guide

С практической точки зрения: когда я использую EF и созданные им сущности, имеет больше смысла использовать, например, new Order, чем new Orders, при создании новой записи заказа.

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

Отношение состоит из заголовка и тела. Заголовок - это набор атрибутов. Тело (n-арного отношения) - это набор из n кортежей. Заголовок отношения также является заголовком каждого его кортежа. [en.wikipedia.org/wiki/Relational_model]

Что делать, если у вас есть пакет с 5 яблоками внутри? Вы называете это мешком с яблоками? или мешок яблок?

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

Как бы вы определили в своем коде массив объектов Apple? Apple apples[100] или Apple apple[100]

@Christopher, если смысл существования мешка состоит в том, чтобы хранить яблоки и только яблоки, то это «мешок для яблок», независимо от того, содержит ли он 1 яблоко, 100 яблок или не содержит яблок.

@ Ян: Это потому, что таблица является универсальной, и ее можно сравнить с транспортным контейнером (может содержать почти все, от ящиков для яблок до ящиков с мотоциклами Harley Davidson). Вы говорите: грузовой контейнер с апельсинами, а не оранжевый грузовой контейнер. Вы говорите: грузовой контейнер с автомобильными запчастями, а не грузовой контейнер с автомобильными запчастями. Если вы создали настраиваемую структуру данных, предназначенную для хранения только определенного типа данных, например, названий яблок, и назвали ее «кунгабого», то у вас могло бы быть яблочное кунгабоко. Я знаю, о чем вы думаете, но сначала подумайте о мешочке с шарами и поймите разницу в значениях.

@Christopher, конкретная таблица базы данных предназначена для хранения только одного типа вещей, навсегда, и может быть связана с этим типом, даже когда она пуста, поэтому транспортный контейнер - неадекватная метафора. Это тоже абстрактные понятия, поэтому вряд ли кто-то их спутает с мошонкой.

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

Это забавные примеры - я склонен согласиться с @Ian, хотя @Christopher - я знаю, что дальше по дороге есть тележка с яблоками. Здесь продаются яблоки Granny Smith, Jonathon и даже Golden Delicious. И в конце концов, это таблица User, а не таблица Users ...

-1 за отсутствие ссылки на какой-либо стандарт (или авторитетного автора).

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

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

Дело в том, что таблица - это набор объектов. Итак, для меня очевидно, что имя таблицы должно быть во множественном числе. То есть таблица Users - это набор объектов / сущностей под названием User.

«Пользователь добавлен в таблицу Users». В Java это все равно что сказать, что переменная user принадлежит классу Users. Или сказать, что «ints i» лучше, чем «int i», потому что i - это просто еще одна переменная типа int (или, в Javascript, «vars i» лучше, чем «var i», потому что i это просто еще одна переменная). При таком подходе базу данных следует называть таблицами.

Я не считаю справедливым сравнивать таблицы с классами Java. Класс работает принципиально иначе, чем таблица БД (набор определенных элементов). Думаю, лучше сравнивать таблицы с массивами.

@Plap Users - это не класс, это коллекция этого класса или список. Вы добавляете пользователя в список пользователей.

Множественное число - лучший способ. Единственный аргумент против этого не выдерживает критики - это выбор отношений. ВЫБЕРИТЕ * от пользователей, у которых Users.Name = "somename". Это действительно должно быть записано как SELECT * from Users user where user.Name = "somename". Или подумайте об этом в рамках сущности. Users.Where (user => user.Name == "somename"). Таблица - это совокупность сущностей, а таблица - НЕ ОТНОШЕНИЕ. Отношение - это характеристика сущности, не более того. Имена таблиц должны быть во множественном числе

Мне нравится ваша идея с «префиксом», но я бы назвал ее SystemUser.

Это соглашение было частью теории отношений задолго до того, как существовала ORM.

ORM не должен диктовать имена объектов, которым они сопоставляются. Смысл ORM - это абстракция объекта, предоставляющая эту гибкость.

Согласовано. Пробелы и префиксы от Дьявола.

MS Access поощряет имена таблиц с пробелами. Я подозреваю, что многие таблицы MSSQL в пробелах были импортированы оттуда.

+1 снова. Таблицы и поля, обозначенные пробелами, - это отличительная черта одаренного ребенка Office Junior, создающего для Берил настоящее приложение для доступа к кулу в учетной записи :-).

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

tbl в качестве префикса - это сын порождения дьявола и вонючей падали, но семантические префиксы немного лучше. В нашем основном приложении мы, Chase Software, ставим перед всеми таблицами префикс «ca» или «cs», что означает приложение преследования или систему преследования.

(продолжение) Таблицы ca являются бизнес-таблицами и регулярно меняются при повседневном использовании, например caDocument, который представляет собой счета-фактуры, заказы на закупку, ведомости затрат и т. д. Таблицы cs больше предназначены для навигации и т. д., например csForm, который мы используется для перехода между формами (страницами) и обычно изменяется только нами.

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

Sql Server требует фигурных скобок только для имен, которые являются зарезервированными ключевыми словами («Пользователь» - один). Я считаю, что у Oracle такая же политика

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

Похоже на ритуальное самобичевание. Были ли такие захваты имен еще?

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

plu_ral / PluRal для имен таблиц, singular_id / singularId для первичных ключей.

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

-1. Таблицы пользователей (и стран, языков) могут использоваться одновременно в нескольких приложениях.

Именно поэтому я сказал: «Возможно ли ...?» и, возможно"

Разве привязка имени схемы не устранит всю путаницу? AppName1.Users, AppName2.Users?

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

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

Какое отношение имеет префикс имени таблицы к использование единственного и множественного числа? Теперь вопрос только в том, использую ли я Widget_User или Widget_Users. Это не имеет отношения к вопросу.

Этот принятый ответ является скорее побочным комментарием и не отвечает на вопрос.

Таблица должна быть независимой от клиента, например, ее не должно волновать, называется ли она Widget или как она используется, имена могут измениться. Единственная обязанность таблицы - сохранять данные пользователя в структурированной и явной форме.

Определенно не используйте имя приложения! В какой-то момент кто-то из маркетологов переименует ваш продукт в NewFooApp, и вы застрянете с наследием «Widget», навсегда загрязняющим вашу схему базы данных, и лишь горстка людей останется в компании достаточно долго, чтобы вспомнить, что это вообще означает.

При запросе `from Country, Cities where Country.id`, здесь страны, имеющие единый идентификатор, звучит не очень хорошо.

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

За счет удобочитаемости, что довольно проблематично в операторах sql.

Полностью согласен - CAPS для ключевых слов, Camelcase и т. д. Для имен помогает немного улучшить это, но все же снижает удобочитаемость.

Сотрудники не всегда могут быть пользователями.

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

Это неправда. Zend_Db не налагает соглашения об именах для имен таблиц базы данных, имен классов таблиц или имен классов строк. Я сам удалил этот непродуманный код перегиба.

Но я поддерживаю соглашение о множественном числе имен классов таблиц и единственном числе имен классов строк. Просто фреймворк Zend_Db не требует соблюдения каких-либо соглашений.

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

Для стола нет класса. Любой класс, сопоставленный с таблицей, на самом деле описывает строку, а не таблицу. Единственное соответствие классу таблицы - это то, что явно описывает коллекцию.

Microsoft - это то, чем они являются, в первую очередь по бизнес-причинам (и зачастую по неэтичным причинам), а в последнюю очередь по логическим причинам. Единственная причина, по которой я следую за ними, - это то, что они большие гориллы, и все остальные идут этим путем. Когда у меня есть выбор, я выбираю другой путь.

Следует отметить, что information_schema является частью ISO / IEC 9075-11, стандарта SQL. И да, он использует множественные имена таблиц / представлений.

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

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

Помня, что единственное число companies - это company, и что этот идентификатор является ссылкой на единичный элемент. Код не должен беспокоить нас больше, чем английский язык.

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

ORM не должен диктовать имена объектов, которым они сопоставляются. Смысл ORM - это абстракция объекта, предоставляющая эту гибкость.

Это преобладает в инструментах или только в тех инструментах, которые вы использовали?

В моем мире я стараюсь использовать согласованные имена во всем проекте, чтобы не тратить время на размышления, есть ли у этого экземпляра в конце или нет. Тот факт, что ORM может переименовывается и является независимым, не означает, что это помогает вашим коллегам-разработчикам.

Некоторые ORM (как и многие инструменты программирования) имеют поведение по умолчанию, которое генерирует реализации без конфигурации ... с точки зрения ПРОИЗВОДИТЕЛЬНОСТИ. Таким образом, создание класса Employee без явного сопоставления приведет к созданию таблицы Employee по умолчанию.

@barrypicker. Множественные имена не просто выглядят глупо в коде ORM. Множественные числа тоже плохо смотрятся в SQL, особенно когда речь идет об уникальном атрибуте. Кто никогда не писал select user.id из пользователей? Или, может быть ... из пользователей, вышедших присоединиться к thingy.user_id = user.id ...?

@SamuelDanielson - Я не понимаю твоей точки зрения. Используя пример SQL, который вы предоставили, я бы в любом случае использовал псевдоним таблицы, например «select u.Id from users u». Стол представляет собой набор предметов, поэтому он должен быть во множественном числе - как в корзине с яблоками, а не в корзине с яблоками.

как насчет слова, оканчивающегося на "s"? Если у вас есть таблица с названием «Новости» (просто в качестве примера), как бы вы назвали сборник новостей? Новости? Или вы бы назвали этот стол «Новым»?

Я бы назвал таблицу NewsItem и коллекцию NewsItems.

Что делать, если вам нужно проверить орфографию весь код, иначе он не будет компилироваться;)?

@Hamish: вы на самом деле проверяете орфографию с помощью общих записей, таких как orderby, sbyte, const, sizeof? Напомнить мне еще раз?

ORM не должен диктовать имена объектов, которым они сопоставляются. Смысл ORM - это абстракция объекта, предоставляющая эту гибкость.

@HamishGrubijan, тогда перестань использовать Word для написания кода! ;)

В дополнение к тому, что вы сказали, есть еще один пример: категория и категории. В Laravel Eloquent ORM используется строчная форма множественного числа в названии модели. Интересно, почему они не рассматривали единственное число как вариант по умолчанию.

Вы противоречили себе. Вы сказали, что «каждая коллекция вещей уникальна с добавлением s», но вы утверждаете, что имена таблиц должны быть в единственном числе. По вашему собственному признанию, имена таблиц должны быть множественного числа (или, как вы указали, псевдо-множественного числа), потому что таблица - это совокупность данных в единственном числе. (т.е. таблица, содержащая автомобили, представляет собой набор объектов автомобилей, поэтому ее следует называть "cars"). Если вам нравится синтаксис car.doors в единственном числе, используйте псевдоним. (т.е. выберите car.WheelCount из Cars as car, где car.Id = 44)

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

Все сводится к тому, называете ли вы таблицу как отдельный объект (например, CarTable) или как объекты, которые она содержит (Cars). Логическая ошибка, которую я имею с людьми, которые назвали бы стол «Машиной», заключается в том, что стол - это не машина! Это CarTable, который представляет собой тип объекта, эквивалентный типу данных. CarCollection (также в единственном числе). Как только вы даете этому «типу данных» имя (т.е. имя переменной), вы обычно описываете, как он используется, в данном случае контейнер / коллекция / что-то еще из объектов Car, поэтому DataType должен должно быть CarTable, но имя таблицы должно быть Cars.

@MarqueIV: Хорошо, пусть будет по-вашему, как указывает SOF, ответы в основном основаны на мнении. Так что я рад, что у тебя есть твое.

Аааа ... старая позиция "соглашусь, чтобы не соглашаться"! lol Достаточно честно. Я признаю это.

В этом ответе есть очень хороший момент. Сопоставление класса Mouse с таблицей Mice кажется таким странным.

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

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

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

Я не согласен с комментарием к оператору SQL. Что делать, если вы хотите присоединиться против Users.Id

У одной old_lady много кошек ИЛИ old_lady есть кошек. Я думаю, что ERD лучше читать во множественном числе. И таблица сущностей, таблицы имеют много сущностей, поэтому я снова думаю, что множественное число звучит хорошо.

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

Привет, мне нравится имя User_Table! :)

ORM не должен диктовать имена объектов, которым они сопоставляются. Смысл ORM - это абстракция объекта, предоставляющая эту гибкость.

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

@Jason: Пожалуйста, сравните и сопоставьте то, как читаются эти вещи: 1) $db->user->row(27), $db->product->rows->where(something) 2) $db->users->row(27), $db->products->rows->where(something).

В SQLAlchemy примерами могут быть User.query.get(27) или User.query.filter(User.id == 27).one() и Product.query.filter(something).all(), независимо от того, как называются таблицы. Как сказал @barrypicker, ORM, который вы используете, недостаточно гибкий.

@barrypicker Грамматика не должна диктовать соглашения о программировании (знаете ли вы, что java beans - это идиотизм?). Его следует соблюдать, пока он не мешает. Возможность использовать другое отображение в ORM есть в тех случаях, когда это необходимо. Грамматика очень необычна, и такие вещи, как «матрицы» против «матриц», - редкие, но убедительные примеры того, почему код не должен быть заражен ею.

Хороший пример ловушки при добавлении к именам объектов префикса квалификатора type!

Я не согласен; В базе данных Oracle есть системная таблица с именем USER, теперь вы должны решить назвать ее «APP_USER» или что-то в этом роде. Но учитывая, что в любом случае лучше сказать «ВЫБРАТЬ ВСЕ ИЗ ПОЛЬЗОВАТЕЛЕЙ», я бы просто назвал все таблицы множественным числом моих сущностей, чтобы не конфликтовать с какой-либо системной таблицей.

Мне нравится выбирать из users или userTable, но не из user. С Singular это звучит так, как будто вы получаете только одну пластинку. Я вижу, что вам нравится думать, что нужно выбирать столбцы из таблицы. Больше всего нравится думать, что select возвращает строки из таблицы, поэтому имя коллекции звучит логично.

Я дам вам свои 2 цента. Будет ли ваша таблица базы данных состоять из одной строки или нескольких строк? Это как сказать: у меня в обеих руках по пять яблок. Тем не менее, мы оба согласны, что правильная фраза будет такой: у меня пять яблок в обеих руках. Почему мы хотим изменить этот вопрос для базы данных? Как только вы назначите userTable в качестве имени, у нас будет 1 таблица, которая фактически уже определяет существование нескольких строк данных. Однако я бы тоже этого не сделал. Я предпочитаю использовать множественное число. Поскольку age = '21', скорее всего, вернет более 1 строки, не так ли?

Единственное число - это стандарт.

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

За исключением того, что приходится иметь дело с нестандартным множественным числом в ActiveRecord ... Я всегда использовал множественные имена таблиц, но множественное число обязательно создает неприятности - как в стандартах ORM, так и в стандартах JSON, - которых никогда не бывает с единственными именами таблиц.

+ Келси Ханнан Точка зрения ярмарки, хотя некоторым людям нравится соглашение о единственном числе, но некоторые фреймворки (например, Rails) используют множественное число в качестве своего соглашения ... поэтому иногда выбор единственного и множественного числа зависит от проекта ....

«Выбрать все поля из таблицы« пользователь », которым 21 год» -> Выбрать каждое поле для каждого пользователя (нескольких), которому 21 год. Так что логичнее использовать множественное число.

В этом примере да, но в практическом sql это никогда не будет написано таким образом. У вас был бы псевдоним таблицы, чтобы он был больше похож на SELECT C.Name, C.Address FROM Customers WHERE Customers.Name > 'def'

+1, (год спустя) Вы привели УЖАСНЫЙ пример того, что единственное число имеет смысл. Это в некотором роде религиозный спор. Несколько лет назад я был переведен на сингулярность архитектором данных, на много лет старше меня, и мне это показалось правильным (после того, как мне потребовалось убедить меня переключиться).

Я думаю, что sql лучше звучит во множественном числе. У вас не было бы имен таблиц для каждого столбца, почему вы так любите печатать? ВЫБЕРИТЕ Имя, Адрес ОТ Клиентов ГДЕ Имя> "def" Вы выбираете из пула клиентов, где имя больше, чем def.

Как насчет использования псевдонима / AS, чтобы обойти эту проблему? ВЫБЕРИТЕ Customer.Name, Customer.Address FROM Customers AS Customer ГДЕ Customer.Name> "def"

Второй звучит намного лучше, необычно звучит как человек, не говорящий по-английски.

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

Пожалуйста, объясните свое мнение.

Нет, на самом деле это будет называться «UserProperties», поскольку они являются свойствами пользователя объекты (строки), которые хранятся в таблице, а не свойствами самого пользователя стол. Выражение «UsersProperties» будет означать, что они являются свойствами таблицы пользователей (например, RowCount, MaxRows и т. д.), Тогда как UserProperties четко обозначает те, которые относятся к пользователю (например, UserName, Age, SSN и т. д.)

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

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

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

Разве это не конвенция и в RoR? Множественные имена для таблиц и Singular для классов ORM? Для меня это имеет большой смысл. Таблица называется «cars», потому что у нее много экземпляров «car», а класс называется «Car», потому что он будет содержать один экземпляр автомобиля !!

@Sap Небольшое исправление последней части вашего предложения - класс "Car" - это абстрактный тип данных, представляющий реальный автомобиль. Будет ли он содержать один экземпляр или несколько, зависит от того, как он используется.

Давайте посмотрим правде в глаза, таблица car - это определение структуры отдельного автомобиля. Если вы посмотрите на структуру таблицы, она будет выдавать в основном «id int, цветовую строку и т. д.», Кроме того: скажем, у вас есть таблица car_vendor (или для вашей версии множественного числа это будет cars_vendor) с внешним ключом cars_id ?! что это за дерьмо? это car_id не надо заставлять меня думать. Я сильно предпочитаю Singular

Мне очень нравится этот ответ! Позволь мне объяснить. Если коллекция - car, и вы хотите получить все от car, то есть blue, результат должен быть чем-то вроде tire, mirror, engine. И это сбивает с толку, потому что все результаты - parts от car. Таким образом, имя таблицы должно быть carparts (или car_parts, CarParts, как хотите)

Любой разработчик баз данных, применяющий единичные имена таблиц, по сути объявляет войну любым разработчикам приложений Ruby on Rails, которые могут войти в контакт с этой базой данных в будущем. Строгая настойчивость Rail в использовании единственных слов для классов и множественных имен для таблиц позволяет реализовать множество мощных функций во многих жемчужинах экосистемы Ruby. Поэтому, даже если вы думаете, что единственное число звучит лучше, ради совместимости вам следует придерживаться множественного числа. Я полагаю, что это справедливо и для многих других объектно-реляционных картографов.

Настоящие проблемы начинаются, когда вам нужно присоединиться к SELECT cars.id, cars.name, cars.speed, cars_parts.engine, cars_parts.something FROM cars LEFT JOIN cars_parts ON cars_parts.cars_id=cars.id против SELECT car.id, car.name, car.speed, cars_part.engine, car_part.something FROM car LEFT JOIN car_part ON car_part.car_id=car.id, последний запрос более информативен, когда вам нужно упомянуть поле.

На практике SQL вы бы предпочли использовать псевдоним таблицы: SELECT c.id, c.name, c.speed, cp.engine, cp.something FROM cars c LEFT JOIN car_parts cp ON cp.car_id=c.id

Наверное, это самый логичный аргумент на эту тему, который я когда-либо видел, и мне приятно, что я потратил то время на латынь. +1 точно.

Что ж, мне явно нужно пополнить свой словарный запас.

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

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

Убежден - это не отражается. Интересно видеть, что по прошествии всего этого времени популярный выбор «единственного» и «множественного числа» является ошибочным и то и другое!

Поздно к вечеринке, но мне интересно, примените ли вы то же правило к именам переменных в (другом) программировании, когда они содержат несколько элементов одного типа (например, массивы, списки, наборы и т. д.). FrequentCustomerArray, а не FrequentCustomers? Если нет, то чем это отличается?

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

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

«ВЫБРАТЬ ИМЯ ИЗ ПОЛЬЗОВАТЕЛЕЙ» - это предложная фраза - вы извлекаете материал из таблицы пользователей. На самом деле вам нужен случай аблатив. Итак, в английском языке нет разного написания для разных падежей, но аргументы в пользу множественного числа одинаковы - вам нужно имя, которое будет вписываться в предложения, в которых оно используется. Вы говорите: «Выберите эти вещи из списка пользователей», а не «Выберите эти вещи из списка пользователей».

Единственное число не является «не изменяемым», оно просто использует наклонение count по умолчанию для английского языка, что означает единственное, а не множественное число.

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

Не могу больше не согласиться. «Выберите * из пользователей, имя которых похоже на« J% »», потому что я выбираю всех пользователей, имя которых начинается с «J». Если ваш аргумент состоит в том, что вы хотите написать «... где User.Name like ...», просто используйте псевдоним. По той же причине я говорю: «Дайте мне пару носков из всех доступных».

Если бы я был именно таким, имя моей таблицы было бы sock_pair

@AlexandreMartini Совершенно верно. Как некоторые люди, которые называют единственная запись в таблице «отношением».

Готов поспорить, если вы повесите этикетку на ящик для носков, вы назовете его «Носки».

Определенно. Трудно получить один стандарт, который работал бы для всех и для всех, важно, чтобы он работал для вас. Это работает для меня, и здесь я объяснил, почему, но опять же, это для меня, и я нахожу это очень удобным.

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

Причина 6, хорошо, пока вы не попытаетесь вернуть более одного пользователя: P SELECT Customers.CustomerRole FROM Customers WHERE Customers.CustomerRole = 'admin'

Главный вопрос, Крис, заключается в том, почему вы должны следовать соглашениям об именах баз данных при именовании ящика для носков?

@Kyle из-за аналогии Нестора с сумкой / контейнером для яблок (Причина 1). Когда вы обозначаете коробку для перевозки, вы пишете «Книги», а не «Книга».

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

Причина 4 милая, но она бесполезна, если вам придется использовать форму множественного числа в другом месте кода. Допустим, есть модельная функция для получения списка неактивных пользователей, естественно назвать ее getInactiveUsers. Итак, простота становится: (1) особенность SQL для всего. (2) особый класс в коде. (3) для остальных, единственное или множественное число, в зависимости от того, является ли это коллекцией или единичным экземпляром. Моя простота всего лишь (3).

+1 Только по причине 5 (глобализация). Я сталкивался с этой проблемой раньше, и, безусловно, это помогает иностранным программистам использовать единое соглашение об именах для объектов и таблиц.

У меня дома есть ящик для носков, а не ящик для носков. Если бы это была база данных, я бы назвал ее таблицей «Sock».

@Chris Сущность не является «этикеткой» или «коллекцией». Он «должен» определять «экземпляр» ...

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

@Nestor, после прочтения вашего комментария причина 4 теперь имеет смысл. Я действительно продан :)

Настолько плохо, что я не могу проголосовать за этот ответ дважды. Один по причине 1, а другой по причине 4.

Причины 2-6 довольно спорны, если вы согласитесь, что идея многословных языков и ООП предназначена для гуманизации программирования, чтобы концепции были немедленно поняты.

Что касается Причины 1, вы можете оправдать единственное имя, используя имя коллекции с суффиксом, когда речь идет об одном объекте: «Это мой SockDrawer». Однако, когда вы говорите обо всех своих ящиках, вы должны сказать: «Это мои носки, это мои штаны» и т. д. Это потому, что контекст разговора о типе коллекции уже установлен. «Для чего эта таблица? Мои пользователи. Что это за таблица? Моя таблица пользователей. Как вы ее обозначите? Пользователи».

@jlembke: Это ящик с носками. Вы не стали бы называть ящик для носков «носком». Какая аналогия более точна?

@minitech: Это хорошие моменты. Для меня это именно то, что сказали Нестор и Джейсон, я просто думаю, что это работает лучше. Но продолжаем бесполезные споры :) - «Носки», «Штаны» и «Перчатки» все равно обычно употребляются во множественном числе. Может, «Рубашки» лучше. Я слышу «Положите эти рубашки (в частности) в ящик для рубашек (абстрактных)» у себя дома каждый день, а на работе я слышу «Сохраните этих клиентов в таблице клиентов». Но, в конце концов, это не имеет значения. Singular работает лучше для меня по причинам, указанным в этом ответе. И если я увижу базу данных с множественным числом, ничего страшного, но я знаю, что это вызовет некоторые неудобства.

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

У вас есть записи пользователей, а не записи пользователей. Следовательно, у вас есть таблица пользователей, а не таблица пользователей.

@minitech: Да, вы бы не назвали свой ящик для носков "Sock". Но вы МОЖЕТЕ назвать это «Ящик для носков». Таким же образом вы можете назвать пользовательскую таблицу «User_Table». Имена МОГУТ быть в единственном числе, если после них стоит слово «Таблица». Итак, вот как я смотрю на это: представьте, что слово «Таблица» должно появиться в конце всех имен ваших таблиц, но по соглашению слово «Таблица» опускается, оставляя вам только слово в единственном числе. Просто как условность. Когда вы смотрите на имя таблицы, вы видите «Пользователь», но интерпретируете это «Пользовательская таблица». Это может сработать для людей с ОКР вроде меня.

@FriendlyDev: Я прочитал «Таблицу с пользователями». ERR_SUBJECTIVE

@minitech: Я согласен, то, как это можно прочитать, субъективно. Я говорю о другом: причины 1–6 в основном объективны и показывают, что использование единичных имен таблиц более эффективно для целей разработки. Тем не менее, отдельные имена для таблиц иногда выглядят и кажутся неудобными для некоторых людей (вот тут-то и возникает субъективный опыт). Это единственный недостаток, который я вижу в использовании имен в единственном числе. Точка зрения, которой я поделился, помогает мне преодолеть мысленные оговорки относительно использования единственных имен. Я уверен, что такая точка зрения поможет другим более комфортно использовать имена в единственном числе.

@FriendlyDev: Причина 3 - единственная объективная причина в списке. 2 и 5 - одна и та же причина. Причина 6 глупая. Но… ладно.

@minitech: Причина 1 сформулирована не очень хорошо, но объективна. Для обозначения коллекции или набора всегда используется слово в единственном числе. Это никогда не «набор носков» или «коллекция безделушек», но всегда «набор носков» или «коллекция безделушек». Я согласен с тем, что вы можете СМЕНИТЬСЯ на набор или коллекцию, сказав «набор носков» или «набор безделушек», но вы на самом деле не ссылаетесь на фактическое имя набора или самой коллекции, когда ссылаетесь на них таким образом. В «Коллекции пользователей» и «Коллекции пользователей» «Пользователь» - это имя коллекции, «пользователи» - это часть описания коллекции.

@FriendlyDev: Я совершенно не согласен. Меня зовут райан; Вы не называете меня «человеком Райана». «Таблица носков» не подразумевается. (Не согласен? Вот почему это субъективно.)

@minitech: 2 и 5 тесно связаны и могут быть объединены вместе, да, но это не значит, что они необъективны. Также можно доказать, что 4 способствует простоте, что делает 4 объективными. 6 слабоват, но тоже объективен. Все это объективно. И, наконец, вы Райан, но вы не являетесь и никогда не будете набором или коллекцией, поэтому пример с Райаном не является продолжением. Если и существовала группа людей по имени Райан, ее можно было бы назвать «Коллекцией Райана», а не «Коллекцией Райана». «Собрание Райанов» будет относиться к нему, но не к его названию.

Хотя мне нравится этот ответ, мое внимание привлекает URL-адрес stackoverflow.com/questions/.... Я бы поместил «вопросы» в таблицу «вопросы», и URL-адрес без путаницы отражал бы имя таблицы.

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

Что касается вашего примера applebag, я согласен. Но если я создаю таблицу с разными видами яблок, да, я могу создать таблицу с именем Apple [идентификатор, цвет, размер, страна происхождения и т. д...), но если я создаю таблицу, в которой я сохраню все выращенные фрукты в моей стране я могу назвать это фруктами [id, name]?

@shabby Если несколько яблок попадают в таблицу Apple, тогда несколько фруктов попадают в таблицу Fruit. Вы также можете назвать их обоих множественным числом. Единственное, что гарантированно будет недопустимым, - это называть одно единственное число, а другое - множественное.

Прочитав все комментарии, я чувствую, что должен сказать .... SOCK .... +10 к OP за очень хороший ответ!

Причина 7. В случае, если таблица отображает объект, имя таблицы и имя класса будут совпадать, что позволяет избежать дополнительных потерь импеданса при несовпадении имен.

Обычно из ящика вынимают пару носков, а не только один. Вешалка для галстуков, натяжка рубашки, шкаф для обуви, кажется, подтверждают ТОЧНУЮ причину.

Стол новостей так же важен, как стол любви или стол погоды. Все они en.wikipedia.org/wiki/Mass_noun Нет таких вещей, как новости, любовь или погода. Сколько погоды вы хотели бы сегодня?

Недавно я нашел еще одну вескую причину, чтобы придерживаться единственного числа. У меня была таблица, содержащая кучу настроек, где каждый набор представлял собой набор настроек для организации, и я подумал, следует ли мне использовать единственное или множественное число. И тут меня осенило, потому что, очевидно, мне пришлось назвать таблицу «OrganizationSettings». Если бы я использовал множественное число, я бы не смог провести это различие. В этом случае множественное число относится к набору настроек для каждой организации. И вы все равно можете создать таблицу, содержащую разные настройки в каждой строке. Я надеюсь, что смогу донести свою точку зрения.

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

Я должен вызвать тебе по твоему комментарию "AppleBag" с первого пункта. Почему? Потому что, добавляя суффикс «Сумка», вы изменяете его находятся для ссылки на контейнер для чего-то. По той же причине у меня нет проблем, если вы сказали AppleTable, что приравнивается к AppleCollection. Но без описательной части - «таблица» или «коллекция» здесь - вы называете что-то тем, что оно может содержать или не содержать, а не тем, чем оно является сам. Другими словами, вы может говорите «AppleBag содержит яблоки», но вы можете нет сказать «Яблоко содержит яблоки», но вы можете сказать «Элемент с именем« Яблоки »содержит ноль или более объектов яблок».

@jlembke, ты прав. Вы бы назвали это «ящиком для носков», но, по вашему собственному признанию, вы не делаете этого в SQL, потому что если бы это было так, вы бы назвали его «SockTable», чего не делаете. Вы называете это «носком». Как я сказал выше, «ящик для носков содержит предметы для носков». Вы бы не сказали: «Ящик для носков содержит объекты-носки» или «Носок содержит объекты-носки». Вы путаете имя с описанием. На вашем «Ящике для носков» (описание) есть ярлык (название) «Носки», а не «Носки».

Если таблица не предназначена для чтения человеком, назовите ее asdjfhasgkdjagksjdg.

А как насчет наименования самой базы данных? Например, я хочу иметь БД песочницы, которую будут использовать модульные тесты, и я пытаюсь выбрать между UNIT_TEST и UNIT_TESTS.

Основная причина использования единого соглашения об именах: таблицы - это прямое выражение сущности в базе данных на языке ER-модели / реляционной алгебре. Таблица «яблоко» представляет объектное яблоко и содержит «экземпляры» яблока. В ООП имя класса имеет единственное число: «Apple». У вас будет много «яблок» - экземпляров (объектов) типа «Яблоко».

О носках и носках: если бы у меня был такой ящик, я бы, вероятно, назвал его socksDrawer, потому что он такой. Это не «носок» или «носки», это «ящик». Я бы назвал контейнер, а не только то, для чего он используется. Почему бы не назвать таблицу так, как она есть: Таблица пользователей или Таблица пользователей? Это делает обсуждение единственного и множественного числа неуместным в этой области, если оно постоянно используется. Использование такого соглашения об именах таблиц в вашем коде делает его на 100% несомненным, несмотря на дополнительный постфикс.

Причина 1. Представьте, что вы гуляете по городу с сумкой для яблок, и кто-то спрашивает, что у вас с собой. Вы бы ответили: «мой мешок с яблоками» или «яблоки». Но не сказал бы «яблоко», если вы не сумасшедший. Причина 2: слова множественного числа не так уж и сложны. По вашей логике, можно вообще отказаться от множественного числа. Я думаю, что человека это может сбить с толку. Причина 3. Порядок действителен, хотя я не часто упорядочиваю свои таблицы лексикографически. Причина 4: «Customer.CustomerID». Действительно? Причина 5: Перефразирование причины 2. Причина 6: Хорошо, я продана. Множественное число.

Мне не нравится ваша аналогия с AppleBag. Это предполагает, что вам придется назвать таблицу для клиентов CustomerTable вместо Customer.

@Nestor Table с именем AppleBag сбивает с толку? это контейнер для яблок или для пакетов с яблоками. По вашему мнению, таблица с именем Customer является контейнером для клиента. AppleBag - это тип, который хранится внутри таблицы Bags.

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

@ tobia.zanarella, как я уже сказал выше в отношении другого плаката, ваш аргумент, приравнивающий имена классов, неверен, потому что класс представляет собой единственный экземпляр. Он не представляет собой набор вещей. И наоборот, таблица представляет собой набор вещей, представленных строками. Строка - это синоним класса, а не таблицы. Вы не скажете «Sock содержит коллекцию носков», но вы может скажете: «Socks (имя) или SockTable (описание) содержат в себе коллекцию объектов Sock».

@pacoverflow, ваш комментарий именно поэтому таблица должна быть множественного числа. Клиенты ясно показывают, что он содержит коллекцию объектов клиентов. Если это просто «Клиент», то откуда вы знаете, что он не содержит свойств для конкретного клиента? Единственное - неоднозначно. К тому же он не следует правильной грамматике. "Select * From Customers where Name = " Joe "" четко означает, что вы выбираете клиентов с таким именем. Но означает ли «Выбрать * от клиента, где Name = " Joe "» вы выбираете часть клиента, в которой эта часть называется Джо, или вы выбираете целого клиента с этим именем?

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

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

@ChrisWard, вы не называете ящик; в данном случае вы только называете носки. Я имею в виду, что этикетка - это не ящик для носков, а только «носки», которые находятся в ящике для носков.

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

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

Я думаю, это зависит от того, что вы делаете, использовать ли существительные во множественном или единственном числе для имен таблиц. Однако fruit уже во множественном числе - и можно сказать, что у вас есть пара socksнет и пара sock. Socks используется в единственном числе, а Sock Pairs - во множественном. Я считаю, что так оно и есть. ржу не могу. Мне нравится брать отрыв с обеих сторон, и я определенно вижу плюсы использования единственной формы. Отличный ответ!

Мне нравится, как кто-то экономит место на диске, сокращая s в имени таблицы, и тратит гораздо больше места, добавляя к каждому свойству клиента префикс customer.

@Semmel, если вы связываете настройки с организациями, я уверен, что у вас просто таблица соединений

Причина 1 основана на ложных предпосылках «Вы можете думать о сумке, содержащей яблоки, например,« AppleBag », почему это должно быть так?» Имя таблицы должно описывать то, что она содержит, а не количество данных, которые она содержит «она содержит пользователей :) Но даже если он должен быть назван в соответствии с типом, который он содержит, почему это должно быть сделано? вы не указываете причины. Причина 2. (Удобство) Это будет так, только если вы останетесь в своей базе данных. При разработке приложения вам понадобится в любом случае начать иметь дело с именами в единственном и множественном числе. Неспособность сделать это сделает код трудным для чтения.

В любом случае, root-проблема заключается в том, что мы все еще пытаемся сократить естественный язык, и поэтому либо таблицы с префиксом col refs будут страдать (w / множественное число), либо table refs (w / singular), и я считаю, что большинство разработчиков не могут только работать либо с SQL, либо с кодом приложения. На естественном языке вы должны суффикс всегда к вашим ссылкам с именем контейнера (например, «таблица сотрудников / список / электронная таблица» (вместо просто «сотрудники»), но в SQL и коде приложения, даже если мы сделали прогресс при отбрасывании (что когда-то считалось нормальным) 1/2-буквенных имен идентификаторов мы все еще не развили полностью для включения имени контейнера в имена наших идентификаторов.

... так что "выберите Customer.Name из Customer, где Customer.Id = 1" действительно должен быть (чтобы не сокращать естественный язык), "выберите CustomerTable.CurrentRow.Name из CustomerTable, где CustomerTable.CurrentRow.Id = 1"

Мне очень нравится ваш ответ, единственная проблема в том, что происходит, когда вы хотите получить доступ ко всем записям, это выглядит немного странно, например: $ article-> get_all () не имеет смысла, $ article-> all () звучит более семантично, я представил бы, что единственное число будет представлять одну строку и ничего больше

Я пришел сказать что-то похожее на Тома, я иногда думаю о том, чтобы назвать свои таблицы таблицами. Пишу ли я Select * from PeopleTable или Select * from PersonTable - понятно, что я делаю. Некоторое время назад я перешел на код EF, и в VS он автоматически предлагает множественные имена для таблиц, потому что это имеет больше смысла в терминах объектов LINQ и oop. Я понял, что добавляю к объектам ViewModel суффиксы с виртуальной машиной, чтобы прояснить мой код. Тогда я подумал, может быть, модели должны иметь суффикс Model. Но тогда вам придется вызвать стол PersonModelTable - в общем, выберите то, что лучше всего подходит для вашей установки !?

Насколько сложнее добавить «Table», чем «_tbl»?

Для большей ясности определение таблицы на самом деле является определением ОДНОЙ потенциальной строки.

По вашему собственному определению вы дали двум разным объектам одно и то же имя ... объект, который будет помещен в таблицу, и таблицу, которая содержит эти объекты. Если я говорю «Автомобиль», я имею в виду таблицу или запись в этой таблице? Если я говорю «Машины», это ясно, что я имею в виду вещь, которая содержит ноль или более автомобильных объектов. Использование множественного числа правильно отличает предмет от того, что его держит. если бы вы сказали CarTable, это единственное число. Но без суффикса «таблица» вы должны дать ему имя, представляющее то, что в нем содержится. На «Sock Drawer» (единственном числе) есть этикетка (название) «Socks».

Microsoft - это то, чем они являются, в первую очередь по бизнес-причинам (и зачастую по неэтичным причинам), а в последнюю очередь по логическим причинам. Единственная причина, по которой я следую за ними, - это то, что они большие гориллы, и все остальные идут этим путем. Когда у меня есть выбор, я выбираю другой путь.

Две вещи. Во-первых, вы обычно не используете имена таблиц и пишете 'select ID FROM OrderHeaders WHERE Reference =' ABC123 ', потому что вы «выбираете все идентификаторы из OrderHeaders, где что-то верно», но если бы вам пришлось использовать имена таблиц из-за присоединиться или что-то еще, вы должны использовать такой псевдоним ... 'выберите OrderHeader.ID FROM OrderHeaders как OrderHeader ГДЕ OrderHeader.Reference =' ABC123 '

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

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

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

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

Нецелесообразно использовать такое соглашение в мире реляционных моделей, особенно когда вы описываете отношения между объектами, например «В каждой команде может быть только один главный тренер и несколько второстепенных тренеров», что описано: Команда-> Главный тренер, Команда - >> Вторичный тренер.

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