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

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

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

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

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

• Клиент
• Заказ
• Пользователь
• Статус
• Новости

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

• 1. заказ
• 2.OrderDetail

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

• 1.OrderDetails
• 2. заказы

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

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

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

Причина 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, ...

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

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

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

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

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

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

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

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

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

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

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

Этот сайт соглашается:
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"

vs.

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

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

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

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

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

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

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

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

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

ИМХО, имена таблиц должны быть во множественном числе, например, Customers.

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

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

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

Итак, отношение AppUser сообщает, какие объекты являются AppUsers.

Отношение AppUserGroup сообщает мне, какие объекты AppUserGroups

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В таблице пользователей указано несколько пользователей.

Модели: единичные

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

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

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

Во всяком случае, это мое мнение.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

my2cents ---

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

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

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

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

Пример: таблица "колледж" может содержать 0 или более колледжей, таблица "колледжи" может содержать 0 или более коллег.

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

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

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

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

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

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

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

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

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

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

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

Однажды я использовал "Dude" для таблицы User - такое же короткое количество символов, никаких конфликтов с ключевыми словами, все еще ссылка на обычного человека. Если бы меня не беспокоили идиоты, которые могут увидеть код, я бы так и оставил.

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

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

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

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

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

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

Руководства действительно существуют именно так. Это не «высечено в камне», поэтому у вас есть возможность игнорировать их.

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

• tblUser
• tblThis
• tbl Это
• tblTheOther

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

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

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

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

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

Например, мне нужно получить все поля от пользователя:

-- Select every fields from 'user' table
SELECT * FROM user

Мне нужно имя пользователя, которому 21 год:

-- Select every fields from 'user' table which have 21 years old
SELECT * FROM user WHERE age = '21'

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

Не существует "соглашения", которое требовало бы, чтобы имена таблиц были единственными.

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

По поводу другой проблемы (цитаты) это зависит от диалекта SQL. Oracle не требует заключать имена таблиц в кавычки.

Если вы используете определенные фреймворки, такие как Zend Framework (PHP), разумно использовать множественное число для классов таблиц и единственное для классов строк.

Скажем, вы создали объект таблицы $ users = new Users () и объявили класс строки как User, вы также сможете вызвать new User ().

Теперь, если вы используете единственное число для имен таблиц, вам нужно будет сделать что-то вроде new UserTable () с строкой new UserRow (). Мне это кажется более неуклюжим, чем наличие объекта Users () для таблицы и объектов User () для строк.

Имя ТАБЛИЦЫ - это ОДНО определение структуры таблицы. Имя VIEW или QUERY - это ОДНО определение представления или запроса (нескольких) таблиц. ТАБЛИЦА, ПРОСМОТР или ЗАПРОС могут содержать одно из следующего:

0 записей 1 запись Много записей.

Зачем вам нужно ставить букву «s» в конце имени одного объекта? Что вы хотите обозначить, поставив букву «s» в конце имени объекта?

Если вы хотите различать, добавьте _tbl. Представление - это _vew (а не глупое соглашение о _v).

Минимум 3 символа суффикса - это останавливает эту дискуссию.

Таблица - это объект БД, ничем не отличающийся от других.

Сохранение трех знаков ничего не спасает, кроме ясности смысла.

Красный ;-)

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

Что мне не нравится в именах таблиц во множественном числе, так это то, что комбинированные имена могут быть довольно странными. Если, например, у вас есть таблица с именем Users и вы хотите сохранить свойства для пользователя, это приведет к таблице с именем _2 _...

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

1) в соотв. к тому, что содержится в таблице, например: таблица пользователей. Всегда будет множественное число. Итак, Пользователи

2) в соотв. к тому, что содержится в записи, например: запись в таблицах пользователей будет одним пользователем. SO, Пользователь.

Теперь проблема в основном для пользователей. случай 1: соотв. к первому соглашению об именах, users_roles Что это имя предполагает, пользователей и их роли.

случай 2: в соотв. ко второму соглашению об именах, user_role Что означает это имя, user и его роли.

Хорошее соглашение об именах должно дать дополнительное представление об отношениях сущностей, особенно когда хранятся отношения "многие ко многим".

Здесь, согласно сценарию, мы должны идентифицироваться как наборы информации.

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

I would prefer,
Users table => user
Roles table => role
users role relationship table => user_roles

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

Мне нравится, как вы это читаете:

SELECT CustomerName FROM Customers WHERE CustomerID = 100;

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

Другой пример, у вас есть таблица Teams, которая хранит TeamID, TeamColor, но также PlayerID, и будет иметь одинаковые teamID и TeamColor для определенного количества PlayerID ...

К какой команде принадлежит игрок?

SELECT * FROM Teams WHERE PlayerID = X

Все игроки из X Team?

SELECT * FROM Players INNER JOIN Teams ON Players.PlayerID = Teams.PlayerID WHERE Teams.TeamID = X

Тебе все это хорошо?

В любом случае, также обратите внимание на соглашения об именах, используемые W3Schools:

http://www.w3schools.com/sql/sql_join_inner.asp

Я решил ту же проблему, назвав таблицу «Сотрудник» (на самом деле «Сотрудники»). Я стараюсь держаться как можно дальше от любых конфликтов с возможно зарезервированными словами. Даже «Юзеры» мне неприятно близки.