问具有大约70个属性的实体的一个或多个表

EN

你会让你的数据正常化。永远不会有一个列shiptype_a和另一个shiptype_b，而是一个包含ship类型的表，可能还有其他引用它的记录的行，而不是列。

或多或少：

“有10种不同类型的船”

• 这意味着一个表ship_types

“以及10个不同类型的防御单位。”

• 这意味着一个表defense_unit_types

“可能有0艘或多艘相同类型的船只和防御单位。”

• 这说明了两个额外的表：附带了和，或者只是简单地处理了这些类型。这取决于您是否希望平等地对待一种类型的实例(例如，您想知道A类型的船在开始时是东的，现在定位在西，还是只想知道现在有A类型的船)。

“还有两种类型的资源。”

• 这可以是一个表或一个标志。

“攻击者有船，而防御者有船和防御单位.所以我需要对每一种类型的攻击舰在战斗前后都有属性.”

• 所以每场比赛都有一名前锋和一名后卫。而且您似乎希望存储所有的游戏步骤(这样以后就可以回滚到以前的情况了？)。

这将导致以下表格：

• 对策 (game_id .)
• attacker_ship (game_id、step_no、ship_id)
• defender_ship (game_id、step_no、ship_id)
• defender_defense_unit (game_id、step_no、defense_unit_id)

或在没有船舶和defense_unit_table的情况下：

• 对策 (game_id .)
• attacker_ship (game_id、step_no、ship_type_id)
• defender_ship (game_id、step_no、ship_type_id)
• defender_defense_unit (game_id、step_no、defense_unit_type_id)

如果它是一个棋盘游戏，有64个字段，如国际象棋，那么您可以存储整个棋盘，但通常您仍然只是存储单个字段，而不是记录64×n字段(fields1_is_what、field1_attacker_ship_id、field1_defender_ship_id、field1_defender_defense_unit_id、field2_ .)。然而，这与性能无关，但更多的是与数据库的处理和如何编写查询有关。