1

我正在建立一个数据库来存储与游戏相关的属性，例如它是否支持多人游戏、它是什么类型、发布日期等。

似乎为每个类别类型创建两个额外的表（例如，genres、genres_data）并没有像它应该的那样动态。我最初的想法是设置它的两种方式之一......

有一个包含骨架信息的游戏表，然后是一个列出所有属性的属性表，还有一个包含与游戏相关的所有数据的第三个表，其中基本上只使用与每个属性相关的列：

games
-----------
game_id
... relevant data

properties
-----------
property_id
title
type
category

properties_data
---------------
game_id
property_id
bool
min
max
date
text(max255)
longtext

或者，让游戏表相同，并让属性包含列名，然后使用第三个表中的列：

properties
--------------
property_id
title
type
category
column_name

properties_data
----------------
game_id
title
description
release_date_au
release_date_jp
genre_rpg
genre_fps
platform_360
platform_ps3
platform_pc
has_leaderboards
has_downloadable_content
... etc

在这种情况下，您有六种左右类型的数据与一行相关，但每个类别中有大量类别和支持属性，那么实际的方法是什么？为每种属性类型或类别（对我而言）制作表格似乎效率不高。

4

2 回答 2

3

这似乎是典型的超类型-子类型表集群。除非您尚未将其识别为此类。因此，正式识别它，并对数据进行规范化。

  • 在超类型（父）中放置公共列
  • 将特定于每个子类型的所有列放在单独的子表中
  • 这样你就没有可选的列了
  • 如果你这样做，那么你需要另一个级别的子表。

如果您选择“动态”填充的表，那么您将失去对数据库中静态表的所有控制，并使用 DDL（而不是代码）中定义的业务规则。在这种情况下，请注意，这些松散定义的表以最终变得一团糟而没有数据完整性而闻名。阅读这个最近的答案以获得一些背景信息。

链接到相关答案

关键是，如果你做那些“动态”的事情，那就正确地去做。

但我不认为你需要走那么远。使用普通的 Rdb，您可以保持完整的关系能力和灵活性。更多的表是 Rdb 的本质，没什么好害怕的。做得好，您将拥有完全的控制力和速度。这让我回到了第一段。

于 2010-11-29T23:27:49.740 回答
1

从您的属性描述中 - 似乎第三个选项是合适的。

games
--------
game_id
name
...

release
----------
release_id
game_id
release_date
release_country

genre
---------
genre_id
name

game_genre
-----------
game_id
genre_id
于 2010-11-29T19:40:22.740 回答