Нормализация множества свойств с похожими типами данных - PullRequest
Новая
       56

Нормализация множества свойств с похожими типами данных

1 голос
/ 29 ноября 2010

Я работаю над настройкой базы данных для размещения свойств, связанных с игрой, например, поддерживает ли она многопользовательскую игру, какие это жанры, даты выхода и т. Д.

Похоже на создание двухдополнительные таблицы (например, 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

Каков практический подход в сценарии такого рода, когда у вас есть около полудюжины типов данных, связанных со строкой, но большое количество категорий и вспомогательных свойств в каждой категории?Мне кажется неэффективным составлять таблицу для каждого типа свойства или категории (для меня).

Ответы [ 2 ]

3 голосов
/ 30 ноября 2010

Это типичный кластер таблиц супертипа и подтипа.За исключением того, что вы не определили его как таковой.Итак, определите его формально и нормализуйте данные.

  • поместите общие столбцы в супертип (родительский)
  • поместите все столбцы, специфичные для каждого подтипа, в отдельную дочернюю таблицу
  • чтобы в итоге не было необязательных столбцов
  • , если вам это нужно, тогда вам нужен другой уровень вложенной таблицы.

Если вы выбираете "динамически" заполненные таблицыВы теряете все управление статическими таблицами в БД с правилами busienss, определенными в DDL (не в коде).В этом случае имейте в виду, что эти слабо определенные таблицы известны тем, что в конечном итоге превращаются в беспорядок без целостности данных.Прочитайте этот недавний ответ, чтобы получить некоторый контекст.

Ссылка на связанный ответ

Дело в том, что если вы делаете эту "динамическую" вещь,делай это правильно.

Но я не верю, что тебе нужно заходить так далеко.С обычным Rdb вы можете поддерживать полную мощность и гибкость отношений.Больше таблиц - это природа Rdb, нечего бояться.Сделано правильно, у вас будет полный контроль и скорость.Что возвращает меня к первому пункту.

1 голос
/ 29 ноября 2010

из ваших описаний атрибутов - кажется, что третий вариант подходит. 

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

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

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

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