Question

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

似乎为每个类别类型创建两个额外的表（类型，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

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

Answer 1

这似乎是典型的Supertype-subtype表格集群。除非您没有将其识别出来。因此，正式识别它，并将数据标准化。

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

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

Link to Related Answer

关键是，如果你做那些“动态”的东西，那就做好吧。

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

Answer 2

来自您的属性描述 - 似乎第三种选择是合适的。

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

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

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

game_genre
-----------
game_id
genre_id

使用类似的数据类型规范化各种属性

2 个答案: