В Academia указано, что имена таблиц должны быть единственными сущностями, в которых хранятся атрибуты.
Мне не нравится любой T-SQL, для которого требуются квадратные скобки вокруг имен, но я переименовал таблицу Users в единственное число, навсегда приговаривая тех, кто использует таблицу, чтобы иногда использовать скобки.
Я чувствую, что правильнее оставаться с единственным, но мое чувство кишки также заключается в том, что скобки указывают на нежелательные имена, такие как имена столбцов с пробелами в них и т.д.
Должен ли я остаться, или я должен идти?
Другие дали довольно хорошие ответы, поскольку "стандарты" идут, но я просто хотел добавить это... Возможно ли, что "Пользователь" (или "Пользователи" ) на самом деле не является полным описанием данных, хранящихся в таблице? Не то, чтобы вы были слишком сумасшедшими с именами таблиц и спецификой, но, возможно, что-то вроде "Widget_Users" (где "Виджет" - это имя вашего приложения или веб-сайта) было бы более подходящим.
У меня был такой же вопрос, и после прочтения всех ответов здесь я определенно останусь с SINGULAR, причины:
Причина 1 (Концепция). Вы можете подумать о сумке с яблоками типа "AppleBag", не имеет значения, содержит ли она 0, 1 или миллион яблок, это всегда одна и та же сумка. Таблицы - это просто контейнеры, имя таблицы должно описывать, что она содержит, а не сколько данных она содержит. Кроме того, понятие множественного числа больше относится к разговорной речи (фактически, чтобы определить, есть ли один или несколько).
Причина 2. (Удобство). легче выходить с единичными именами, чем с множественными. Объекты могут иметь неправильное множественное число или вообще не иметь множественное число, но всегда будут иметь единственное число (за некоторыми исключениями, такими как Новости).
Причина 3. (Эстетика и порядок). Особенно в сценариях мастер-детали, он лучше читается, лучше выравнивается по имени и имеет более логичный порядок (сначала мастер, потом второй):
По сравнению с:
Причина 4 (Простота). Соберите все вместе, имена таблиц, первичные ключи, отношения, классы сущностей... лучше знать только одно имя (единственное) вместо двух (единственное число, таблица во множественном числе, поле единственного числа, основная деталь во множественном числе единственного числа).).
CustomerCustomer.CustomerIDCustomerAddresspublic Class Customer {...}SELECT FROM Customer WHERE CustomerID = 100Как только вы узнаете, что имеете дело с "Клиентом", вы можете быть уверены, что будете использовать одно и то же слово для всех ваших потребностей взаимодействия с базой данных.
Причина 5. (Глобализация). Мир становится меньше, у вас может быть команда разных национальностей, не у всех есть английский как родной язык. Для программиста, не являющегося носителем английского языка, было бы проще думать о "Репозитории", чем о "Репозитории" или "Статусе" вместо "Статусы". Наличие единичных имен может привести к меньшему количеству ошибок, вызванных опечатками, сэкономить время, не думая "это ребенок или дети?", А значит, повысить производительность труда.
Причина 6. (Почему нет?). Это может даже сэкономить ваше время записи, сэкономить дисковое пространство и даже продлить срок службы клавиатуры компьютера!
SELECT Customer.CustomerName FROM Customer WHERE Customer.CustomerID = 100SELECT Customers.CustomerName FROM Customers WHERE Customers.CustomerID = 100Вы сохранили 3 буквы, 3 байта, 3 дополнительных нажатия клавиш :)
И, наконец, вы можете назвать тех, кто работает с зарезервированными именами, например:
Или используйте печально известные квадратные скобки [Пользователь]
В своей книге " Стиль программирования SQL" Джо Целько предполагает, что коллекция (например, таблица) должна быть названа во множественном числе, в то время как скалярный элемент данных (например, столбец) должен быть назван в единственном числе.
Он цитирует ISO-11179-4 как стандарт для именования метаданных, который поддерживает это руководство.
Позвольте мне объяснить, почему это имеет смысл.
args в программе Java.args во множественном числе, поскольку они могут содержать 0, 1 и миллионы аргументов.for every student in students, а не for every s in student. Вы выбираете подмножество студентов из набора учеников. Вы не выбираете подмножество студентов от ученика. Это концептуальная причина правильного именования.Нарушение заблуждений. самый популярный ответ говорит
Причина 1 (концепция). Вы можете думать о сумке, содержащей яблоки, как "AppleBag", это не имеет значения, если содержит 0, 1 или миллион яблок, это всегда одна и та же сумка. Столы только таковы, контейнеры, стол имя должно описывать, что он содержит, а не то, сколько данных оно содержит. Кроме того, концепция множественного числа больше относится к разговорной речи (на самом деле определить, есть ли один или несколько), таблица не предназначенный для чтения человеком.
Позволяет конвертировать AppleBag = > BagOfApples. Теперь один и тот же "концептуальный" аргумент говорит о том, что он противоположен самому себе, мы видим Apple s, и поэтому ответ должен быть множественным числом!
Это потому, что в этом **** нет ничего концептуального. Он не может даже рассуждать об английском языке, простой логике. На английском языке BagOfApples != AnApple!
Аргумент "Сумка содержит 0,1,... миллионы" яблок просто доказывает, что коллекция должна называться "Яблоки", аналогичные аргументы Java или fooobar.com/questions/10898/.... Так или иначе, врагам цивилизации удается заключить, что единственное должно быть использовано здесь. Посты - это всего лишь папка. Почему это должно быть множественное число?
Пусть учить мр. Артувуд немного логичен: folder is a folder and must describe what it contains, not how much data it contains.
На самом деле, если вы начинаете думать, что понимаете, что apple contains apple описывает бессмыслицу. Истинная концепция такова, что Bag contains Apples. Либо мы называем наш контейнерный мешок (определенного вида), либо думаем, что он содержит, Яблоки (эти грязные ублюдки пытались уменьшить это до нумерации. яблоки, а не их число.). Да, если мы отбросим оболочку, мы поймем, что мы после Apples, что содержится в ней. Мы забираем и итерируем либо Сумку, либо Яблоки, а не яблоко.
Причина 2. (Удобство). легче выходить с единственными именами, чем с множественными. Объекты могут иметь нерегулярные множественные числа или нет во множественном числе, но всегда будет иметь единственное (с несколькими исключения, такие как News).
Информация о статусе пользователя клиента
О каком удобстве он говорит? Давайте просто укажем, что это множественное число получается проще, чем единственные.
Причина 3. (Эстетика и порядок).
Эстетика на нашей стороне. Это просто, как и он. Мы просто утверждаем, что это все, что необходимо для поворота таблицы.
Причина 4 (простота). Все вместе, имена таблиц, первичные ключи, Отношения, классы сущностей... лучше знать только одну имя (единственное) вместо двух (особый класс, множественная таблица, единственная поле, сингулярно-множественное главное-подробно...)
Я один, видя, что для простоты все должно стать единичным? Да, забудьте множественное число, используя английский язык. Это упростит ситуацию.
Фактически, на многих языках секс привязан ко всем вещам, а не только к мальчикам и девочкам. Это глупо и делает язык излишне сложным. Но я заметил, что это упрощает ссылку. Когда я говорю "лиса, собака и волк" по-русски, а затем говорю "он", это однозначно означает, что я ссылаюсь на "волк", потому что "лиса" и "собака" - это "она". Теперь вы говорите, что это делает различие, которое помогает уменьшить двусмысленность. Как это так?
Вероятно, логика "пусть держит произвольное дерьмо на нашем языке и принуждает беспорядок, удаляя правила, которые имеют смысл". Да, предложение использовать единственное, где логика требует множественного числа, сохраняя при этом неприемлемые атрибуты, такие как секс, к неуместным предметам - это стремление к бессмыслице в нашем сумасшедшем мире.
По состоянию
SELECT activity.name читается лучше, чем SELECT activities.name
Вероятно, вам нужно SELECT student.name FROM students as student
Хорошо, здесь, вероятно, есть аргумент: как псевдоним таблицы является единственным, если таблица является множественной? Хорошо, это имеет смысл. Но говоря, что столбец (атрибут объекта) является особым, поэтому коллекция объектов также должна быть исключительной, это бессмыслица.
Причина 5. (Глобализация). Мир становится все меньше, вы можете команда разных национальностей, не у всех есть английский как родной язык. Было бы проще для не-родного программиста на английском языке думать о "репозитории", чем о "репозиториях", или избегать их типа "Статусы" вместо "Статус". Наличие особых имен может привести к меньшему ошибки, вызванные опечатками, сэкономить время, не тратя лишних секунд на подумайте "это ребенок или дети?", следовательно, повышая производительность.
Этот фанатик, несомненно, сломает его разум. Но почему другие неродные носители, такие как я, должны покупать вздор "для простоты и интернационализации"? Почему бы не улучшить наш английский и не поддерживать логику? В конце концов, гораздо легче понять язык.
В противном случае мы должны также отказаться от глаголов, статей, прилагательных и говорить только в существительных, для простоты. Это было бы проще (и более продуктивно), если бы мы ограничили нашу речь moooo и ничего больше, потому что животные могли говорить по-английски. Таким образом, мы достигаем гораздо более широкой интернационализации.
Причина 6. (Почему нет?). Это может даже сэкономить вам время на запись, сэкономить диск пространство и даже сделать клавиатуру вашего компьютера больше!
Этот аргумент подтверждает, почему мы должны отказаться от множественного числа в нашем человеческом сообществе. Нет, вместо moooo, mo moo, moo moo, мы скажем I, III, III, II. Гораздо короче, чем с единственным предложением.
Суть в том, что все "аргументы" против множественного числа - это чистая ерунда. Если вы думаете об этом, он говорит против единственного числа. Когда все, что вам нужно для поддержки своей позиции, это дерьмо, это означает, что вам нужна дерьмо, чтобы поддержать ваше мнение, вы на неправильной стороне.
Единственным значимым аргументом для единственного является то, что таблица представляет собой очень специальный набор объектов. Таблица - это класс! Да, он содержит все объекты определенного типа, и мы используем исключительные имена классов. Класс Dog содержит всех собак. Что такое собака1? Это собака. С другой стороны, пользователи рассматривают таблицы как коллекции. Они добавляют/удаляют элементы в коллекцию, и мы используем множественное число для коллекций.
Если вы используете инструменты реляционного сопоставления объектов или в будущем я предлагаю Singular.
Некоторые инструменты, такие как LLBLGen, могут автоматически корректировать множественные имена, такие как пользователи для пользователя, без изменения самого имени таблицы. Почему это имеет значение? Потому что когда он сопоставлен, вы хотите, чтобы он выглядел как User.Name, а не Users.Name или хуже из некоторых моих старых таблиц баз данных, называющих tblUsers.strName, которое просто запутывается в коде.
Мое новое правило состоит в том, чтобы судить, как оно будет выглядеть, когда оно будет преобразовано в объект.
одна таблица, которую я нашел, не подходит для нового имени, которое я использую, это UserInRoles. Но всегда будут те немногие исключения, и даже в этом случае он отлично выглядит как UserInRoles.Username.
Я предпочитаю использовать существительное uninflected, которое на английском языке является сингулярным.
Включение числа имен таблиц вызывает проблемы с орфографией (как видно из многих других ответов), но предпочитая это делать, потому что таблицы обычно содержат несколько строк, также семантически заполнены дырками. Это более очевидно, если мы рассматриваем язык, который изменяет существительные на основе case (как и большинство):
Поскольку мы обычно делаем что-то со строками, почему бы не поместить имя в винительный падеж? Если у нас есть таблица, которую мы пишем больше, чем читаем, почему бы не поместить имя в дательный? Это таблица чего-то, почему бы не использовать родительный падеж? Мы не будем этого делать, потому что таблица определяется как абстрактный контейнер, который существует независимо от его состояния или использования. Воспламенение существительного без точной и абсолютной семантической причины - лепет.
Использование неинфицированного существительного является простым, логичным, регулярным и независимым от языка.
Какое соглашение требует, чтобы таблицы имели уникальные имена? Я всегда думал, что это множественные имена.
Пользователь добавляется в таблицу 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 в последнем имеет более странное звучание, чем первое.
Я проголосую за единственное.
Я твердо убежден в том, что в диаграмме отношения сущностей объект должен отражаться с единственным именем, аналогичным тому, что имя класса является единственным. После создания экземпляра имя отражает его экземпляр. Таким образом, с базами данных объект, когда он заключен в таблицу (совокупность объектов или записей), является множественным. Entity, Пользователь внесен в таблицу Users. Я согласен с другими, которые предположили, что имя пользователя может быть улучшено для Employee или что-то более применимое к вашему сценарию.
В этом случае смысл в выражении SQL, потому что вы выбираете из группы записей и если имя таблицы является единственным, оно не читается хорошо.
Я использую единственное для имен таблиц и любого объекта программирования.
Причина? Тот факт, что на английском языке есть нерегулярные множественные числа, такие как мышь ⇒ мыши и овцы ⇒ овец. Тогда, если мне нужна коллекция, я просто использую мышей или овец и двигаюсь дальше.
Это действительно помогает выделить множество, и я могу легко и программно определить, как будет выглядеть коллекция вещей.
Итак, мое правило: все сингулярно, каждая коллекция вещей является единственной с прилагаемой. Помогает с ORM тоже.
ИМХО, имена таблиц должны быть множественными как Клиенты.
Имена классов должны быть уникальными, как Customer, если они сопоставляются с строкой в таблице Customers.
болванка. Я не покупаю никаких аргументов, которые наиболее логичны - каждый считает, что его собственное предпочтение наиболее логично. Независимо от того, что вы делаете, это беспорядок, просто выберите конвенцию и придерживайтесь ее. Мы пытаемся сопоставить язык с очень нерегулярной грамматикой и семантикой (нормальным устным и письменным языком) с очень регулярной (SQL) грамматикой с очень специфической семантикой.
Моим главным аргументом является то, что я не думаю о таблицах как о наборе, а как об отношениях.
Итак, отношение AppUser указывает, какие объекты AppUsers.
Отношение AppUserGroup сообщает мне, какие объекты AppUserGroups
Отношение AppUser_AppUserGroup говорит мне, как связаны AppUsers и AppUserGroups.
Отношение AppUserGroup_AppUserGroup указывает мне, как связаны AppUserGroups и AppUserGroups (т.е. члены группы из групп).
Другими словами, когда я думаю об объектах и о том, как они связаны, я думаю о связях в единственном числе, но, конечно, когда я думаю о сущности в коллекциях или наборах, коллекции или множества являются множественными.
В моем коде, затем, и в схеме базы данных, я использую единственное число. В текстовых описаниях я использую множественное число для повышения удобочитаемости - затем используйте шрифты и т.д., Чтобы отличить имя таблицы/отношения от множественного числа s.
Мне нравится думать, что это беспорядочно, но систематично - и таким образом всегда существует систематически сгенерированное имя для отношения, которое я хочу выразить, что для меня очень важно.
Я также поеду с множественными числами, и с вышеупомянутой дилеммой пользователей мы возьмем квадратный брекетинг.
Мы делаем это, чтобы обеспечить единообразие как между архитектурой базы данных, так и с архитектурой приложения, с пониманием того, что таблица Users представляет собой набор значений Пользователя, а коллекция пользователей в артефакте кода представляет собой коллекцию объектов User.
Благодаря тому, что наша команда данных и наши разработчики, говорящие на одном и том же концептуальном языке (хотя и не всегда одинаковые имена объектов), облегчают передачу идей между ними.
Я предпочитаю использовать множественные имена для представления набора, он просто "звучит" лучше для моего реляционного ума.
В этот момент я использую уникальные имена для определения модели данных для своей компании, потому что большинство людей на работе чувствуют себя более комфортно с ней. Иногда вам просто нужно сделать жизнь проще для всех, вместо того, чтобы навязывать свои личные предпочтения. (что, как я оказался в этом потоке, получить подтверждение того, что должно быть "лучшей практикой" для именования таблиц)
Прочитав все аргументы в этом потоке, я пришел к одному выводу:
Мне нравятся мои блины с медом, какой бы ни был любимый вкус. Но если я готовлю для других людей, я постараюсь служить им, что им нравится.
болванка. Я бы назвал массив, содержащий кучу пользовательских объектов-представлений объектов-пользователей, но таблица представляет собой "таблицу пользователя". Мысль о том, что таблица является не чем иным, как набором строк, которые она содержит, ошибочна, ИМО; таблица - это метаданные, а набор строк иерархически привязан к таблице, это не сама таблица.
Я использую ORM все время, конечно, и это помогает, чтобы код ORM, написанный с именами множества таблиц, выглядел глупо.
Мне не нравятся имена множественных таблиц, потому что некоторые существительные на английском языке не являются счетными (вода, суп, наличные деньги) или значение изменяется, когда вы делаете его счетным (курица против цыпленка, мясо против птицы). Мне также не нравится использование сокращений для имени таблицы или имени столбца, потому что это добавляет дополнительный уклон к уже крутой кривой обучения.
Как ни странно, я мог бы сделать 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 - путь мимо их предполагаемых сроков жизни.
Я на самом деле всегда считал популярным соглашение использовать множественные имена таблиц. До этого момента я всегда использовал множественное число.
Я могу понять аргумент для имен уникальных таблиц, но для меня больше множественного числа. Имя таблицы обычно описывает то, что содержит таблица. В нормализованной базе данных каждая таблица содержит определенные наборы данных. Каждая строка является сущностью, а таблица содержит множество объектов. Таким образом, форма множественного числа для имени таблицы.
Таблица автомобилей будет иметь название машины, и каждый ряд - автомобиль. Я соглашусь, что указание таблицы вместе с полем в стиле table.field является наилучшей практикой и что наличие уникальных имен таблиц более читаемо. Однако в следующих двух примерах первый имеет смысл:
SELECT * FROM cars WHERE color='blue'
SELECT * FROM car WHERE color='blue'
Честно говоря, я буду переосмысливать свою позицию по этому вопросу, и я буду полагаться на фактические соглашения, используемые организацией, для которой я развиваюсь. Тем не менее, я думаю, что для моих личных соглашений я буду придерживаться множественных имен таблиц. Для меня это имеет смысл.
Таблицы: множественное число
Несколько пользователей перечислены в таблице пользователей.
Модели: сингулярные
Пользовательский пользователь может быть выбран из таблицы пользователей.
Контроллеры: множественное число
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
Что касается префикса таблиц и представлений, я абсолютно ненавижу эту практику. Дайте человеку никакой информации вообще, прежде чем давать им, возможно, плохую информацию. Любой, кто просматривает db для объектов, может легко рассказать таблицу из представления, но если у меня есть таблица с именем tblUsers, по какой-то причине я решил реструктурировать в будущем на две таблицы, с целью объединения их, чтобы не нарушать старый код Теперь у меня есть вид tblUsers. На этом этапе у меня остались два непривлекательных варианта, оставьте вид с именем с префиксом tbl, который может запутать некоторых разработчиков, или заставить другой уровень, либо средний уровень, либо приложение, которое будет переписано, чтобы ссылаться на мою новую структуру или имя viewUsers. Это отрицает значительную часть значения представлений IMHO.
Возможные альтернативы:
ИМО с использованием скобок - технически самый безопасный подход, хотя он немного громоздкий. ИМО это 6 из одного, полдюжины других, и ваше решение действительно просто сводится к личным/командным предпочтениям.
Это может быть немного избыточно, но я бы посоветовал быть осторожным. Не обязательно, что это плохо для переименования таблиц, но стандартизация именно такова; стандарт - эта база данных уже может быть "стандартизирована", как бы плохо она ни была). Я бы предложил, чтобы последовательность была лучшей целью, поскольку эта база данных уже существует и, по-видимому, состоит из более чем двух таблиц.
Если вы не можете стандартизировать всю базу данных или, по крайней мере, планируете работать в этом направлении, я подозреваю, что имена таблиц - это всего лишь верхушка айсберга и сосредоточение внимания на задаче, перенося боль слабо названных объектов, может быть в ваших интересах -
Практическая последовательность иногда является лучшим стандартом...:)
my2cents ---
Мой выбор в семантике зависит от того, как вы определяете свой контейнер. Например, "Мешок с яблоками" или просто "яблоки" или "яблочный мешок" или "яблоко".
Пример: стол "колледжа" может содержать 0 или более колледжей таблица "колледжей" может содержать 0 или более коллег.
a "student" table can contain 0 or more students
a table of "students" can contain 0 or more students.
Мое заключение состоит в том, что либо все в порядке, но вы должны определить, как вы (или люди, взаимодействующие с ним) подходите к обращению к таблицам; "таблица x" или "таблица xs"
Если мы посмотрим на системные таблицы MS SQL Server, их имена, присвоенные Microsoft, находятся в plural.
Системные таблицы Oracle названы в singular. Хотя некоторые из них во множественном числе.
Oracle рекомендует множественное число для пользовательских имен таблиц.
Это не имеет большого смысла, что они рекомендуют одно и следуют другому.
То, что архитекторы этих двух программных гигантов назвали свои таблицы, используя разные соглашения, тоже не имеет особого смысла... В конце концов, что это за ребята... Кандидаты наук?
Я помню, в научных кругах эта рекомендация была единственной.
Например, когда мы говорим:
select OrderHeader.ID FROM OrderHeader WHERE OrderHeader.Reference = 'ABC123'
может быть б/ц каждый ID выбирается из определенной отдельной строки...?
Как упоминалось выше, соглашения должны быть инструментом для упрощения использования и удобочитаемости. Не как кандалы или клуб, чтобы пытать разработчиков.
Тем не менее, мое личное предпочтение заключается в использовании особых имен для таблиц и столбцов. Это, вероятно, происходит из моего программирования. Названия классов обычно являются единственными, если только они не являются какой-то коллекцией. По моему мнению, я храню или читаю отдельные записи в рассматриваемой таблице, поэтому сингулярность имеет смысл для меня.
Эта практика также позволяет мне резервировать множественные имена таблиц для тех, которые хранят отношения "многие ко многим" между моими объектами.
Я стараюсь избегать зарезервированных слов в своих именах таблиц и столбцов. В рассматриваемом случае имеет смысл идти вразрез с сингулярным соглашением для пользователей, чтобы избежать необходимости инкапсулировать таблицу, в которой используется зарезервированное слово пользователя.
Мне нравится использовать префиксы ограниченным образом (tbl для имен таблиц, sp_ для имен proc и т.д.), хотя многие считают, что это добавляет беспорядок. Я также предпочитаю имена CamelBack для подчеркивания, потому что во время ввода имени я всегда нажимаю вместо + вместо _. Многие другие не согласны.
Вот еще одна хорошая ссылка для рекомендаций по именованию: http://www.xaprb.com/blog/2008/10/26/the-power-of-a-good-sql-naming-convention/
Помните, что самым важным фактором в вашем соглашении является то, что он имеет смысл для людей, взаимодействующих с соответствующей базой данных. Нет никакого "единого кольца для их правильного управления", когда речь идет об условных обозначениях.
Я думаю, что использование единственного - это то, чему нас учили в университете. Но в то же время вы можете утверждать, что в отличие от объектно-ориентированного программирования таблица не является экземпляром ее записей.
Думаю, я сейчас склоняюсь к сингулярности в связи с множественными нарушениями на английском языке. На немецком языке это еще хуже из-за отсутствия последовательных множественных форм - иногда вы не можете определить, является ли слово множественным или нет, без указания статьи перед ним (der/die/das). И на китайском языке в любом случае нет множественных форм.
Я всегда использовал единственное, просто потому, что меня учили. Однако при создании новой схемы в последнее время, впервые за долгое время, я активно решил сохранить это соглашение просто потому, что... он короче. Добавление 's' в конец каждого имени таблицы кажется мне бесполезным, добавляя 'tbl_' перед каждым.
Я когда-то использовал "чувак" для таблицы "Пользователь" - такое же короткое количество символов, не конфликтуя с ключевыми словами, все еще ссылаясь на родового человека. Если бы меня не интересовали душные головы, которые могли бы видеть код, я бы сохранил его таким образом.
Я всегда думал, что это было немой конвенцией. Я использую множественные имена таблиц.
(Я считаю, что рациональная стратегия заключается в том, что она упрощает создание генераторов кода ORM для создания классов объектов и коллекций, поскольку проще создавать множественное имя из уникального имени, чем наоборот)
Я использую только имена для имен таблиц, которые пишутся одинаково: единственное или множественное:
лосей рыба олень самолет вы брюки шорты очки ножницы вид потомство