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

25

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

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

Person_First_Name
или, может быть, даже
Person_Person_First_Name (не спрашивайте меня, почему вы видите человека 2x)

Почему считается плохой практикой предварительно фиксировать имена столбцов? Подчеркивания также считаются злом в SQL?


Примечание: у меня есть Pro SQL Server 2008 - разработка и реализация базы данных отношений. Ссылки на эту книгу приветствуются.

P.Brian.Mackey
источник
2
Похоже, кто создал эти правила, не знал о функции псевдонимов.
ba__friend
@ Даниэль Приден - я использовал плохую формулировку. Вопрос обновлен.
P.Brian.Mackey
Подобный вид поста здесь stackoverflow.com/questions/465136/…
@ba__friend - Можете ли вы дать мне некоторые детали этого комментария?
P.Brian.Mackey
1
Основное слово, которое вы использовали - «Стандарт». Если вы измените стандартную практику, у вас будет несоответствие. Честно ли вы чувствуете, что любое изменение по сравнению с этой стандартной практикой стоит того противоречия? Действительно ли статус-кво хуже этого?

Ответы:

44

Подчеркивание не зло, просто сложнее набрать. Что плохо, так это изменение стандартов среднего уровня без исправления всех существующих объектов. Теперь у вас есть personId, Person_id и т. Д., И вы не можете вспомнить, какая таблица использует подчеркивания или нет. Согласованность имен (даже если вам лично не нравятся имена) помогает упростить кодирование.

Лично я считаю, что единственное место, где мне нужно использовать имя таблицы в столбце, - это столбец идентификатора (использование только идентификатора является антипаттерном в дизайне базы данных, так как любой, кто делал обширные запросы на создание отчетов, может сказать вам. Это очень весело переименовать 12 столбцов в вашем запросе каждый раз, когда вы пишете отчет.) Это также облегчает немедленное знакомство с FK в других таблицах, поскольку они имеют одинаковые имена.

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

HLGEM
источник
4
Да, но к базе данных, в которой отсутствует непротиворечивый стандарт именования, запрашивать гораздо сложнее, чем в базе данных, которая постоянно применяется.
HLGEM
2
Я частично согласен. Если база данных огромна, то придерживайтесь стандарта. Но я трачу свое время на чтение кода больше, чем на его написание, и префиксы имен таблиц кажутся более шумными, чтобы их просеивать. Если бы это был я и знал, что я мог бы сделать рефакторинг в течение нескольких дней или недели, я бы уверен. Но большую часть времени у вас нет такой роскоши, и вы должны продолжать кодировать производство, производство, производство.
программист
3
@ Джейсон, ты можешь сломать больше, чем ты думаешь, делая это. К базам данных часто обращаются многие вещи, о которых не знает программист приложения. Такие вещи, как импорт данных из клиентов или других БД и экспорт в клиенты и / или хранилища данных, другие приложения, отчеты и т. Д. Вы можете привыкнуть к считыванию любого стандарта за считанные часы и рефакторингу от утвержденного стандарта компании без согласия на переход на новый стандарт привел бы вас к увольнению в большинстве мест. Честно говоря, если база данных находится в зачаточном состоянии, лучше использовать существующий стандарт, нравится вам это или нет.
HLGEM
7
@ Джейсон, я работаю в базе данных, мы широко известны тем, что не имеем никакого смысла в приключениях!
HLGEM
2
Полностью согласен с TableName. Я являюсь антипаттерном. Работали внутри и без этого шаблона достаточно долго, чтобы я мог с уверенностью сказать, что ошибки / путаница происходят с TableName.Id, которые не происходят с TableName.TableNameId
AaronLS
16

Аргументом для префикса имени столбца будет предотвращение столкновения имен при объединении нескольких таблиц И когда создатель запроса не использует псевдонимы.

SELECT person.name, company.name FROM person JOIN company ON ...

SELECT * FROM person JOIN company ON ...

Оба запроса будут иметь два столбца «name» ( name_1, name_2 ) без « указания », к какой сущности он принадлежит. И вы никогда не можете быть уверены в сгенерированных именах столбцов (это будет name_2 или name_3 или ...). Если вы используете префикс имени таблицы, имена столбцов будут person_name , company_name, чтобы вы знали каждое имя, к какому объекту он принадлежит, плюс вы знаете, что имена столбцов останутся постоянными (если вы получаете их в Java с использованием JDBC, например, ).

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

Что касается подчеркивания в именах таблиц и столбцов, я широко его использую, потому что я использую только строчные буквы в именах и подчеркивания в качестве разделителя. Использование только строчных букв помогает отличить идентификаторы от ключевых слов SQL (которые я печатаю прописными буквами):

SELECT person_name, COUNT(bought_product) FROM bought_products WHERE person_name LIKE 'A%'
Николае Албу
источник
6
Мне бы очень понравилось, если бы все столбцы с одинаковой информацией в разных таблицах имели одинаковое имя и чтобы при использовании более 1 таблицы псевдонимы применялись в качестве обязательного стандарта. Я устал от того, что вспоминаю, к каким таблицам относятся карты: Papd, Patient, Pat_id, ID_Pat или Ptatient_id.
Питер Б
1
Я никогда не пишу производственный запрос без наложения псевдонимов на все столбцы. Это делает обслуживание намного проще. Конечно, я пишу сложные запросы типа отчетов / экспорта с 10-20 объединениями и 30-50 столбцами, и через шесть месяцев трудно вспомнить, из какой таблицы пришел этот столбец.
HLGEM
8

Добавление таких префиксов к именам столбцов усложнит развитие таблицы. В качестве примера: если в конце концов вы поймете, что хотите / должны изменить имя таблицы, вам придется изменить всю структуру таблицы (т. Е. Не только имя таблицы, но и имя всех ее столбцов). Это также затруднит обновление индексов таблицы и кода клиентов, запрашивающих ее.

Sergio
источник
4

Существуют исключения, если их использовать разумно (согласно ответу Патрика Карчера на вашу ссылку) для общих имен столбцов (обычно только ID, иногда Name), которые слишком часто бывают неоднозначными .

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

Сравните это: что легче для глаз?

SELECT P.name, P.Salary FROM dbo.Person P

SELECT Person.Name, Person.Salary FROM dbo.Person Person

SELECT dbo.Person.name, dbo.Person.Salary FROM dbo.Person

SELECT Person.Person_name, Person.Person_Salary FROM dbo.Person Person
ГБН
источник
3
Определенно первый ... :)
ErikE
3
Как насчет SELECT name, salary FROM dbo.Person? : P
cHao
1
@cHao: попробуйте создать представление с SCHEMABINDING на это ...
ГБН
@gbn: у меня отлично работает. CREATE VIEW [dbo].[vwMeritPercentage] with schemabinding AS SELECT [Performance Score] as dblMinScore, ISNULL(( SELECT TOP 1 [Performance Score] FROM dbo.Budget b WHERE b.[Performance Score] > budget.[Performance Score] ORDER BY [Performance Score] ), 100.00) as dblMaxScore, [Merit Minimum] as dblMinPercentage, [Merit Midpoint] as dblBudgetPercentage, [Merit Maximum] as dblMaxPercentage FROM dbo.Budget;
Цао
1
Соответствующая документация ( msdn.microsoft.com/en-us/library/ms187956(v=SQL.105).aspx ): «Когда вы используете SCHEMABINDING, select_statement должен включать имена из двух частей (schema.object) таблиц, представления или пользовательские функции, на которые есть ссылки. " Обратите внимание, что столбцы не требуют точечных имен (если только они не требуются для разрешения неоднозначностей в запросе) ... только таблицы, представления и функции.
Цао
3

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

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

Дэн Саймон
источник
2

В TSQL вы можете ссылаться на поля в форме TableName.FieldName, если вы хотите избежать неоднозначности, поэтому добавление имен таблиц к именам полей фактически лишает возможности чтения, делая его TableName.TableName_FieldName или аналогичным. Я думаю, использование подчеркивания или нет - больше личного выбора. Я предпочитаю CamelCase и использую _, когда хочу добавить суффикс или аналогичный, например, TableName_Temp, но это только я.

Бен Робинсон
источник
2

Однажды я работал над системой, в которой мы решили использовать короткие коды для добавления префиксов к столбцам. В полях PK в качестве префикса использовалось «полное имя таблицы», а во всех других столбцах в качестве префикса использовались 2-4 символа. Каждый столбец также использовал домен данных в качестве суффикса. Если все сделано последовательно, это может быть очень красиво и чисто. Это нонсенс, что стандарт именования того или иного типа подразумевает небрежное кодирование. Наличие единого стандарта - вот что важно. Я видел несколько баз данных, которые несовместимы, потому что нет четкого стандарта, и что больше всего на свете указывает мне, что могут быть проблемы в структурах данных. Если разработчик базы данных не может даже последовательно называть объекты и их дочерние элементы,

Том
источник
1

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

Что касается использования подчеркивания в имени таблицы, это религиозный аргумент. В конце концов, если увеличивает видимость и делает вещи проще пойти на это. У меня вообще никогда не было бы пробелов или таблиц в имени столбца или таблицы. Однако я мог бы сделать исключение для таблиц или представлений, которые использовались только пакетом отчетов или экспортировались в файл CSV.

Джастин Даринг
источник
1

Многие базы данных имеют строгие ограничения на количество символов в имени столбца (например, Oracle).

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

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

Бритт Уэскотт
источник
0

Попробуйте написать словарь данных (или «реестр»). Под этим я подразумеваю документ, содержащий все элементы данных в вашей модели: имя, описание и т. Д. Он должен быть независимым от реализации модели, например, не должен упоминать имена таблиц. Как бы вы избавились от неоднозначности имен, таких как «ID», «Type» и «Code»?

Один из подходов состоит в том, чтобы следовать рекомендациям международного стандарта ISO / IEC 11179 - в конце концов, зачем изобретать велосипед? Базовая структура:

[Object] [Qualifier] Property RepresentationTerm

с разделителями между элементами: SQL плохо сочетается с пробелами в именах столбцов, а подчеркивание работает хорошо визуально.

У меня есть ощущение, что кто-то в вашей организации пытался следовать этим рекомендациям, когда он придумал имена элементов, такие как Person_Person_First_Name.

Пример, который мне нравится показывать, это словарь данных Службы здравоохранения Великобритании (NHS) .

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

При реализации, например, в SQL, некоторые люди предпочитают пропускать подэлементы Object, Qualifier и Property, когда имя таблицы предоставляет контекст, например, person_first_nameстановится first_nameв Personтаблице и т. Д. Однако практическое правило, согласно которому элемент данных не должен просто менять свое имя из-за его местоположения в физической модели кажется хорошим. Любой, кто считает, что не следует следовать этому правилу, должен задокументировать все варианты названий, которые они использовали :)

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

onedaywhen
источник
0

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

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

Билл Липер
источник