비슷한 데이터 형식을 사용하여 다양한 속성 정규화

Question

게임 관련 속성을 저장하는 데이터베이스 (예 : 멀티 플레이어 지원 여부, 장르, 출시 날짜 등)를 설정하는 중입니다.

각 카테고리 유형에 대해 두 개의 추가 테이블 (예 : 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 

, 각 속성에 관한 본질적 열만 사용되는 경우

이 종류의 sc에서 실질적인 접근 방식은 무엇입니까? 어디 행에 관련된 데이터가 6 개 정도 있지만, 각 카테고리에 많은 수의 카테고리와 지원 속성이 있습니다. 각 속성 유형이나 카테고리 (나에게)에 대한 테이블을 만드는 것이 효율적으로 보이지 않습니다.

Answer 1

이것은 테이블의 전형적인 Supertype-subtype 클러스터 인 것으로 보입니다. 당신은 그런 것으로 확인하지 않았다. 따라서 형식적으로 식별하고 데이터를 표준화하십시오. 슈퍼 타입 (부모)의

• 장소 일반적인 열
• 장소 당신은 어떤 선택 열 다음
• 당신이 경우에, 끝낼 것을
• 때문에 별도의 자식 테이블의 각 하위 유형에 고유 한 모든 열 다른 레벨의 서브 테이블이 필요합니다.

"동적으로 채워진"테이블을 사용하는 경우 DDL (코드 아님)에 정의 된 busiens 규칙을 사용하여 db의 정적 테이블에 대한 모든 제어 권한을 잃게됩니다. 이 경우, 이러한 느슨하게 정의 된 테이블은 데이터 무결성이없는 혼란으로 끝나는 것으로 유명합니다. 이 최근 답변을 읽어 보면 상황을 알 수 있습니다. 당신이 그 "동적"물건을 제대로 할 경우

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