Рекомендации по наименованию столбцов в Sql
Скажем, у меня есть таблица под названием Студент. Какие из следующих соглашений об именах вы предпочитаете для столбцов? Вы также можете предложить свои собственные.
Student
-------
StudentID
StudentName
MentorID
Student
-------
StudentID
Name
MentorID
Student
-------
ID
Name
MentorID
Ответы
Ответ 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
- Легко видеть, какой ключ является иностранным.
- Более короткие запросы
- Нет необходимости в псевдонимах