Соглашения об именах баз данных, таблиц и столбцов?

Поздний ответ, но вкратце:

1. Имена таблиц во множественном числе: я предпочитаю использовать множественное число
2. Имена столбцов в единственном числе: Да
3. Префикс таблиц или столбцов:

• Таблицы: * Обычно * лучше не использовать префиксы.
• Столбцы: нет.

4. Используйте любой регистр в именах элементов: PascalCase как для таблиц, так и для столбцов.

Доработка:

(1) Что вы должны делать. Есть databases очень мало вещей, которые variable-naming вы должны делать каждый раз определенным language-agnostic образом, но есть несколько.

• Назовите свои первичные ключи в формате «[singularOfTableName] ID». То есть независимо от того, является ли ваша таблица именем Customer или Customers, первичным ключом должен быть CustomerID.
• Кроме того, внешние ключи должны иметь одинаковые имена в разных таблицах. Бить того, кто этого не делает, должно быть законным. Я хотел бы заявить, что, хотя определенные ограничения внешнего ключа часто важны, согласованное именование внешнего ключа всегда важно
• Ваша база данных должна иметь внутренние соглашения. Хотя в следующих разделах вы увидите, что я очень гибкий, внутри именование базы данных должно быть очень последовательным. Менее важно, называется ли ваша таблица для клиентов Customers или Customer, чем то, что вы делаете это одинаково во всей той же базе данных. И вы можете подбросить монетку, чтобы определить, как использовать символы подчеркивания, но тогда вы должны продолжать использовать их одинаково. Если вы этого не сделаете, вы плохой человек, у которого должна быть низкая самооценка.

(2) Что вам, вероятно, следует делать.

• Поля, представляющие одинаковые данные в разных таблицах, должны называться одинаково. Не используйте Zip на одном столе и ZipCode на другом.
• Чтобы разделять слова в именах таблиц или столбцов, используйте PascalCasing. Использование camelCasing по сути не было бы проблемой, но это не соглашение, и это выглядело бы забавно. Я обращусь к символам подчеркивания через минуту. (Вы не можете использовать ALLCAPS, как в былые времена. OBNOXIOUSTABLE.ANNOYING_COLUMN было нормально в DB2 20 лет назад, но не сейчас.)
• Не сокращайте и не сокращайте слова искусственно. Лучше, чтобы имя было длинным и ясным, чем коротким и запутанным. Ультракороткие имена - это пережиток более темных и жестоких времен. Cus_AddRef. Что это такое? Ссылка на адресата-хранителя? Дополнительный возврат клиенту? Пользовательский переход по адресу?

(3) Что следует учесть.

• Я действительно считаю, что имена таблиц должны быть во множественном числе; некоторые думают, что это нечто особенное. Прочтите аргументы в другом месте. Однако имена столбцов должны быть в единственном числе. Даже если вы используете имена таблиц во множественном числе, таблицы, представляющие комбинации других таблиц, могут быть в единственном числе. Например, если у вас есть таблица Promotions и Items, таблица, представляющая элемент, являющийся частью рекламной акции, может быть Promotions_Items, но она также может законно быть Promotion_Items I думать (отражая отношения "один ко многим").
• Используйте символы подчеркивания последовательно и для определенной цели. Просто общие имена таблиц должны быть достаточно ясными с PascalCasing; вам не нужны подчеркивания для разделения слов. Сохраните символы подчеркивания (а) для обозначения ассоциативной таблицы или (б) для префикса, о чем я расскажу в следующем пункте.
• Префикс - это ни хорошо, ни плохо. Это обычно не самое лучшее. В ваших первых или двух базах данных я бы не предлагал использовать префиксы для общей тематической группировки таблиц. Таблицы в конечном итоге не соответствуют вашим категориям, и это может фактически сделать поиск таблиц сложнее. Имея опыт, вы можете спланировать и применить схему префиксов, которая принесет больше пользы, чем вреда. Однажды я работал в базе данных, где таблицы данных начинались с tbl, таблицы конфигурации с ctbl, представления с vew, proc sp и fn udf и некоторые другие; его применяли тщательно и последовательно, так что все прошло хорошо. Единственный раз, когда вам НУЖНЫ префиксы, это когда у вас действительно отдельные решения, которые по какой-то причине находятся в одной базе данных; их префикс может быть очень полезным при группировке таблиц. Префикс также подходит для особых ситуаций, например для временных таблиц, которые вы хотите выделить.
• Очень редко (если вообще когда-либо) вы бы хотели для префикса столбцов.