Подтвердить что ты не робот

Рекомендации по наименованию столбцов в Sql

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

Student
-------
StudentID
StudentName
MentorID

Student
-------
StudentID
Name
MentorID

Student
-------
ID
Name
MentorID
4b9b3361

Ответ 1

Я бы пошел со вторым.

Student
-------
StudentID
Name
MentorID

Мне нравится иметь имя таблицы в главном ключе, но это не обязательно должно быть в каждом поле. Также MentorID будет таким, как я бы назвал внешний ключ (предполагая, что Mentor - это имя таблицы, на которую он указывает).

Таким образом, поле MentorID в таблице Student имеет то же имя, что и поле MentorID в таблице Mentor. Некоторым людям это не нравится, потому что это может быть немного запутанным при соединении таблиц, но я предпочитаю явно указывать таблицы полей в объединениях в любом случае,

Ответ 2

Поскольку регулярные RDBMS являются своего рода иерархическими, СУБД содержит базу данных - база данных содержит таблицу - таблица содержит столбец - столбец содержит значение, мне не нравится итеративное использование имен таблиц в именах столбцов.

Мое голосование:

Student
--------
id (pk)
name
mentor (fk) (alt. mentorId)

Довольно легко выбрать правильные поля, а в случае соединений между таблицами я часто переименовываю имена столбцов, то есть:

SELECT s.id AS StudentID, s.name AS StudentName, m.id AS MentorId, m.name AS MentorName
FROM Studens AS s
INNER JOIN Mentors AS m ON m.id=s.mentor

Ответ 3

так как некоторые sql формируют прописные слова, я иду с описанием:

student
-------
id
name
mentor_id

таким образом я могу сохранить разделение слов в db.

в OO-коде я использую соответствующие имена верблюдов

mentorId, getMentorId()

Ответ 4

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

 SELECT blah blah blah
 FROM Student INNER JOIN Mentor
      ON Student.MentorID = Mentor.ID

Но это почти так же субъективно, как "вам нравится дело верблюда?": P

Главное - быть последовательным. Мне приходилось иметь дело в прошлом с некоторыми базами данных, где они никогда не могли принять решение по стандарту. Таким образом, в некоторых таблицах PK будет StudentID, другие Student_ID и другие ID. Или они не использовались последовательно, когда используются в качестве внешних ключей. Ой, я начинаю говорить...

Ответ 5

Я бы лично пошел с:

Students
--------
student_id
first_name
last_name
mentor_id

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

Я также могу понять аргументы только для использования "id", а не "student_id", поэтому я не прочь от этого.

Ответ 6

Я предпочитаю второй:

Students
-------
StudentID
Name
MentorID

Где:

  • Все внешние ключи идентифицируются с ID в конце имени столбца.
  • Остальные столбцы называются с понятным понятием.
  • Также используйте EndDate, BeginDate для дат.

Ответ 7

Я предпочитаю первый.

Предоставляя поля более конкретное имя, чем просто Id или Name, вам легче увидеть, что вы правильно соединяетесь, и вам не нужно использовать псевдонимы для полей, если вы выбираете поля из более чем одна таблица:

select s.StudentId, s.StudentName, m.MentorId, m.MentorName
from Student s
inner join Mentor m on m.MentorId = s.MentorId

против.

select s.Id as StudentId, s.Name as StudentName, m.Id as MentorId, m.Name as MentorName
from Student s
inner join Mentor m on m.Id = s.MentorId

Кроме того, слово Name является зарезервированным ключевым словом в некоторых базах данных (например, SQL Server), поэтому его не всегда удобно использовать в качестве имени поля.

Ответ 8

Насколько я ненавижу, я бы пошел с Вариантом 1:

Student
-------
StudentID
StudentName
MentorID

Причиной этого является присоединение к другим таблицам с столбцом "Имя", например "Курс" или "Степень" или что-то еще, для присоединения требуется, чтобы вы переименовали столбцы, чтобы избежать неоднозначных имен. Работа с длинными именами, в которых есть имя таблицы, раздражает, но это может сэкономить вам работу в долгосрочной перспективе.

Ответ 9

Я бы пошел с номером 1:

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

Избегайте использования идентификатора, а затем у вас нет идеи, какой идентификатор для какой таблицы. Сделайте это однозначным, и тогда вам придется квалифицировать его в любом случае. student_ID = mentor_ID - это ПОЛНАЯ партия, более читаемая чем a.id = b.id. Это не полезно, трудно читать, нужно затем выяснить, что такое a и b, и не является гибкой практикой. Код /SQL должен быть легко читаемым без комментирования.

Пользователь подчеркивания помогает с удобочитаемостью, в стороне от верблюда (поскольку это то, что я использую в С#) Я всегда ставил PK в качестве первого имени поля и связанного FK как поля 2, 3 и т.д.

Не завершайте имя поля с помощью _s или _d для деления строки или даты.

Мне нравятся вещи аккуратные и недвусмысленные, потому что я хочу быть внимательными к другим, которые идут позади меня, которые должны делать maint на БД. Слишком много людей перетаскивают вредные привычки из Access в SQL. В основном потому, что у них не было наставника, чтобы помочь им учиться!: -)

Помните, что при текущем обслуживании всегда важнее задача, чем первоначальная разработка.

Ответ 10

Я могу использовать имя StudentName вместо Name, потому что это упростит объединение. Часто я нахожу, что у меня много, много таблиц с столбцом "имя" и "описание".

Ответ 11

И я бы пошел почти с третьим:

Student
-------
Id
Name
Mentor_Id

SELECT Student.Name, 
  Student_Mentor.Name
FROM Student
  INNER JOIN Mentor AS Student_Mentor ON Student.Mentor_Id = Student_Mentor.Id

Ответ 12

Я обычно делаю номер 3

Student-------
ID
Name
MentorID

Ответ 13

В качестве побочного примечания, как сокращение слов, таких как Company, Brother и Number to Co, Bro и No, я бы рекомендовал, чтобы Identity сокращался до "Id" вместо "ID", поскольку капитализация буквы "d" 'предполагает, что' Id 'является аббревиатурой, а не сокращением.

Ответ 14

Название, скорее всего, зарезервированное слово, я бы никогда не использовал его как имя столбца. Я также не хотел бы хранить имена в одном поле. Вам действительно нужны first_name, Middle_name, last_name, Suffix (для III, Jr и т.д.). Подумайте, что вам нужно сделать, чтобы запросить поле имени, когда вы хотите, чтобы все клиенты с именем "Смит".

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

Может ли только один человек стать наставником? Unikely. Ментор должен быть отдельной таблицей, и должна быть таблица соединения с StudentID и mentorID

Ответ 15

Для этого нет "правильного" ответа. Просто выберите любое соглашение об именах, которое вам нравится (и все, кто будет использовать ваш db), и придерживайтесь его. В Интернете существует множество хорошо разработанных соглашений об именах. Просто найдите Google в "Соглашениях об именах SQL".

По моему опыту люди используют совершенно разные стили, но это нормально, пока все приложение (или все проекты в одной организации) используют одни и те же соглашения.

Ответ 16

Я предпочитаю использовать этот шаблон:

student
-------
id
name
mentor_id

_id for foreign keys

Ответ 17

Мне действительно нравится:

Student
-------
Id
Name
IdMentor

Я думаю, это похоже на подражание венгерской нотации. Там также больше визуальной разницы между IdMentor и Mentor.Id, чем между MentorId и Mentor.Id.

Ответ 18

Student
-------
Id
Name
MentorId

Это сработало бы для меня.

Ответ 19

Student
-------
Id
Name
Mentor_Id

inner join Mentor m on m.Id = s.Mentor_Id
  • Легко видеть, какой ключ является иностранным.
  • Более короткие запросы
  • Нет необходимости в псевдонимах