数据库架构设计的关系

Question

您好，

我是新来的数据库设计，我想设计一个模型非常简单的模式。

只是想知道这是否是设计它的最佳方式，因为这是我第一次，并且不想在没有外观的情况下建立它。

Pokemon table:

• 我得到name, id (PK), type(FK), image and regionID(fk)
• type从Type表的外键，并具有one-to-many关系。这听起来是对的吗？我在想这是因为one pokemon can have multiple types？另外multiple pokemon can have multiple类型对我来说很有意义。
• regionID是来自Region表的外键。 many pokemon can live in many regions对我有意义。或者应该是one pokemon can live in multiple regions？或multiple regions can have multiple pokemon？

Region table:

• 我只有在这里得到了PK。我是否也需要LocationWithinRegion表中的FK？
• 这里我有一个one to many的关系，因为1 region can have multiple locations但是one location can't have multiple regions。这是正确的吗？

Type table：

• 我提出的所有这些类型的比特，所以我可以表示一个布尔值。我希望能够查询宠物小精灵表并查找所有相关数据，并在可找到该宠物小精灵的地区找到真或假。

这是我第一次制作数据库模式，请让我知道它是怎么样的！

感谢

Answer 1

一般：

• 提供每个表有奇异的名字。 User而不是Users因为每个
  行代表一个用户。
• 为每个表提供可能的最小主键。在大多数 的情况下，一个身份int会做。
• 在外键列上创建索引。这将有助于加入。

现在你的情况：

有Pokemon和Type之间的许多一对多的关系。所以我会从Pokemon表中删除PokemonType string，我会创建一个表Type(Id int Identity PK, Description string Unique)和一张桌子PokemonType(PokemonId int FK on Pokemon, TypeId int FK on Type, PK on both columns)

也就是Pokemon和Region之间的许多一对多的关系。

通常，为了表示多对多关系，您需要两个表之间的查找表。

有点像（ID） - >查找（A.id，B.id）< - B（ID）