对于我的目的来说，许多表是一种有效的数据库设计吗？
我需要创建一个数据库来存储有关游戏角色所在区域以及他们如何到达那里的详细信息。 我计划将字符 UUID 存储为二进制 (16) 索引，将区域名称存储为 varchar(25)，将 unix 时间存储为 int；其他领域尚未完全确定。
我还需要存储用户曾经去过的每个区域的完整历史记录以及相同的详细信息。
当角色在区域之间移动时，该系统将同时处理来自多个来源（至少一百个）的传入数据。
大多数查询只想了解与角色相关的信息，但有些查询想知道为给定区域上传的最后一个代理。我打算将此信息存储在单独的表中。
一位同事认为，对每个区域使用一个表对我来说会更有效，但我很担心，因为我不认为通常会这样做。
所以基本上我想知道在我的情况下，按照他所说的那样为每个区域使用单独的表是否会更有效。
I need to create a database to store details about what regions game characters have been in and how they got there.
I am planning to store the character UUID as a binary(16) index, the region name as varchar(25), and the unix time as an int; other fields aren't fully decided yet.
I also need to store the entire history of every region a user has ever been to along with the same details.
This system will deal with incoming data from many sources simultaneously (at least a hundred) as the characters move between regions.
Most queries will only want to know about things relating to a character, but some will want to know the last agents uploaded for a given region. I intend to store this information in separate table(s).
An associate believes that it would be more efficient for me to use a table for every region, but I am concerned because I do not see this usually done.
So basically what I want to know if in my case is it more efficient to do as he said and use separate tables for every region.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我会使用一张表，每个区域都有一个表意味着任何扩展都需要新的表，这反过来又意味着更多的编码。对于每个实体类型一个表，您只需在数据库中插入或删除行，就可以添加和删除多个区域。
I would use one table, to have one per region would mean any expansion down the track would require new tables, which in turn means more coding. With one table per entity type you can allow for many regions to be added and removed by just inserting or deleting rows from the database.
为每个区域创建一个表可能会更有效，但这会在设计和实现方面引起头痛。
现在，对于每个区域，它必须对其引用的表名称进行编码，而不仅仅是使用外键（区域的 ID）。同样，对于您决定稍后添加的每个区域（扩展等），您将需要添加新代码以及新表以与基本相同的操作进行交互。
仅当您确定这是瓶颈时我才会这样做。这种规模的预优化通常是一个错误。毕竟，采用良好的标准化设计并使其更具特定领域性是很容易的，但反之则很难。
Creating a table for every region very well might be more efficient, but that is going to cause a headache in terms of design and implementation.
Now, for every region, it must encode the table name it is referencing rather than just using a foreign key (the region's ID). Similarly, for every region that you decide to add later (expansions, etc), you will need to both add new code, as well as new tables to interact with a fundamentally identical operation.
I would only do this if you determine that it is a bottleneck. Pre-optimizing on this scale is generally a mistake. After all, it's easy to take the good, normalized design and make it a bit little more domain specific, but it's harder to do the reverse.