Соглашение об именовании внешних ключей - PullRequest
Новая
       7

Соглашение об именовании внешних ключей

2 голосов
/ 01 сентября 2009

При создании связей между таблицами (в mysql) я столкнулся с дилеммой именования.

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

**project_authors**
questionId
userId

и 

**project_bidders**
questionId
userId

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

project_authors
questionId
authorId

и 

project_bidders
questionId
bidderID

Проблема здесь сейчас заключается в том, что authorId и readerId на самом деле являются просто userIds, и имя не отражает это и может ошибочно указывать, что authorId и bidderId уникальны и различны сами по себе.

Я уверен, что в моем примере много дыр, но я недавно сталкивался с этой проблемой, так что мой вопрос: какой метод вы используете?

Ответы [ 6 ]

4 голосов
/ 01 сентября 2009

Что не так с author_userID и bidder_userID?

У вас есть люди, играющие роли, что всегда сложно. Вам необходимо отразить роль, а также основной объект, играющий эту роль.

3 голосов
/ 01 сентября 2009

Я бы сказал: 

project_users
-------------
questionId
userId
roleId

, где roleId - ссылка на таблицу, которая различает автора, участника торгов и т. Д. Положительный эффект - с помощью выбора составного первичного ключа вы можете контролировать, может ли пользователь быть только одним (автор или покупатель) или оба. Первый будет означать ключ над questionId, userId, второй - ключ над всеми тремя полями.

Примечание: лично я предпочитаю придерживаться одной схемы именования. Либо я использую everyhing_with_underscores, либо я использую camelCase / PascalCase, но не project_users и userId в одной базе данных.

1 голос
/ 01 сентября 2009

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

Пользователи Идентификатор_пользователя

Заказы Customer_UserID SalesRep_UserID

Таким образом, вы знаете конкретное использование идентификатора, а также фактическое имя идентификатора.

0 голосов
/ 01 сентября 2009

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

project_authors
questionId
authoredByUserId

и 

project_bidders
questionId
bidByUserId

Тогда в коде гораздо больше смысла при доступе к свойствам, например 

myProjectAuthorEntity.authoredByUserId = someUserId;
myProjectBidderEntity.bidByUserId = someOtherUserId;
0 голосов
/ 01 сентября 2009

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

tblUser

  • UserID (pk)

tblProjectAuthor

  • ProjectAuthorID (pk)
  • UserID (от fk до tblUser)

tblProjectBidder

  • ProjectBidderID (pk)
  • UserID (от fk до tblUser)

В своих запросах вы можете использовать префиксы, чтобы различать, на какой UserID таблицы вы ссылаетесь. 

select author.UserID 
from tblProjectAuthor author 
left join tblUser user on user.UserID = author.UserID

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

Например:

tblEmployee

  • EmployeeID (pk)
  • ManagerEmployeeID (от fk до tblEmployee)
0 голосов
/ 01 сентября 2009

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

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

...