Теория и ключи реляционной базы данных
Я разрабатываю схему для хранения данных игрока в браузерной игре.
У меня три отношения. Два из них имеют как минимум два ключа-кандидата, а третий имеет только три атрибута: {playerId, message, date}
Это отношение не будет содержать уникальных строк, поскольку существует отношение 1..1:0..*, означающее, что для каждого игрока может быть любое количество кортежей новостей. Мне не нужно иметь возможность однозначно идентифицировать любой кортеж, и ни один из атрибутов не может быть кандидатом.
Мой вопрос: я понимаю, что в реляционной модели не может быть дубликатов кортежей, и каждое отношение должно иметь ключ. Моя схема выше противоречит обоим этим ограничениям, но работает для моей цели. Я знаю, что мог бы просто добавить атрибут индекса (например, идентификатор), который является уникальным, но это кажется ненужным. Я что-то пропустил?
Спасибо за ваше время.
2 ответа
Я думаю, что вам не хватает сложного первичного ключа.
В вашем случае, если вы сохраняете, чтобы не получить дублирующих записей, вы хотите использовать составной первичный ключ.
Но подумайте о том, что один и тот же игрок отправляет одно и то же сообщение в одну и ту же дату.... В этом случае у вас будет конфликт с составным первичным ключом. Виртуальный уникальный идентификатор в качестве первичного ключа является более надежным способом.
Вопрос на засыпку! У меня нет четкого ответа, но я думаю, что вы можете столкнуться с проблемами, если у вас нет хотя бы одного ограничения на уникальность для всего кортежа: представьте, что какое-то приложение запускается само собой и пытается вставить 1 000 000 000 раз один и тот же кортеж в твой стол...