正常化具有类似数据类型的各种属性

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子类型的表簇。除非你没有确定它是如此。因此，请正式确定并正确处理数据。在超类（父）

• 地方公共列
• 在单独的子表
• 让你最终没有可选列
• ，如果你这样做，那么具体到每个子类型的所有列你需要另一个级别的子表。

如果您使用“动态”填充表，您将失去使用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