Se ho più tipi di un oggetto, quando object.type dovrebbe essere una stringa e quando dovrebbe essere una chiave esterna?

Question

Diciamo che ho libri che possono essere romanzi, finzione o mistero. Ho 2 opzioni realistiche per memorizzare questi dati. Uno è di avere una colonna di tipo nella tabella dei miei libri che è una stringa con il valore "storia d'amore", "finzione", o "mistero". L'altro è quello di creare una tabella book_types e memorizzare i tipi al suo interno. Quindi i miei libri avrebbero una chiave esterna type_id che fa riferimento alla tabella book_types.

La mia domanda è come scegliere quale sia la migliore? Ho visto il metodo stringa utilizzato nel plug-in Rails di autenticazione Restful che contiene informazioni sullo stato degli utenti: 'inattivo', 'attivo', 'in sospeso' ...

C'è un impatto sulle prestazioni nell'uso del metodo della tabella di ricerca considerando che cercherò sempre queste informazioni?

Grazie!

Answer 1

L'approccio con chiave esterna funzionerà meglio. Il confronto delle stringhe rallenta le cose. È molto più veloce confrontare i numeri.

Se si desidera accelerare ulteriormente le query, aggiungere un indice sulla colonna che si sta utilizzando per fare riferimento alla chiave esterna. A differenza delle chiavi primarie, gli indici non vengono creati automaticamente per le chiavi esterne.

Answer 2

se non ci sono mai più informazioni da archiviare su qualcosa, la stringa va normalmente bene (anche se questo è un valore non transitorio, quindi non è in forma normale).

Questo sembra comunque un buon candidato per un tavolo, quindi potresti voler fare di più con le categorie, quindi dovrebbe essere una tabella di riferimento, imo.

Answer 3

Nella maggior parte dei casi l'approccio con una chiave esterna a una tabella separata è il migliore - vantaggi:

• La tabella separata ti dà un modo estensibile per convalidare la voce. Inserimento di un vincolo di controllo codificato nella definizione della tabella quindi richiede una tabella ALTER per aggiungere un nuovo tipo

• Se hai mai bisogno di modificare il testo del tipo per qualche motivo (ad esempio "romanzo" & -; - gt; "romanzo femminile" per un esempio zoppo), avrai solo un leggero aggiornamento alla tabella di ricerca .

• Si potrebbe presumibilmente avere tipi per i quali non ci sono ancora voci e la tabella separata consente di utilizzare un join esterno per includere il tipo nei set di risultati SQL.

• Dal punto di vista dell'interfaccia, una tabella separata consente di generare facilmente un elenco a discesa di tipi che non richiedono hard-coding nell'interfaccia utente.

Per quanto riguarda le prestazioni, con l'indice corretto sull'FK qualsiasi motore RDBMS funzionerà bene - i join sono ciò per cui è progettato un RDBMS.

Answer 4

Vorrei usare fk. Meno informazioni duplicate.

EDIT: Soluzione migliore: Codice MySql:

CREATE TABLE books
(
    id int AUTO_INCREMENT          not null,
    book_type enum('romance', 'fiction', 'mystery')     not null,
    ....
);