Argomenti per la memorizzazione di associazioni binarie in un singolo campo e in una tabella di mappatura?

Sulla base del chiarimento che stiamo parlando di memorizzare i dati come testo separato da virgole in una tabella - non . Rende più difficile la ricerca, rende più difficile la modifica dei dati e rende l'applicazione più difficile da estendere.

L'unica volta in cui ciò sarebbe appropriato è se denormalizzi il database per eliminare ogni ultimo bit di prestazioni e memorizzi entrambi i singoli pezzi di dati nella loro tabella, < em> e una colonna separata (mantenuta in sincronizzazione) con dati di testo formattati. Lo faresti per semplificare le query per velocizzarle nel recupero a scapito del rallentamento delle cose su insert & aggiornamenti.

TablePokeMastersToPokemon <- Side question, what is a good naming convention for a linking table?

Queste sono chiamate associazioni o tabelle di associazione.

Inoltre, nessun nome di tabella dovrebbe mai iniziare con Table . È sciocco come iniziare ogni nome di variabile con "Variabile"

The only value I can see in the second method is a smaller number of tables, and it is easier to see the relationships right inside of one table, instead of building queries to see the relationships.

Questa è una falsa economia. Le tabelle (e la memoria associata) non sono quelle che stai cercando di ottimizzare.

Il secondo esempio elimina le chiavi primarie separate. Ciò significa che una semplice ridenominazione (per correggere un errore di ortografia di "PikaChu", ad esempio) non tocca più una riga, ma ora tocca numerose righe nella tabella di associazione.

Il secondo metodo è meno robusto ma consente le migliori prestazioni. La maggior parte delle volte vorrai mantenere il tuo schema il più robusto possibile perché i dati sono molto più lunghi del tuo codice.

La mia convenzione della mia associazione

Vorrei nominare la tua tabella delle relazioni in questo modo.

{One}{Many}

O per il tuo esempio specifico

PokeMaster
    Id
    Name

Pokemon
    Id
    Name

PokeMasterPokemon
    PokeMasterId
    PokemonId

Il prefisso di Table in realtà non aiuta molto qui.

Di certo non vedo molti benefici reali dal secondo metodo quando si tratta di mantenere i tuoi dati. Usi le strutture delle tabelle relazionali per aiutare in molti modi, incluso rendere la vita MOLTO più facile quando esegui tutte le operazioni CRUD (ad esempio, dammi un modo semplice e veloce per aggiornare "Charizard" nei tuoi dati secondari sopra - non c'è).

Allo stesso modo, dovresti davvero saltare attraverso i cerchi per riferire su quei dati, e se mai in fondo dovrà essere inserito in un data warehouse di qualche tipo, fare di una tabella delle dimensioni sarebbe un incubo.

Se hai un basso numero di record, l'impatto sulle prestazioni di ciò che stai suggerendo è trascurabile. Tuttavia, quando si raggiungono migliaia di record e si desidera eseguire una query sul pokemon, si noterà un impatto grave. Per non parlare dell'utilizzo di un elenco delimitato da virgola varchar per archiviare i dati che verranno eseguiti in un limite dei dati che è possibile memorizzare. Con una tabella relazionale hai una capacità praticamente illimitata di collegare il pokemon.

A volte è utile la seconda forma con più valori:

• Quando non c'è un rispettivo valore nell'altra tabella più lungo (l'integrità della chiave esterna non è disponibile)

• Quando non c'è un valore corrispondente ancora (forse le regole aziendali consentono a un utente di mappare a qualcosa che non esiste ancora - accade)

• Quando è necessario mappare a un pool più grande di valori non completamente contenuti nella tabella di mappatura

Tutti questi sono casi piuttosto speciali ma sono reali.