Это плохая практика кодирования, чтобы иметь таблицу SQL, которая содержит столбец с тем же именем?

Question

Пример:

CREATE TABLE ErrorNumber
(
     ErrorNumber int,
     ErrorText varchar(255),
)

Это может привести к запросам, которые выглядят так:

SELECT ErrorNumber FROM ErrorNumber WHERE ErrorNumber=10

Answer 1

Я предполагаю, что ErrorNumber в качестве столбца в таблице является первичным ключом? В этом случае вы можете назвать столбец таблицы ErrorNumberID.

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

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

Answer 2

CREATE TABLE Errors (
    Number int,
    Description varchar(255)
)

Мне кажется, что вышеприведенная схема является лучшей схемой именования, потому что:

• Имя таблицы теперь представляет, что это есть.
• В столбцах не нужно слово «Ошибка» в них из-за таблицы они в.

Answer 3

Вы можете придерживаться значения по умолчанию и назвать свои первичные ключи с идентификатором.

Answer 4

Я не думаю, что это хорошая идея иметь столбец с таким же именем в своей таблице. Это сбивает с толку, даже если это работает. Попробуйте переименовать вашу таблицу в Error или столбец в ErrorNum или даже просто Num

Answer 5

Я согласен с DWC и хотел бы сделать еще один шаг, назвав таблицу чем-то более описательным, например, что это за таблица ошибок. Если он используется для хранения ошибок, которые вы будете использовать в своем коде, это одно, а если это таблица, в которой регистрируются ошибки, - это другое. Не уверен, для чего вы его используете, так что вам действительно нужно назвать это как-то, что имеет смысл для контекста, для которого он используется. Когда я вижу таблицу с именем «Ошибки», я не уверен, является ли она таблицей журналов или таблицей поиска, используемой для поиска кодов ошибок. Если это последнее, возможно, что-то вроде ErrorCodes будет хорошим именем.

CREATE TABLE ErrorCodes
(
Id int,
Number int,
Description varchar(255)
)

Answer 6

Да, это так. Подавляющее большинство простых таблиц в простых моделях данных должны быть существительными во множественном числе. В вашем примере таблица должна называться «ошибки» с двумя столбцами: «id» и «description».

Answer 7

+ 1 для сокращенных имен dwc.

Проблема с «именем столбца должно означать домен значений» состоит в том, что он пропускает контекст. Имя столбца существует только в контексте таблицы. Это никогда не бывает двусмысленным. Его домен контролируется независимо от его имени.

Существует ли человек, который не может различить Errors.Description и Parts.Description и Problems.Description или кто предположил бы, что все столбцы с именами Description или Name взяты из одного и того же святого колодца?

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

Предположим, что номера ошибок должны были быть записаны, скажем, в таблице Actions. Actions.Number не может ссылаться на номер ошибки, поэтому мы вынуждены изобрести что-то вроде Actions.ErrorNumber. Если оно будет ErrorNumber везде, оно может иметь то же имя, где оно служит ключом!

Answer 8

Если ожидается, что таблица будет содержать более одной строки, тогда я предпочитаю использовать в качестве имени общий термин. Обратите внимание, что это не то же самое, что взять в единственном числе и добавить 's', например. Я бы предпочел «Персонал» и «Заработная плата», а не «Сотрудники» и «Сотрудники зарплаты» соответственно. И имя, такое как «Сущности», должно быть убрано и убито:)

В свете этого и учитывая колонки в вашем дизайне, я бы назвал данную таблицу "Ошибки". Теперь я знаю, что многие кодировщики предпочитают единичные термины для имен таблиц, но это просто другой стиль, а не «плохая практика кодирования».

Иногда требуются таблицы с одной строкой, например таблица «Константы», содержащая общую аппроксимацию числа «пи» для использования приложениями, использующими СУБД ... но в таблице «Константы», которую я имею в виду, есть несколько столбцов для каждой константы, поэтому в качестве имени она получает собирательный термин ,

Возможно, если ваши приложения когда-либо использовали только одну константу, то, возможно, вы могли бы получить таблицу с именем "Pi"? Ну, другой выбор стиля, который я сделал, - это использование UpperCamelCase для имен таблиц и lower_case_separated_by_underscores для имен столбцов. Поэтому я все еще могу отличить (почти) таблицу от столбца, т.е.

SELECT pi FROM Pi;

[А синтаксический анализатор кода, такой как здесь, на SO, тоже облегчает работу!]

На самом деле, я склонен использовать имена корреляций таблиц почти исключительно, поэтому я с большей вероятностью напишу:

SELECT P1.pi 
  FROM Pi AS P1;

Также учтите, что некоторые коллективные термины пишутся так же, как и единственный термин, например «виды», «олени», «овцы», «рыбы» и, возможно, многие другие, не относящиеся к животному царству, но у меня сейчас ментальный блок:)

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

Answer 9

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

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

Answer 10

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

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