Utilizzo di un database relazionale vs oggetti JSON per dati di eventi / attività

Sto lavorando a un progetto in cui sto cercando di decidere se utilizzare un database relazionale SQL standard o oggetti JSON per archiviare dati su un evento o un'attività.

Il progetto memorizzerà i dati su più tipi di eventi, quindi ho deciso di descrivere un solo tipo di evento per questa domanda.

L'evento di musica dal vivo (descritto per intero utilizzando lo schema JSON in fondo a questa domanda) è un oggetto che memorizza dati come dove si svolgerà l'evento, l'ora / data dell'evento e il costo dell'evento. L'oggetto evento di musica dal vivo ha sia uno-a-uno (evento -> nome, evento -> descrizione) che uno-a-molti (evento -> luoghi, evento -> date, evento -> tipi di biglietti ) relazioni. Inoltre, l'oggetto evento può contenere uno o più ID performer, che si collegano all'oggetto performer. L'oggetto performer memorizza i dati sui musicisti che si esibiscono all'evento di musica dal vivo.

I dati verranno interrogati dagli utenti utilizzando sia semplici ("Trovami eventi con 'x' nome") che complessi ("Trovami eventi con il genere musicale 'x' e il costo di 'y' entro un raggio di 'z' dal mio attuale posizione "). I dati saranno inviati dagli utenti utilizzando un modulo web.

Come probabilmente puoi dire dallo schema JSON definito, inizialmente avrei usato gli oggetti JSON per archiviare questi dati, ma ho sentito da alcune persone che affermano che, poiché i miei dati sono puramente relazionali, dovrei attenermi ai metodi più vecchi.

Gradirei qualsiasi pensiero sui pro e contro di ogni approccio dato i miei bisogni. Se hai bisogno di chiarimenti, non esitare a chiedere.

{
    "event": {
        "eventID":{
            "type":"string"
        },  
        "eventType":{
            "type":"array",
            "eventTypeItem":{
                "type":"string"
            }
        },
        "eventName":{
            "type":"string"
        },      
        "eventDescription":{
            "type":"string"
        },
        "eventVenueList":{
            "type":"array",
            "eventVenueListID":{
                "type":"integer"
            }
        },
        "eventURL":{
            "type":"string"
        },
        "eventTwitter":{
            "type":"string"
        },
        "eventFB":{
            "type":"string"
        },
        "eventInstagram":{
            "type":"string"
        },
        "eventEmail":{
            "type":"string",
            "format":"email"
        },
        "eventContactPerson":{
            "type":"string"
        },
        "eventDoorTime": {
            "type":"string",
            "format":"date-time"
        },  
        "eventPerformerIDList":{
            "type":"array",
            "liveMusicPerformerID":{
                "type":"integer"
            }
        },  
        "eventSetList":{
            "type":"array",
            "eventPerformerID":{
                "type":"integer"
            },
            "eventPerformerStartTime":{
                "type":"string",
                "format":"date-time"
            },
            "eventPerformerEndTime":{
                "type":"string",
                "format":"date-time"
            }                                   
        },
        "eventDateList": {
            "type":"array",
            "eventDateItem": {
                "type":"string",
                "format":"date-time"
            }   
        },
        "eventDateStartTime": {
            "type":"string",
            "format":"date-time"
        },
        "eventDateEndTime": {
            "type":"string",
            "format":"date-time"
        },
        "eventTicket":{ 
            "type":"array",
            "eventTicketType":{
                "type":"string" 
            },
            "eventTicketLowPrice":{
                "type":"number"
            },
            "eventTicketHighPrice":{
                "type":"number" 
            },
            "eventDatesAdvancePrice": {
                "type":"number"
            }   
        }
    },  
    "performer": {
        "performerID": {
            "type":"integer"
        },
        "performerType": {
            "type":"string"
        },
        "performerName": {
            "type":"string"
        },
        "performerAlternateName": {
            "type":"array",
            "performerAlterateNameItem":{
                "type":"string"
            }
        },
        "performerGenreList": {
            "type":"array",
            "performerGenreItem":{
                "type":"string"
            }
        },
        "performerURL": {
            "type":"string"
        }                                       
    }
}   

Penso che la tua domanda si riduca davvero a: quando dovrei usare un approccio NoSQL rispetto a RDBMS? Hai optato per JSON in anticipo (una decisione NoSQL), forse perché hai consumatori Ajax.

La risposta ovviamente a quando utilizzare gli approcci NoSQL rispetto a quelli di RDBMS è fondamentalmente su quale tipo di dati con cui stai lavorando e quali consumatori prevedi di avere. Se i tuoi dati sono essenzialmente relazionali (gerarchie piuttosto piatte, nessun tipo di dato strano come immagini o audio, relazioni prevedibili tra gli schemi che possono essere facilmente descritti nelle chiavi) e si prevede che i tuoi consumatori includeranno eventualmente persone che desiderano fare query di Business Intelligence (query ad hoc), quindi un RDBMS è la strada da percorrere. È abbastanza facile trasformare una query in una rappresentazione JSON, quindi non grava in modo significativo sui consumatori Ajax - aggiunge semplicemente una piccola codifica di trasformazione nei tuoi endpoint (REST / SOAP / qualunque cosa). al contrario, se i tuoi dati sono molto gerarchici (schemi profondi), contengono tipi di dati strani come immagini, audio, video, ecc., ci sono poche relazioni tra entità e sai che gli utenti finali non eseguiranno la BI, quindi NoSQL / memorizzazione JSON potrebbe essere appropriato.

Naturalmente, anche queste linee guida generali non sono solide. Il motivo per cui Google ha sviluppato Google File System, MapReduce (lavoro che è stato utilizzato da Doug Cutting per costruire Hadoop in Yahoo) e successivamente BigQuery (un modo [schematico] orientato a NoSQL per la gestione di dati su larga scala) era proprio perché avevano un sacco di ad hoc Le richieste della BI non sono riuscite a ottenere approcci relazionali per scalare le scale tera / peta / exa / zetta / yotta che stavano cercando di gestire. L'unico approccio pratico consisteva nel ridimensionare, sacrificando un po 'di facilità d'uso delle query ad hoc fornite da un RDBMS e sostituendo un semplice algoritmo (MapReduce) che poteva essere codificato abbastanza facilmente per una determinata query.

Dato il tuo schema sopra, la mia domanda sarebbe sostanzialmente: perché non dovresti usare un RDBMS? Non vedo molte ragioni per non farlo. La nostra professione dovrebbe essere orientata all'ingegneria, non alla moda, quindi il nostro istinto dovrebbe essere quello di scegliere la soluzione più semplice che funzioni, giusto? Voglio dire, i tuoi endpoint potrebbero dover fare una piccola traduzione se i tuoi consumatori sono Ajaxy, ma i tuoi dati sembrano molto piatti e sembra probabile che gli utenti aziendali vogliano fare tutti i tipi di query ad hoc su cose come eventi musicali (che L'evento è stato più frequentato entro 50 miglia dalla nostra capitale l'anno scorso?)

"Non andare dagli elfi per un consiglio, perché diranno sia no che sì."- Frodo

Credo che qui ci siano più considerazioni che potresti non cercare. Ci sono due grandi preoccupazioni qui:

• Conservazione
• Cerca e recupera

Conservazione

Ci sono molte opinioni sul perché usare l'archivio no-sql o RDBMS per i tuoi dati. Uno degli elementi più importanti che riteniamo utili è che possiamo facilmente definire e archiviare oggetti json in memoria senza doversi preoccupare di definirne la struttura completa o la relazione tra diversi tipi di oggetti. Alcuni degli altri motivi per utilizzare un db NoSql potrebbero essere la capacità di frammentare automaticamente i dati, le ricerche basate sulla posizione e la facile manutenzione. Esistono molti buoni database NoSql, la mia preferenza personale è MongoDB. Tuttavia, se non hai mai usato il database NoSql in precedenza, c'è una curva di apprendimento definita mentre impari a ricablare la tua mente. La maggior parte di noi utilizza RDBMS da un po 'di tempo e ci vuole uno sforzo consapevole per uscire da quell'abitudine. Inoltre, ti ritroverai a voler rifare il tuo modello di dati man mano che procedi insieme ai tuoi sforzi e hai una migliore comprensione dei concetti. Se la capacità di refactoring o rimodellare non è un'opzione per il tuo progetto, suggerirei di attenersi a ciò che già conosci meglio.

Ricerca

Se intendi fornire qualsiasi tipo di ricerca utilizzabile, ti consiglio vivamente di utilizzare un motore di ricerca di testo dedicato come SOLR per eseguire le tue ricerche. Le ricerche di testo sono lente e se hai più frammenti allora ancora più lentamente. SOLR supporta ricerche di testo incredibilmente veloci tra cui parametri di ricerca ponderati, ricerche basate sulla posizione e molto altro. SOLR tuttavia non è adatto come archivio principale dei tuoi dati. Ciò significa che durante l'aggiunta o l'aggiornamento degli eventi sarà necessario creare meccanismi per il doppio inserimento e l'aggiornamento sia del database primario sia del livello SOLR. Inoltre dovrai aggiornare il SOLR in seguito rimuovendo eventuali eventi obsoleti / terminati.

Anche se questo sembra un sacco di lavoro extra, ti ringrazierai per la lungimiranza di utilizzare un motore di ricerca a testo completo in seguito. Nessuno dei database NoSql o RDBMS si avvicina alle prestazioni e all'agilità di SOLR / Lucene.

Innanzitutto, se stai cercando di archiviare i dati JSON in qualsiasi archivio ma non in un database NoSQL , ti scoraggerei sicuramente dall'utilizzare JSON. Il motivo è che se, ad esempio, memorizzi i tuoi dati come file JSON, sarà estremamente lento aprirli, analizzarli, eseguirne il ciclo, ecc.

Detto questo, posso restringere la tua domanda a: quali sono i pro e i contro di NoSQL e RDBMS ?Ed è già stato risposto migliaia di volte in rete.

Riguardo al tuo progetto, puoi ovviamente usare NoSQL o RDBMS ; Tuttavia, ciò che posso generalmente consigliarti è pensare fuori dagli schemi e cercare gli altri fattori meno visibili che potrebbero aiutarti a decidere tra le due opzioni. Prova a vedere quale opzione potrebbe accelerare lo sviluppo? Quale è più adatto per gli altri membri del team - se non sei un unico sviluppatore. Se lo stai vendendo, quale è più economico, più facile e generalmente più adatto ai tuoi clienti non sviluppatori?

In questo modo puoi finalmente decidere quale strada fare, altrimenti sarà davvero difficile decidere in base alle informazioni fornite in quanto entrambe le opzioni potrebbero adattarsi abbastanza bene.

Nella maggior parte delle applicazioni ci sono requisiti per

1. Immettere i dati, eseguire alcune elaborazioni, salvare i dati, recuperare i dati e interrogarli. Potrebbe inoltre essere necessario generare report sui dati.
2. Scambiare dati tra diverse parti del sistema o con sistemi esterni

Al fine di soddisfare i requisiti per l'articolo 1 è necessario un metodo di persistenza dei dati. In genere se il volume di dati è molto piccolo e il tipo di dati è semplice e non richiede ampie capacità di ricerca, è possibile utilizzare una struttura di file semplice. Man mano che i dati diventano più complessi, è possibile utilizzare una struttura XML (o persino JSON) con i dati ancora memorizzati nei file. La ricerca però diventa più problematica. All'aumentare del volume di dati e all'aumentare della complessità delle ricerche, viene normalmente selezionato un database che fornisce metodi standard di settore per la persistenza, la query dei dati, ecc. I database possono essere progettati per gestire grandi volumi di dati e archiviare, recuperare e cercare i dati in modo rapido ed efficiente .

Al fine di soddisfare i requisiti per l'articolo 2, esistono diversi metodi per consentire lo scambio di dati tra sistemi tra cui XML, JSON ecc.

Questi metodi consentono di definire la struttura dei dati da parte di un utente e sono indipendenti dalla lingua consentendo al sistema diverso di scambiare dati.

Nel tuo caso particolare stai usando correttamente JSON sta descrivendo una serie di eventi musicali. Sebbene sia possibile archiviare i dati in formato JSON, la ricerca di questi dati man mano che il numero di eventi musicali aumenta sarà lenta e inefficiente.

Utilizzando un approccio di separazione delle preoccupazioni, un approccio migliore consiste nel raccogliere i dati, archiviarli in un database, eseguire la query in base all'input dell'utente nel database e quindi restituire i risultati in formato JSON sul lato client per visualizzare i dati.

Un ulteriore problema con l'approccio JSON è la modifica della struttura dei dati. Attualmente la tua struttura è relativamente semplice. È possibile utilizzare questa struttura per diversi mesi e quindi viene identificato un campo aggiuntivo. Cosa fai allora con tutti i tuoi oggetti JSON esistenti? L'aggiornamento di questi sarebbe problematico.

Se hai utilizzato un database, l'aggiunta di un campo aggiuntivo è relativamente semplice e solo il tuo codice per generare il JSON dovrebbe essere modificato in un unico posto, offrendoti così tutto il nuovo JSON con il nuovo campo.

In breve ogni componente tecnologico per ciò che è stato progettato per JSON per lo scambio di dati e un database per la persistenza dei dati.

Penso che avrai un successo migliore con l'utilizzo di NoSQL rispetto a SQL per la memorizzazione di questi dati, a causa delle domande che devi fare.

Anche solo perché alcuni dati sono puramente relazionali non significa più, devono essere persistiti in alcuni RDBMS (SQL). I dati relazionali dell'IMO si traducono meglio in banche dati grafiche.

Ovviamente puoi anche scrivere le query in SQL ma le prestazioni saranno terribili a causa del numero di join che dovrai avere (considerando che i tuoi dati saranno in qualche modo normalizzati e non tutti in una tabella degli eventi).

Ma in conclusione avrai più libertà usando NoSQL (quindi JSON o qualche altro formato supportato dal database) considerando che puoi modificare il tuo schema in futuro senza tener conto dei dati già persistenti.

Considerando NoSQL, potresti anche esaminare i database dei grafici se prevedi di utilizzare query molto complesse, dal momento che ti offriranno vantaggi nel crearle facilmente e anche eseguirle molto velocemente.

Penso che dovresti usare entrambi e non la vedo come una decisione "contro".

Un database relazionale ha senso per l'archiviazione e il recupero rapidi ed efficienti di dati con proprietà relazionali.

JSON è un formato di dati eccezionale perché è semplice, leggero e ideale per il trasferimento di dati non elaborati in un formato molto semplice con una sintassi adatta alla memorizzazione e allo scambio di informazioni di testo. È ottimo per trasferire piccole quantità di dati tra un browser e un server. Non è in un formato così facile da iniziare a utilizzare per query di dati di tipo relazionale.

Quindi consiglierei SQL per l'archiviazione dei dati e JSON per il formato di trasporto dei dati.

È vero che non ci sono opzioni di valore-chiave noSQL come Mongo, Redis, ecc. Questi avrebbero il vantaggio di una mappatura forse più semplice sul formato JSON, ma sono generalmente un po 'più difficili da usare per le query. Il principale ostacolo con loro è la mancanza di familiarità da parte della comunità IT generale, soprattutto se confrontata con SQL, che è così noto e ha una vasta gamma di risorse e conoscenze disponibili per quasi ogni situazione immaginabile.