正常化具有類似數據類型的各種屬性

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