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

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

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

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

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

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

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

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

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

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%'

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

Существуют исключения, если их использовать разумно (согласно ответу Патрика Карчера на вашу ссылку) для общих имен столбцов (обычно только 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

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

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

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

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

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

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

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

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

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

Попробуйте написать словарь данных (или «реестр»). Под этим я подразумеваю документ, содержащий все элементы данных в вашей модели: имя, описание и т. Д. Он должен быть независимым от реализации модели, например, не должен упоминать имена таблиц. Как бы вы избавились от неоднозначности имен, таких как «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, в том числе доказательства того, что в именах столбцов используются подчеркивания в качестве разделителей.

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

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