Стандарты именования объектов базы данных

Стандарты именования объектов базы данных

Часть I: Таблицы

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

Правила именования таблиц

В единственном числе Имена таблиц всегда в единственном числе; Goose вместо Geese, Crow вместо Crows и Whale, а не Whales. Достаточно просто. Однако, говоря о единственном числе, это не исключает собирательных терминов. Таким образом, Gaggle, Murder и Pod будут вполне подходящими именами таблиц, а Gaggles, Murders и Pods - нет. Чтобы понять почему, полезно подумать о столбцах, которые в конечном итоге заполнят эту таблицу, и, в частности, о том, как будет звучать сочетание имени таблицы и имени столбца при чтении или обсуждении. Я бы сказал, что Crow.nm (например, «имя вороны») и Crow.dsc («описание вороны») имеют больше смысла, чем эквиваленты во множественном числе («имя вороны» и «описание вороны»). Или, другими словами, столбцы имени и описания относятся к конкретной вороне в одной строке таблицы, а не ко всей популяции ворон во всех строках таблицы.

Одно существительное Я стремлюсь к тому, чтобы одно существительное лучше всего описывало набор данных, содержащихся в таблице: чем проще имя, тем более очевидными становятся таблица и ее содержимое. Car было бы хорошим именем таблицы, а CarFender — нет. Не может быть большой путаницы в отношении того, что может содержать таблица Car. CarFender может содержать информацию об автомобилях, или крыльях, или, может быть, о ком-то, кто заканчивает карфы (какими бы они ни были), или, возможно, обо всех трех. Просто глядя на последнюю, мне хочется разделить ее на отдельные таблицы с какой-то связью друг с другом. Если вы действительно застряли на хорошем, уникальном имени, попробуйте добавить несколько возможных имен в тезаурус и посмотреть, какие существуют синонимы. Вы можете быть приятно удивлены тем, что найдете. Существует одно существенное исключение из правила Одно существительное, описанное в разделе Ассоциативные таблицы ниже.

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

Устранение избыточности Если вы действительно работаете над применением правила Одного существительного, это просто вопрос времени, когда возникнет ситуация, когда одно и то же простое существительное описывает как минимум два совершенно разных слова. идеи. Point — хороший пример; это может быть физическое местонахождение на поверхности земли, или одиночная пуля на слайде презентации, или, может быть, острый конец карандаша. В некоторых случаях наложение может быть устранено с помощью схем (подробнее об этом в следующем посте), но на данный момент это единственная ситуация, когда единственное уточняющее прилагательное, стоящее перед существительным, уместно. GeographicPoint и TalkingPoint создадут необходимое различие между двумя идеями. Однако избегайте превентивного использования этого метода; «Мне лучше назвать таблицу GeographicPoint на случай, если в будущем появится точка другого типа.». чем пытаться представить все возможные будущие ситуации — вы просто сведете себя с ума, а тем временем ухудшите простоту и ясность имен ваших таблиц.

Ассоциативные таблицы. Эти таблицы разрешают отношения "многие ко многим", существующие в вашей структуре данных. Недавно я начал нарушать — эээ, развивать — первое правило Одно существительное, потому что пришел к выводу, что ассоциативные таблицы действительно коренным образом отличаются от других таблиц. Они описывают отношения, а не вещь. Поэтому в их случае я бы сказал — ужасы! — переходный глагол. Например, таблицы Presentation и Document связаны в том смысле, что данная презентация может состоять из многих документов, и данный документ может использоваться во многих презентациях. Это классическая связь многие ко многим. Ассоциативной таблицей, разрешающей отношение, может быть переходный глагол Contain. Подумайте Документ-Содержит-Презентация и Презентация-Содержит-Документ. Я неоднозначно отношусь к употреблению единственного числа в данном случае. Мне нравится абсолютный характер правила Единственного числа, но использование множественного числа действительно улучшает его чтение. Так что давайте использовать единственное число, в целях согласованности, по крайней мере, сейчас.

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

другие мысли

С начала 2005 года я либо руководил, либо участвовал в проектах по разработке программного обеспечения с использованием методологии Agile. В первую очередь из-за нехватки времени были созданы только те таблицы, которые действительно были необходимы во время текущей итерации. Даже если вы не следуете Agile, настоятельно рекомендуется создавать только те таблицы, которые соответствуют конкретным требованиям, которые вы четко понимаете. Немного позаимствовать и порезать фон Мольтке; Дизайн никогда не переживет первого контакта с пользователем.. То, что вы изучаете на каждой итерации разработки, вполне может исключить таблицы, которые, как вы были уверены, вам были нужны. В то же время вам потребуется создавать таблицы, о которых вы раньше и не подозревали. Пусть конкретные, текущие, ориентированные на функции требования вытесняют структуру — всегда.

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

Вы можете заключить, что соблюдение всех приведенных выше правил очень узко определяет возможности; два человека, разделенные временем и пространством, но рассматривающие один и тот же предмет, вполне могут придумать очень похожие или даже идентичные имена таблиц. Например, если одним из описываемых объектов является человек, сколько именно в нем разных слов? Устранение ненормативной лексики, уничижительных и неполиткорректных высказываний, которых на самом деле не так много. Так почему же все продолжают создавать одну и ту же таблицу Person с нуля? Хороший вопрос, на который я пока не могу придумать хорошего ответа — возможно, тема будущего поста?

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

Далее следует Часть II: Столбцы, в которой рассматриваются стандарты именования столбцов базы данных. Спасибо за чтение, и, пожалуйста, дайте мне знать, что вы думаете!

Эта серия статей была первоначально опубликована Теренсом С. Гэнноном в 2007 году в первоначальной версииблога Intellog. Поскольку мы приступаем к разработке новой базы данных с чистым листом для нового клиента, мы решили вернуться к этим исходным документам, чтобы проверить, выдержали ли они испытание временем. По большей части они есть, но мы также воспользовались возможностью немного обновить их для более современной эпохи. Мы хотели бы услышать ваши отзывы.