У меня есть схема реляционной базы данных следующим образом
Первичные ключи подчеркнуты.
Сценарий: я должен управлять бронированием на теннисных кортах. Как видно из рисунка, каждый корт принадлежит ровно одному спортивному центру, каждый центр принадлежит ровно одному городу. Давайте забудем о персонале, игроке и столе бронирования , потому что мой вопрос к ним не относится.
Так что у моего профессора был очень странный способ реализации этой схемы в MySQL. Он создал уникальные атрибуты CenterName и CourtName (и даже PlayerName). CityName также уникален, но я думаю, что это оправдано. Что стоит подвергнуть сомнению, так это то, как он это сделал:
Предположим, у меня есть City A, у которого Center 1, у которого Court i. Он будет хранить City A_Center 1 в поле CenterName и City A_Center 1_Court i в поле CourtName.
В основном он будет связывать информацию из других атрибутов, чтобы сделать атрибут уникальным, вместо того, чтобы определять уникальные условия на наборы атрибутов (CenterName, CityID) и (CourtName, CenterID).
Способ, которым он оправдал свой дизайн, заключается в том, что он может использовать имена вместо номеров идентификаторов при вызове хранимых функций. Он также сказал, что имена должны быть предпочтительнее идентификаторов, а идентификаторы должны использоваться только для фильтрации (не уверен, что это такое). Он сказал, что методика объединения, приведенная выше, чтобы сделать имена уникальными, «все время делается на практике». Я действительно сомневаюсь в этом.
Это правда?