Какова наилучшая практика именования таблиц базы данных для обеспечения естественной организации?

Question

Мы помещаем общие префиксы в связанные таблицы, чтобы они отображались рядом друг с другом в нашем программном обеспечении для управления БД (Toad, Enterprise Manager и т. Д.).

Так, например, все пользовательские таблицы начинаются со слова User:

• Пользователь
• UserEvent
• UserPurchase

В идеале, в честь трех великих достоинств программиста эти таблицы должны называться соответственно Пользователь, Событие, Покупка, чтобы сохранить некоторую печать, согласились?

Является ли это соглашение об именах лучшей (единственной?) Практикой для естественного объединения связанных таблиц?

Answer 1

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

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

2. Я почти полностью игнорирую длины имен. Я гораздо больше обеспокоен удобочитаемостью и понятностью, чем продолжительностью 1/10 секунды для ввода названия столбца или таблицы. Когда вы также помните, что все время тратится впустую, пытаясь вспомнить, сокращали ли вы «число» как «нет», «num» или «nbr», и помните об использовании таких вещей, как Intellisense, использование более длинных и значимых имен ежу понятно для меня.

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

Надеюсь, это поможет!

Answer 2

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

Прочтите книгу Джо Селко " Стиль программирования SQL ." Его первая глава в этой книге посвящена соглашениям об именах, руководствуясь стандартом ISO 11179 для именования метаданных. Одна из его рекомендаций - избегать ненужных префиксов в соглашении об именах.

Answer 3

Я бы использовал это обозначение, т. Е. «UserEvent», если эта таблица представляет отношение «многие ко многим» между таблицами «Пользователь» и «Событие».

Answer 4

Я предполагаю, что соглашение об именах в SQL соответствует или, по крайней мере, должно следовать тем же правилам, что и в других языках программирования. Я всегда предпочитал имена переменных / имена классов, которые четко указывали цель и, как правило, означали больше печатания. Я думаю, что важно помнить, что код пишется только один раз, но читается много раз, поэтому ясность крайне важна. За последние 4 или 5 лет я заметил, что имена переменных выросли с «eDS» до «employeeDataSet», и я думаю, что IntelliSense является основной причиной этого. Я думаю, что мы увидим то же самое в SQL, поскольку Red Gate SQL Prompt и теперь MS SQL2008 внедрили Intellisense в мире баз данных mainstrem.

Answer 5

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

• Пользователи (Id int, Имя varchar)
• Аккаунты (Id int, Имя varchar)
• Логины (Id int, Имя varchar)
• События (Id int, Имя varchar)
• UserEvents (UserId int, EventId int)
• AccountEvents (AccountId int, EventId int)
• LoginEvents (LoginId int, EventId int)

Answer 6

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

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

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

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

Answer 7

Лично я переименую свои таблицы следующим образом:

• Основные таблицы: tbl_user
• Справочные таблицы: ref_profil
• Связанные таблицы: lnk_user_profil

Answer 8

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