Вопрос:
У меня есть две таблицы:
- Person (personID, имя, адрес, телефон, электронная почта)
- Игрок (дата рождения, школа)
Какой код я бы использовал, чтобы я мог использовать personID в Person в качестве первичного ключа в таблицах Person и Player?
Я понимаю, что playerID также должен быть внешним ключом в Player. Есть идеи?
Лучший ответ:
Не ясно, что вам нужны две таблицы для этой информации, если только не представлены люди, которые не являются игроками. Предположим, что это так (другие люди могут быть тренерами, родителями, судьями и т.д.). Кроме того, несмотря на то, что тренеры действительно родились, их дата рождения не является существенной для системы (поэтому нет необходимости передавать дату рождения обратно в таблицу Person). Кроме того, предположите, что вы имеете дело с людьми, которые посещают только одну школу; если они были в другой школе в прошлом году, запись игрока будет обновляться между сезонами. (Если вам нужна историческая информация о школах, посещаемых в разные годы, вам понадобится другая структура таблицы.) Также можно предположить, что со временем вы добавите больше полей в таблицу Player.
В этом случае вам необходимо связать данные проигрывателя с нужным человеком:
CREATE TABLE Player ( PlayerID INTEGER NOT NULL PRIMARY KEY REFERENCES Person(PersonID), DateOfBirth DATE NOT NULL, School VARCHAR(20) NOT NULL REFERENCES School(SchoolName) );
Я предполагаю, что список школ ограничен. Вы можете использовать целое число SchoolID вместо имени школы для присоединения; что имеет тенденцию быть более компактным.
Ответ №1
Сначала вы должны иметь personID в таблице Player.
Как только это будет сделано, вы можете иметь personID как первичный ключ таблицы Player, а также можете иметь отдельный столбец playerID, и это может быть первичный ключ.
Какой выбор вы выбираете, зависит от ваших требований приложения. Если вы считаете, что игрок будет связан только с одним человеком и определенно одним человеком, то personID может быть основным ключом.
Но во многих случаях вам понадобится отдельный playerID (и я предлагаю его). Например, если вы не моделируете компьютерные игры, все игроки могут не быть людьми – personID будет null. Также, если вы ставите баскетболиста, отличного от футболиста, человек, который играет в эти игры, может иметь несколько записей в таблице игроков (несколько записей с одинаковым personID).
Ответ №2
Не могли бы вы добавить поле personID и управлять им так же, как вы управляете таблицей человека? Каждый раз, когда вы вставляете игрока, вам нужно будет вставить соответствующее лицо с тем же идентификатором.
конечно, если ваша концепция человека абстрактна, то она обязательно должна находиться в одной таблице.
Ответ №3
Я предлагаю переместить поле даты рождения из таблицы “Player” в таблицу “человек” (в конце концов, у человека нет нескольких дат рождения!), затем добавьте поле “personID” в таблицу “игрока”. Если у человека есть несколько школ (начальный, средний, высокий), то основным ключом таблицы “игрок” должен быть человек + школа.
Определенно нет проблем в том, что один первичный ключ таблицы служит в качестве первичного ключа во второй таблице; такая вторая таблица может помочь сократить дисковое пространство и улучшить время доступа. Скажем, что для некоторых, но не для всех, существует большое текстовое поле. Сохранение этого поля во вторичной таблице (с тем же самым первичным ключом) означало бы, что только люди, которые нуждаются в этом поле, будут иметь записи во вторичной таблице.
