Come si può pensare ad uno schema relazionale in termini di memorizzazione in un database NoSQL?

Se stai parlando di archivi di documenti e disponi del tuo database di brani, prova a pensare a memorizzare i testi di tutte le canzoni. Quelli non possono davvero essere memorizzati in modo relazionale. Perché non puoi davvero modellare le parole di un testo in modo relazionale alla canzone.

Tuttavia ciò che puoi fare è mettere tutti i testi in un negozio di documenti e renderli ricercabili.

Utilizza lo strumento giusto per il lavoro, non provare a modellare i dati relazionali in modo non relazionale solo perché NoSQL è la tendenza.

Con i database NoSQL / Document, devi pensare a come interrogerai i tuoi dati. Pensa ad esso come costruire indici, tranne che gli indici sono i tuoi dati. Puoi avere più indici che possono avere dati duplicati. RDBMS ti dà il lusso di mantenere tutte le varie relazioni, vincoli e indici in modo da poter avere la struttura migliore per entrare e soprattutto aggiornare i dati. Questa è la bellezza di un database normalizzato; aggiorna la data di nascita dell'artista e si mostra correttamente in tutte le tue domande.

I dati normalizzati hanno un prezzo e il prezzo può essere una performance, ma uno più grande è uno schema fisso. I database relazionali amano uno schema fisso. Costruiscono tutti questi piani e statistiche su come accedere ai tuoi dati perché conoscono tutte le colonne, i loro tipi e anche qualcosa sui dati stessi, per ottimizzare le cose per te. Dovrai gestire molto questo nella tua applicazione.

Il design dello schema può essere molto più semplice in NoSQL, perché per ogni album o traccia, hai tutta la flessibilità di inserire più artisti singoli, band, orchestre, ecc. In un database normalizzato, stai andando avere la necessità di pianificare in anticipo molti di questi campi e correre il rischio che molti di essi siano vuoti o con tabelle speciali per tipi speciali di registrazioni. Le bande punk non hanno conduttori. Che cosa succede se hai una registrazione di un artista di strada o di una registrazione storica e non sai nemmeno chi sia, ma hai chi lo ha registrato, quando e dove. Non importa. Puoi consentire questo tipo di immissione e recupero dei dati, senza ristrutturare una tabella.

Ho menzionato in un commento che i database relazionali stanno migliorando con la gestione di grandi campi di testo / binari e persino indicizzandoli. Alcuni stanno seguendo un percorso ibrido e includono alcuni NoSQL. Mettere una grande porzione di XML con tutti i loro diversi dati in un campo è solo un'eresia per i puristi relazionali.

Proprio quando pensi di sapere tutto ciò che c'è da sapere sulla gestione di un database, prova a eseguirlo su due server. Questo è quando inizia il divertimento. NoSQL rende questo un po 'più facile. Un prodotto come Nuodb cerca di offrire il meglio di entrambi i mondi.

A prima vista, penso che il tuo esempio avrà molto più senso se invertirai la tua struttura in modo che un album sia una proprietà secondaria di una Band (che è composta da un gruppo di artisti). Con soluzioni NoSQL basate su documenti, trovo utile disegnare le classi in anticipo e, a volte, utilizzare classi nidificate (in C #) in modo che le classi di livello superiore rappresentino i tipi di Raccolta documenti. Il modo in cui si nidificano le classi, o quali classi sono di livello superiore, i documenti dipendono dal modo in cui si interagirà con questi dati. Un approccio molto comune sarebbe che un documento faccia riferimento a un altro tramite il suo ID e alcuni campi denormalizzati che vengono comunemente chiamati. Dai un'occhiata a questa struttura di classi 2min che ho montato in C # per il tuo esempio di Music Store nella domanda:

// top-level document
public class Band
{
    public BandMate[] BandMembers { get; set; }
    public Album[] Albums { get; set; }

    public class BandMate
    {
        public DateTime Joined { get; set; }
        public DateTime? Left { get; set; } // nullable
        public string ArtistName { get; set; }
        public string ArtistId { get; set; }
    }

    public class Album
    {
        public string Id { get; set; }
        public string Title { get; set; }
        public DateTime ReleaseDate { get; set; }
        public Song[] Songs { get; set; }

        public class Song
        {
            public string Title { get; set; }
            public string Lyrics { get; set; }
        }
    }
}


// top-level document
public class Artist
{
    public string Name { get; set; }
    public string Id { get; set; }
    public DateTime DateOfBirth { get; set; }
    public string[] Background { get; set; }
    public Instrument[] InstrumentsKnown { get; set; }
    // more fields here for divorces, children, overdoses, etc....
}

Alcuni oggetti, come i Songs, sono contenuti completamente all'interno della classe genitore, quindi sono interamente parte del più grande documento / classe "Band". Tuttavia, gli artisti stessi potrebbero contenere molte informazioni che non sono necessarie al 100% durante il rendering delle informazioni sugli album, che probabilmente si preoccupano solo dei loro nomi, o forse dei loro strumenti. Pertanto la classe BandMate contiene l'ID artista, nel caso in cui si desideri effettuare ricerche sul documento Artista per tutte le informazioni complete, ma includa anche il loro nome denormalizzato, in modo che sia molto semplice rendere l'appartenenza alla banda da una semplice query su Album. Questo livello di denormalizzazione dipende da te e vincolato dal sapore del database Document NoSQL che scegli.

Infine, senza cercare di sembrare accondiscendente, se non si ha familiarità con un paradigma come DocumentDb / NoSQL, allora è piuttosto facile dire "Oh, immagino che i dati delle mie app siano puramente relazionali", quando è solo il fatto che tu Abbiamo utilizzato DB relazionali per archiviare il 99% dei dati delle applicazioni per anni poiché è quello che è più comunemente disponibile (prima di questa meravigliosa nuova era di MongoDb / CouchDb / RavenDb / etc). Questo esempio in realtà non mostra tutta la potenza dello storage senza schema, ma in C #, ad esempio, posso memorizzare raccolte di oggetti figlio sotto l'etichetta di un'interfaccia, e il db NoSQL può fare il lavoro di inizializzarle al loro tipo originale , senza che mi debba preoccupare di configurare tabelle di differenze e di unire tutte queste cose insieme.