Elementi multipli in una singola colonna SQL

Se vedi qualcuno che inserisce "cose" diverse in una singola tabella di database usando un delimitatore per tenerle separate, è un problema .

Potrebbe essere che qualcuno non abbia il permesso di cambiare la struttura del database o che semplicemente non "ottenga" i database. In ogni caso, è un mal di testa per le prestazioni e la manutenzione.

Nella tua situazione probabilmente creerei 3 tabelle: "Item", "Amenity" e "ItemAmenity".

La tabella 'Articolo' contiene record che rappresentano la cosa che ha amenità. La tabella "Amenity" contiene record che rappresentano ogni possibile amenità. La tabella 'ItemAmenity' ha chiavi esterne che collegano un particolare 'Item' ad un particolare 'Amenity'.

Questa è chiamata una relazione "molti a molti".

Puoi trovare codice di esempio in relazione molti-a-molti MySQL con i tasti STRANIERE

Utilizza sempre una tabella collegata separata per la memorizzazione di dati di tipo "multiple x per ogni y".

Il primo modulo normale richiede che ogni campo di una riga contenga un valore atomico, ovvero un valore che non è divisibile in più sotto-valori.

Nel caso ti stia chiedendo quanto sia utile una tabella separata, confrontati con un elenco separato da virgole in una singola colonna, considera come andresti a scrivere queste query:

• Un elenco di entità con più di 4 ma meno di 9 servizi.
• Un elenco di entità associate a "amenity A" ma non "amenity B" o "amenity C".
• Un elenco di entità con gli stessi servizi di "entità X" e "entità Y" combinate.

Con una tabella separata, le query precedenti sarebbero banali con SQL di base.

Se desideri flessibilità e una certa facilità nella gestione dei dati, creerai una tabella separata e le collegherai, ma se hai esigenze e prestazioni minime è una preoccupazione, puoi metterle tutte in una sola.

L'altro sviluppatore potrebbe aver deciso che non era necessario selezionare specifici indirizzi IP o ottenere un conteggio del numero di indirizzi IP di ciascuna entità, quindi perché preoccuparsi di un'altra tabella? Infatti, interrogare i dati e dover scrivere codice per "raggruppare" tutti quegli indirizzi IP in un campo potrebbe non essere stato l'ideale.

La risposta facile in un database relazionale è la normalizzazione. La tua immissione e gestione dei dati sarà più flessibile. Il tuo caso d'uso ti dirà se questo è necessario o meno. Decidere di cambiare in seguito è sempre più difficile. Questo è il rischio che prendi se ti preoccupi delle prestazioni. Ci sono molte cose che possono essere fatte per accelerare le cose senza sacrificare la normalizzazione.