Почему префикс имен столбцов с именем таблицы является соглашением?

Question

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

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

Answer 1

Не думаю, что на самом деле существует соглашение о добавлении имен столбцов к имени таблицы.

Как отмечает Филипп Грондиер, «правильный» подход к моделированию данных заключается в том, чтобы сначала создать словарь имен элементов данных. В соответствии с требованиями международного стандарта ISO 11179 :

[Object] [Qualifier] Property RepresentationTerm

в итоге вы получите полностью квалифицированные элементы данных. Здесь элементы-квалификаторы Object, Qualifier и иногда Property представляют собой комбинацию того, что вы считаете «префиксом».

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

Другими словами, в соглашении, которое вы спрашиваете, дело не в том, что имя таблицы было добавлено к имени столбца, а в том, что соответствующие термины были сохранены.

---

** является ли ваша или любая другая хорошая договоренность субъективной, и Stackoverflow не место для такого обсуждения. Тем не менее, я попутно упомяну, что сохранение квалификационных терминов имеет практические преимущества (а также теоретически обоснованные), например, учтите, что SQL NATURAL JOIN подходит для столбцов, имена которых последовательно называются по всей схеме.

Answer 2

Это правда, что такие методы "имен разработанных столбцов" широко используются для именования столбцов, где, например, Tbl_Person будет иметь столбец первичного ключа id_Person и текстовый столбец personName.

Хотя это может показатьсясначала довольно сложно писать «развитые» имена столбцов, такие как «id_Person», «personName», «personAdress» и т. д., все становится понятнее, когда вам нужно писать SELECT для нескольких таблиц, что происходит каждый раз, когда вы открываете формуили отчет.

Существует также теоретическое / историческое измерение для этого метода "расширенных имен столбцов" .Первые теории и методы реляционных баз данных (такие как MERISE) предлагали в качестве первого шага создать так называемый « словарь данных », то есть список всех данных, которые будут обрабатываться приложением \ базой данных.

Этот словарь должен быть создан еще до того, как будет предложена любая модель "сущность-связь". имена / описания данных должны быть полностью разработаны , это , чтобы избежать путаницы между "похожими" записями данных , например, такими как "companyName" и "personName".

Таким образом, соглашение о "именах столбцов в развернутом виде" отражает факт того, что на уровне данных аналогичные столбцы (такие как столбцы Company.name и Person.name) не так эквивалентны, как кажется .Хотя они оба выглядят так, будто находятся здесь, чтобы держать имя, одно из них предназначено для названия компании, а другое - для имени человека!

Это соглашение может рассматриваться как способотражать точное значение каждого столбца базы данных или точное значение каждой записи в словаре данных .

Answer 3

Это не соглашение;некоторые люди делают это, некоторые нет.Чаще всего я вижу столбец ID с префиксом имени таблицы, но нет других столбцов.Некоторые (все?) БД также допускают добавление префикса к имени таблицы в запросах, но это не требуется и не является частью фактического имени столбца.

Answer 4

Join является частью выбора, поэтому сравнение не выполняется.

Кроме того, я не думаю, что вы должны ставить перед именем таблицы префикс, за исключением первичных ключей. Мне нравится давать каждой таблице суррогатный ключ, который я предпочитаю называть после таблицы. Таким образом, таблица «Orders» получит PK «OrderId». Строка заказа будет иметь внешний ключ OrderId, указывающий на заказ. Таким образом, имена полей в таблицах одинаковы, и по имени можно определить, какие данные он представляет. Вы можете назвать поле просто «Id» во всех таблицах, но вам нужно прочитать псевдоним, чтобы увидеть, какой идентификатор вы имеете в виду. Некоторые запросы, которые я написал, содержат более 400 строк. Вы не хотите полагаться только на псевдонимы таблиц. Небольшой контекст в самом названии поля помогает.

Answer 5

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

Answer 6

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

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

• Мне нравится называть первичные ключи чем-то умным, например, id.
• Мне нравится называть префикс имен столбцов внешнего ключа именем таблицы, содержащей первичный ключ.

Это делает намного более разборчивым SQL, ИМХО. Пример:

создать таблицу foo ( id int не нулевой первичный ключ, ... )

создать панель таблицы ( id int не нулевой первичный ключ, foo_id int ненулевые ссылки на внешние ключи foo (id), ... )

выберите * от фу фу присоединиться к баре bar на bar.foo_id = foo.id

Эта схема рушится, конечно, когда вы получаете составные ключи. Но мне нравится это. YMMV.

Answer 7

В дополнение к тому, что говорили другие, это также делает вещи проще при наличии идентифицирующих отношений (также называемых ИНОСТРАННЫМИ КЛЮЧАМИ).

Идентификационные отношения "переносят" первичный ключ родителя в часть дочернего элемента.основной ключ.Префикс гарантирует, что столкновения не будет, и вам не нужно будет переименовывать перенесенные поля, даже если существует несколько уровней идентификации отношений.Например:

PARENT:
    PARENT_NAME      PK

CHILD:
    PARENT_NAME      PK, FK referencing PARENT
    CHILD_NAME       PK

GRANDCHILD:
    PARENT_NAME      PK, FK referencing CHILD
    CHILD_NAME       PK, FK referencing CHILD
    GRANDCHILD_NAME  PK

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

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