La normalizzazione di una varietà di proprietà con simili tipi di dati

Question

Sto lavorando sulla creazione di un database per la casa di proprietà relative ad un gioco, ad esempio se non supporta la modalità multiplayer, che generi è, date di rilascio, etc.

Sembra che la creazione di due ulteriori tabelle (generi, genres_data per esempio) per ogni tipo di categoria non è così dinamico come potrebbe essere.Il mio pensiero iniziale era quello di impostare uno dei due modi...

Dispone di un tavolo da gioco con scheletrico informazioni, quindi una proprietà tabella per elencare tutte le proprietà, e una terza tabella per contenere tutti i dati relativi al gioco, dove essenzialmente solo le colonne relative a ciascuna struttura sono utilizzati:

games
-----------
game_id
... relevant data

properties
-----------
property_id
title
type
category

properties_data
---------------
game_id
property_id
bool
min
max
date
text(max255)
longtext

O, sono i giochi di tavolo stesso, e hanno proprietà include un nome di colonna, quindi, utilizzare le colonne nella terza tabella:

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

Qual è l'approccio pratico in questo tipo di scenario in cui si dispone di una mezza dozzina di tipi di dati relativi a una riga, ma un gran numero di categorie e sostenere le proprietà di ogni categoria?Non sembra che sia efficiente per fare una tabella per ogni tipo di proprietà o la categoria (per me).

Answer 1

Questo sembra essere un tipico Supertipo-sottotipo cluster di tabelle.Tranne che non hai identificato come tale.Quindi, identificare formalmente, e normalizzare i dati.

• luogo comune colonne del Supertipo (genitore)
• posto tutte le colonne specifiche per ogni Sottotipo in un separato tabella figlio
• in modo che si finisce con n colonne opzionali
• se si, allora avete bisogno di un altro livello di sub-tabella.

Se si va per "dinamicamente" popolate le tabelle, si perde il controllo di tutti statico tabelle in un db con l'lavorative regole definite nel DDL (non il codice).In questo caso, essere consapevoli del fatto che questi genericamente definito le tabelle sono famosi per finire come un pasticcio senza l'integrità dei dati.Leggere questo recente risposta per ottenere un po ' di contesto.

Link Correlati Risposta

Il punto è che se fai quella "dinamica" di roba, farlo correttamente.

Ma non credo che avete bisogno di andare lontano.Con un normale Rdb, è possibile mantenere la relazione di potenza e flessibilità.Più tabelle sono la natura dell'Rdb, niente di cui avere paura.Fatto correttamente, si avrà il pieno controllo e velocità.Il che mi riporta al primo comma.

Answer 2

dal tuo attributo descrizioni, sembra una terza opzione è appropriata.

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

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

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

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