Именование таблиц базы данных; соглашения name_verb_name для таблиц пересечения многие-ко-многим

Question

Я перечитал SO на предмет других вопросов по этому вопросу, и я знаю, что соглашения об именах - это часто субъективная тема, однако я чувствую, что это менее общий вопрос ( и меньше вопросов о )чем PascalCase против under_scores.

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

В любом случае, если бы я представила возможность "Голосовать" за товары и за "Любимые" товары,схема User_Product больше не остается однозначной.

Является ли это необычной () и поэтому я бы предположил менее приемлемую ) схему именования для использования Name_Verb_Name следующим образом:

• User_Purchase_Product
• User_Vote_Product
• User_Favorite_Product
• и так далее ...

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

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

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

Answer 1

Соглашения об именах не являются стандартными !

Наука не субъективна !

Существуют стандарты, и есть причины для стандартов,Все эти вопросы были решены и стандартизированы более 30 лет назад.Прочитайте мой IDEF1X Введение , IDFE1X - это стандарт моделирования реляционных баз данных, другого нет.

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

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

Обычно это означает составные ключи.

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

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

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

• Учитывая ваши таблицы User и Product

• UserProduct не является полным именем по рассуждению выше

• допустим, они были Независимыми

• . Любимая таблица будет Зависимой на обоих
• , ее ПК будет UserPK плюсProductPK
• Фраза глагола Each User Favours zero-to-many Products

• Я бы назвал это UserFavoured или UserFavourite

• User_Favourite_Product перегружен, третья часть избыточна

• Аналогично, Each User Elects zero-to-many Products (или Supports или Elevates)

• его PK будетUserPK плюс ProductPK (если вы не любите дубликаты)
• Поэтому UserElected или UserElection

Выше приведены ассоциативные таблицы (то, что вы называете «ссылкой»)) или несколько столбцов, добавленных к тому же.Покупка существенно отличается (не «ссылка»).Для покупки должны быть записаны различные детали, которых нет ни в User, ни в Product.

• Я бы назвал это Purchase
• UserPurchase избыточнои глупо
• UserPurchaseProduct это глупость в квадрате

---

(я поддерживал пределы вашего вопроса. На самом деле, не было бы таблицы покупок, там было быSalesOrder, который составляет основу Покупки, коммерческое мероприятие, и SalesOrderItem, в котором подробно указывается Products.

Answer 2

Вы должны выбрать соглашение и быть настолько последовательными, насколько это возможно, как указал Одед.

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

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

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

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

Что касается noun_verb_noun, я бы сам не выбрал соглашение об именах, в котором подчеркивалась бы механическая согласованность, независимо от того, как это влияет на понятность компонентов системы. Однако, как всегда, отличительная черта стандартов в том, что есть из чего выбирать!

Answer 3

Не существует «стандарта», и это полностью субъективно.

Как обычно с этими вещами - выберите один и придерживайтесь его в любом проекте.