关系数据库理论与要点
我正在设计一个架构来在基于浏览器的游戏中保存玩家数据。
我有三个关系。其中两个至少有两个候选键，但第三个只有三个属性：{playerId, message, date}
该关系将不包含唯一行，因为存在 1..1:0..* 关系，这意味着可以可以是每个玩家的任意数量的新闻元组。我不需要能够唯一地标识任何元组，并且无论如何，没有一个属性实际上可以成为候选者。
我的问题是：我理解关系模型规定不能有重复的元组，并且每个关系必须有一个键。我上面的模式与这两个约束相矛盾，但适合我的目的。我知道我可以简单地添加一个唯一的索引属性（如 ID），但这似乎没有必要。我错过了什么吗？
感谢您抽出时间。
I'm designing a schema to hold player data within a browser based game.
I have three relations. Two of them have at least two candidate keys, however the third has only three attributes: {playerId, message, date}
This relation will hold no unique rows as there is a 1..1:0..* relationship, meaning there can be any number of news tuples for each player. I don't need to be able to uniquely identify any tuple and none of the attributes can actually be a candidate, anyway.
My question is: I understand the relational model states there cannot be duplicate tuples and each relation must have a key. My schema above contradicts both of those constraints but works for my purpose. I know I could simply add an index attribute (like an ID) that is unique, but that seems unnecessary. Am I missing something?
Thanks for your time.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我认为您缺少的是复合主键。
在您的情况下，如果您要保存以获取不重复的条目，则需要使用复合主键。
但想想同一个玩家在同一日期发送相同的消息......
在这种情况下，您将与复合主键发生冲突。
使用虚拟唯一 ID 作为主键是一种更节省的方法。
I think what you are missing is a composite primary key.
In your case if you are save to get no dublicate entries you want to use a composite primary key.
But think about the same player sends the same message at the same date....
In this case you will have a conflict with a composite primary key.
A virtual unique id as primary key is a saver way.
棘手的问题！我没有明确的答案，但我认为如果你对整个元组没有至少一个唯一性约束，你可能会遇到麻烦：想象一些应用程序疯狂运行并尝试插入 1.000.000.000 次相同的元组你的桌子...
Tricky question ! I don't have a clear answer, but i think you may run into trouble if you don't have at least a unicity constraint on the whole tuple : imagine some app runs amok and tries to insert 1.000.000.000 times the same tuple in your table...