Я начинаю новый проект и хотел бы получить имена таблиц и столбцов с самого начала. Например, я всегда использовал множественное число в именах таблиц, но недавно выученное единственное число является правильным.
Итак, если я получил таблицу «пользователь», а затем я получил продукты, которые будут иметь только пользователи, должна ли таблица называться «user_product» или просто «продукт»? Это отношения один ко многим.
И далее, если бы у меня было (по какой-то причине) несколько описаний продуктов для каждого продукта, было бы это «user_product_description» или «product_description» или просто «description»? Конечно, с правильными установленными внешними ключами. Назвать его только описанием было бы проблематично, так как у меня также может быть описание пользователя или описание учетной записи или что-то еще ..
Как насчет того, как бы я хотел получить чистую реляционную таблицу (от многих ко многим) только с двумя столбцами? "user_stuff" или что-то вроде "rel_user_stuff"? И если первый, что бы отличить это, например, "user_product"?
Любая помощь очень ценится, и, если вы, ребята, порекомендуете какой-нибудь стандарт соглашения об именах, не стесняйтесь ссылаться.
Спасибо
primarily opinion-based
является явно ложным.Ответы:
Таблица • Имя
Да. Остерегайтесь язычников. Множественное число в именах таблиц является верным признаком того, кто не читал ни одного из стандартных материалов и не знает теории баз данных.
Некоторые из замечательных вещей о стандартах:
Стандартное имя таблицы относится к каждой строке таблицы, которая используется во всех словах, а не к общему содержанию таблицы (мы знаем, что
Customer
таблица содержит всех клиентов).Отношения, глагольная фраза
В подлинных реляционных базах данных, которые были смоделированы (в отличие от систем хранения записей до 1970-х годов [отличающихся тем,
Record IDs
что для удобства реализованы в контейнере базы данных SQL):Diagram_A
Конечно, связь реализована в SQL как
CONSTRAINT FOREIGN KEY
в дочерней таблице (подробнее позже). Вот фраза глагола (в модели), предикат, который она представляет (для чтения из модели), и имя ограничения FK :Таблица • Язык
Однако при описании таблицы, особенно на техническом языке, таком как Предикаты, или другой документации, используйте единственное и множественное число, как они, естественно, на английском языке. Помня, что таблица названа для единственной строки (отношения), а язык ссылается на каждую производную строку (производное отношение):
не
(Это не вопрос соглашения об именах; это вопрос разработки базы данных.) Не имеет значения,
user::product
равен ли 1 :: n. Важно то, является лиproduct
отдельный объект и является ли он независимой таблицей , т.е. оно может существовать само по себе. Поэтомуproduct
нетuser_product
.И если
product
существует только в контекстеuser
, т.е. следовательно, это зависимая таблицаuser_product
.Diagram_B
Это правильно. Любой
user_product_description
xorproduct_description
будет правильным, основываясь на вышеизложенном. Это не для того, чтобы отличить его от другихxxxx_descriptions
, но для того, чтобы дать имени понять, где оно принадлежит, префиксом является родительская таблица.Надеемся, что все таблицы в реляционной базе данных являются чисто реляционными нормализованными таблицами. Нет необходимости указывать это в имени (иначе будут все таблицы
rel_something
).Если он содержит только PK двух родителей (который разрешает логическое отношение n :: n, которое не существует как сущность на логическом уровне, в физическую таблицу), то это ассоциативная таблица . Да, обычно имя представляет собой комбинацию имен двух родительских таблиц.
Обратите внимание, что в таких случаях фраза глагола применяется к родительскому слову и читается как его, игнорируя дочернюю таблицу, потому что ее единственная цель в жизни - это связать двух родителей.
Diagram_C
Если это не ассоциативная таблица (т. Е. В дополнение к двум PK, она содержит данные), присвойте ей соответствующее имя, и к ней будут применяться глагольные фразы, а не родительский элемент в конце отношения.
Diagram_D
Если вы получите две
user_product
таблицы, то это очень громкий сигнал о том, что вы не нормализовали данные. Итак, вернитесь на несколько шагов назад и сделайте это, и назовите таблицы точно и последовательно. Имена затем разрешат сами.Соглашение об именовании
То, что вы делаете, очень важно, и это повлияет на простоту использования и понимания на каждом уровне. Так что с самого начала полезно получить как можно больше понимания. Актуальность большей части этого не будет ясна, пока вы не начнете кодировать в SQL.
Дело является первым пунктом для решения. Все заглавные буквы недопустимы. Смешанный регистр - это нормально, особенно если таблицы доступны непосредственно пользователям. См. Мои модели данных. Обратите внимание, что когда ищущий использует некий слабо выраженный NonSQL, который имеет только строчные буквы, я даю это, и в этом случае я включаю подчеркивание (согласно вашим примерам).
Поддерживайте фокус данных , а не приложение или использование. Ведь после 2011 года у нас была открытая архитектура с 1984 года, и предполагается, что базы данных не зависят от приложений, которые их используют.
Таким образом, по мере того, как они растут и их использует не одно приложение, наименование останется значимым и не нуждается в исправлении. (Базы данных, которые полностью встроены в одно приложение, не являются базами данных.) Назовите элементы данных только как данные.
Будьте очень внимательны и называйте таблицы и столбцы очень точно . Не используйте,
UpdatedDate
если этоDATETIME
тип данных, используйтеUpdatedDtm
. Не используйте,_description
если он содержит дозировку.Важно быть последовательным по всей базе данных. Не используйте
NumProduct
в одном месте для указания количества Товаров и /ItemNo
илиItemNum
в другом месте для указания количества Товаров. ИспользуйтеNumSomething
для номеров иSomethingNo
илиSomethingId
для идентификаторов последовательно.Не добавляйте префикс имени столбца к имени таблицы или короткому коду, например
user_first_name
. SQL уже предоставляет имя таблицы в качестве квалификатора:Исключения:
Первое исключение касается PK, они нуждаются в специальной обработке, потому что вы постоянно кодируете их в соединениях и хотите, чтобы ключи выделялись из столбцов данных. Всегда используйте
user_id
, никогдаid
.user_id
это столбец , который идентифицирует пользователя, а неid
вuser
таблице.user_product
таблица будет иметьuser_id
в качестве компонента своего PK(user_id, product_no)
.id
множеством таблиц легко запутаться в кодировании SQL. Во-вторых, кто-нибудь другой, первоначальный кодер понятия не имеет, что он пытается сделать. Оба из них легко предотвратить, если ключевые столбцы обрабатываются как указано выше.Второе исключение - это когда более одного FK ссылаются на одну и ту же таблицу родительской таблицы, передаваемой в дочернем элементе. Согласно реляционной модели , используйте имена ролей, чтобы дифференцировать значение или использование, например.
AssemblyCode
иComponentCode
на двоихPartCodes
. И в этом случае не используйте недифференцированныйPartCode
для одного из них. Будь точным.Diagram_E
Префикс
Если у вас более 100 таблиц, добавьте к именам таблиц предметную область:
REF_
Справочные таблицыOE_
для кластера ввода заказов и т. д.Только на физическом уровне, а не на логическом (это загромождает модель).
Суффикс
Никогда не используйте суффиксы для таблиц и всегда используйте суффиксы для всего остального. Это означает, что при логическом, нормальном использовании базы данных подчеркивания отсутствуют; но на административной стороне подчеркивания используются в качестве разделителя:
_V
Просмотр (TableName
конечно, с основным впереди)_fk
внешнего ключа (имя ограничения, а не имя столбца) Операция сегмента_cac
кэша (сохраненный процесс или функция) Функция (нетранзакционная) и т. Д._seg
_tr
_fn
Формат представляет собой имя таблицы или FK, подчеркивание и имя действия, подчеркивание и, наконец, суффикс.
Это действительно важно, потому что когда сервер выдает сообщение об ошибке:
____
blah blah blah error on object_name
Вы точно знаете, какой объект был нарушен, и что он пытался сделать:
____
blah blah blah error on Customer_Add_tr
Внешние ключи (ограничение, а не столбец). Лучшее наименование для FK - использовать фразу глагола (минус «каждый» и количество элементов).
Customer_Initiates_SalesOrder_fk
Part_Comprises_Component_fk
Part_IsConsumedIn_Assembly_fk
Используйте
Parent_Child_fk
последовательность, а неChild_Parent_fk
потому, что (а) она отображается в правильном порядке сортировки, когда вы ищете их, и (б) мы всегда знаем вовлеченного ребенка, о чем мы предполагаем, какой родитель. Сообщение об ошибке тогда восхитительно:____
Foreign key violation on Vendor_Offers_PartVendor_fk
.Это хорошо работает для людей, которые пытаются моделировать свои данные, где были определены глагольные фразы. В остальном используют системы регистрации документов и т
Parent_Child_fk
. Д.Индексы являются особыми, поэтому они имеют собственное соглашение об именах, состоящее по порядку из каждой позиции символа от 1 до 3:
U
Уникальный, или_
для неуникальногоC
Clustered, или_
для некластеризованного_
разделителяДля остатка:
Если ключ один столбец или очень мало столбцов:
____
ColumnNames
Если ключ больше, чем несколько столбцов:
____
PK
Первичный ключ (согласно модели)____
AK[*n*]
Альтернативный ключ (термин IDEF1X)Обратите внимание, что имя таблицы не обязательно указывать в имени индекса, поскольку оно всегда отображается как
table_name.index_name.
Поэтому, когда
Customer.UC_CustomerId
илиProduct.U__AK
появляется в сообщении об ошибке, он говорит вам что-то значимое. Когда вы смотрите на индексы на столе, вы можете легко их дифференцировать.Найдите кого-то квалифицированного и профессионального и следуйте за ним. Посмотрите на их проекты и внимательно изучите соглашения об именах, которые они используют. Задайте им конкретные вопросы о том, что вы не понимаете. И наоборот, бежать чертовски от любого, кто демонстрирует мало внимания к соглашениям или стандартам именования. Вот несколько, чтобы вы начали:
Ввод и инвентаризация заказа по стандартным адресам
Простая межведомственная система бюллетеней для PHP / MyNonSQL
Сенсорный мониторинг с полной временной возможностью
Ответы на вопросы
На это нельзя разумно ответить в поле для комментариев.
В вашем комментарии есть две основные проблемы:
Вы объявляете свой пример «самым тривиальным», однако это не что иное, как. С таким противоречием я не уверен, если вы серьезны, если технически способны.
Это «тривиальное» предположение имеет несколько грубых ошибок нормализации (DB Design).
Пока вы не исправите их, они неестественны и ненормальны, и они не имеют никакого смысла. Вы можете также назвать их abnormal_1, abnormal_2 и т. Д.
У вас есть «поставщики», которые ничего не поставляют; циркулярные ссылки (незаконные и ненужные); клиенты, покупающие продукты без какого-либо коммерческого инструмента (такого как Invoice или SalesOrder) в качестве основы для покупки (или клиенты "владеют" продуктами?); неразрешенные отношения «многие ко многим»; и т.п.
Как только это нормализуется, и необходимые таблицы определены, их имена станут очевидными. Естественно.
В любом случае я постараюсь обслуживать ваш запрос. Что означает, что мне придется добавить к этому некоторый смысл, не зная, что вы имели в виду, поэтому, пожалуйста, потерпите меня. Грубых ошибок слишком много, чтобы их перечислить, и, учитывая запасную спецификацию, я не уверен, что исправил их все.
Я предполагаю, что если продукт состоит из компонентов, то продукт представляет собой сборку, а компоненты используются более чем в одной сборке.
Кроме того, поскольку «Поставщик продает компоненты с нуля ко многим», то, что они не продают продукты или сборки, они продают только компоненты.
Спекуляция против нормализованной модели
Если вы не в курсе, разница между квадратными углами (независимыми) и закругленными углами (зависимыми) значительна, см. Ссылку на обозначение IDEF1X. Аналогично сплошные линии (Идентификация) против пунктирных линий (Неидентификация).
Теперь, когда я решил таблицы, я не понимаю твою проблему. Возможно, вы можете опубликовать конкретный вопрос.
Предполагая, что нет ошибок нормализации,
User likes Product
это предикат, а не таблица. Не путайте их. Обратитесь к моему ответу, где он относится к предметам, глаголам и предикатам, и к моему ответу Ларри непосредственно выше.Каждая таблица содержит набор фактов (каждая строка представляет собой факт). Предикаты (или предложения) не являются фактами, они могут быть или не быть правдой.
Реляционная модель основана на исчисления предикатов первого порядка (более известный как первый Order Logic). Предикат - это предложение с одним предложением на простом и точном английском языке, которое оценивается как истинное или ложное.
Кроме того, каждая таблица представляет или является реализацией множества предикатов, а не одного.
Запрос - это проверка Предиката (или нескольких Предикатов, связанных вместе), который приводит к истине (Факт существует) или ложь (Факт не существует).
Таким образом, таблицы должны быть названы, как подробно описано в моем Ответе (соглашения об именах), для строки, Факта и Предикатов должны быть задокументированы (во всех случаях, это часть документации базы данных), но как отдельный список Предикатов. ,
Это не предположение, что они не важны. Они очень важны, но я не буду писать это здесь.
Тогда быстро. Поскольку реляционная модель основана на FOPC, можно сказать, что вся база данных представляет собой набор объявлений FOPC, набор предикатов. Но (а) существует много типов предикатов, и (б) таблица не представляет один предикат (это физическая реализация многих предикатов и разных типов предикатов).
Поэтому называть таблицу «Предикат, который она« представляет »- абсурдная концепция.
«Теоретики» знают только несколько Предикатов, они не понимают, что, поскольку РМ была основана на ВОЛП, вся база данных представляет собой набор Предикатов и разных типов.
И конечно, они выбирают абсурдных из немногих, которых они знают:
EXISTING_PERSON
:;PERSON_IS_CALLED
, Если бы не было так грустно, это было бы весело.Также обратите внимание, что стандартное или атомарное имя таблицы (с именем строки) прекрасно работает для всех слов (включая все предикаты, прикрепленные к таблице). И наоборот, идиотское имя «таблица представляет предикат» не может. Что хорошо для «теоретиков», которые очень мало понимают в предикатах, но отстают в противном случае.
Предикаты, которые имеют отношение к модели данных, выражаются в модели, они имеют два порядка.
Унарный предикат
Первый набор является схематическим , а не текстовым: сама запись . К ним относятся различные экзистенциальные; Ограничение-ориентированный; и дескриптор (атрибуты) предикаты.
Двоичный предикат
Второй набор - это те, которые формируют отношения между фактами. Это линия отношения. Глагольная фраза (подробно изложенная выше) определяет Предикат, предложение , которое было реализовано (которое можно проверить с помощью запроса). Никто не может быть более явным, чем это.
Вот модель данных , в которой я перечислил предикаты. Я выбрал этот пример, потому что он показывает экзистенциальные и т. Д. Предикаты, а также отношения, единственные предикаты, не перечисленные - это дескрипторы. Здесь, из-за уровня обучения искателя, я отношусь к нему как к пользователю.
Поэтому событие более чем одной дочерней таблицы между двумя родительскими таблицами не является проблемой, просто назовите их в качестве Existential Fact для их содержимого и нормализуйте имена.
Правила, которые я дал для глагольных фраз для имен отношений для ассоциативных таблиц, вступают в действие здесь. Вот обсуждение Предиката против Таблицы, вкратце охватывающее все упомянутые пункты.
Чтобы получить хорошее краткое описание правильного использования Предикатов и того, как их использовать (что совершенно не соответствует контексту ответов на комментарии здесь), перейдите к этому ответу и прокрутите вниз до раздела Предикат .
Хорошо, это то, что мы называем таблицей Key или NextKey. Назовите это так. Если у вас есть SubjectAreas, используйте COM_NextKey, чтобы указать, что он является общим для всей базы данных.
Кстати, это очень плохой метод генерации ключей. Не масштабируется вообще, но с производительностью Oracle это, вероятно, "просто отлично". Кроме того, это означает, что ваша база данных полна суррогатов, а не реляционных в этих областях. Что означает крайне низкую производительность и отсутствие целостности.
источник
Singular vs. Plural: выберите один и придерживайтесь его.
Столбцы не должны быть префиксами / суффиксами / инфиксами или в любом случае исправлены со ссылками на тот факт, что это столбец. То же самое касается таблиц. Не называйте таблицы EMPLOYEE_T или TBL_EMPLOYEES, потому что, когда они заменяются на представление, все становится действительно запутанным.
Не вставляйте информацию о типе в имена, такие как «vc_firstname» для varchar или «flavour_enum». Также не встраивайте ограничения в имена столбцов, такие как "Department_fk" или "employee_pk".
На самом деле, единственная хорошая вещь * исправления я могу думать, что вы можете использовать зарезервированные слова , как
where_t
,tbl_order
,user_vw
. Конечно, в этих примерах использование множественного числа решило бы проблему :)Не называйте все ключи "ID". Ключи, относящиеся к одной и той же вещи, должны иметь одинаковые имена во всех таблицах. Столбец идентификатора пользователя может называться USER_ID в пользовательской таблице и во всех таблицах, ссылающихся на пользователя. Единственный раз, когда он переименовывается, это когда разные пользователи играют разные роли, такие как Message (sender_user_id, receive_user_id). Это действительно помогает при работе с большими запросами.
Что касается CaSe:
В общем случае лучше называть «таблицы сопоставления», чтобы они соответствовали описываемым отношениям, а не именам ссылочных таблиц. Пользователь может иметь любое количество отношения к продукции:
user_likes_product
,user_bought_product
,user_wants_to_buy_product
.источник
{table_name}_id
а не простоid
, поскольку на столбец всегда будет ссылаться только имя таблицы с префиксом в качестве спецификатора, напримерtable_name.id
. Для контекста, я работаю в экосистеме, где синтаксис соединения формыtable_a JOIN table_b ON table_b_id_column
не поддерживается; Я должен сделатьtable_a JOIN table_b ON table_b.id_column = table_a.table_b_id_column
.В «единственном и множественном числе» нет «правильного» - это в основном дело вкуса.
Частично это зависит от вашего внимания. Если вы рассматриваете таблицу как единое целое, она содержит «множественное число» (потому что она содержит много строк - поэтому подходит имя во множественном числе). Если вы считаете, что имя таблицы идентифицирует строку в таблице, вы предпочитаете «единственное число». Это означает, что ваш SQL будет рассматриваться как работающий на одной строке таблицы. Это нормально, хотя обычно это упрощение; SQL работает на множествах (более или менее). Тем не менее, мы можем пойти с единственного числа для ответов на этот вопрос.
Поскольку вам, вероятно, понадобится таблица «пользователь», другой «продукт» и третья для связи пользователей с продуктами, вам понадобится таблица «user_product».
Поскольку описание относится к продукту, вы должны использовать «product_description». Если каждый пользователь не называет каждый продукт для себя ...
Таблица 'user_product' является (или может быть) примером таблицы с идентификатором продукта и идентификатором пользователя и не более того. Вы называете таблицы с двумя атрибутами одним и тем же общим способом: 'user_stuff'. Декоративные префиксы типа 'rel_' не очень помогают. Например, вы увидите, как некоторые люди используют 't_' перед каждым именем таблицы. Это не большая помощь.
источник
Множественное число неплохо, если его использовать последовательно, но мое предпочтение - единственное число.
Я бы обошелся без подчеркиваний, если вы не хотите описать отношения «многие ко многим»; и использовать начальный капитал, потому что он помогает различать вещи в ОРМ.
Но есть много соглашений об именах, поэтому, если вы хотите использовать подчеркивание, это нормально, если это делается последовательно.
Так:
Если только один пользователь может иметь любой продукт, то
Но если продукт доступен пользователям:
Если вы сохраните свои подчеркивания для отношений «многие ко многим», вы можете сделать что-то вроде:
чтобы сформировать M-to-M между UserProduct и Stuff - не уверен из вопроса точный характер многих ко многим требуется.
источник
Нет более правильного использования формы единственного числа, чем формы множественного числа, где вы слышали это? Я бы скорее сказал, что форма множественного числа чаще используется для именования таблиц базы данных ... и, на мой взгляд, также более логична. Таблица чаще всего содержит более одной строки;) В концептуальной модели, хотя названия сущностей часто бывают в единственном числе.
По поводу вашего вопроса, если «Product» и «ProductDescription» являются концепциями с идентичностью (то есть сущностями) в вашей модели, я бы просто назвал таблицы «Products» и «ProductDescription». Для таблиц, которые используются для реализации отношения «многие ко многим», я чаще всего использую соглашение об именах «SideA2SideB», например «Student2Course».
источник