Quali sono gli svantaggi in un file di archiviazione dati JSON Server-Side-Side?

Question

Sto cercando metodi di archiviazione dati alternativi su SQL ( per dire, io faccio non desideri utilizzare SQL, anche per query ) e si è imbattuto in APochi basati su JSON.Parlando con gli amici che fanno il lavoro del database, hanno detto che non dovrei considerare questi, ma non sarebbe elaborato. Quali sono i potenziali (e pratici) inconvenienti per utilizzare JSON come formato di file di archiviazione dati?

---

.

Ho capito che Json sarebbe Better di SQL per questi motivi:

.
1. json è rigorosamente definito e non ha sapori (Oracle, Microsoft, MySQL, ecc.)
2. Poiché Google ha iniziato a fare Chrome, gli interpreti JS hanno reso lettura, analizzazione e che emettono JS (e quindi JSON) A molto Fast and Easy Process.
3. Database L'output potrebbe essere puro json , cancellando la necessità di un interprete di media uomo per i browser, ecc.

Tra gli altri ...

Answer 1

Penso che potresti voler dare un'occhiata a No-SQL Database: https://en.wikipedia.org/wiki/nosql

Se ti piace l'utilizzo di dati simili a JSON, allora uno che ho usato personalmente è mongolodb.

Non l'ho usato come fonte principale / singola dei miei dati dell'app, ma solo per scopi secondari. Ma immagino, puoi provare a usarlo come anche la tua archiviazione dei dati principali (penso che molte persone facciano).

Quello che ho provato, ed è stato abbastanza soddisfacente, è stato mongodb con C # e usando Mongovie come applicazione GUI per l'esecuzione di query e interazione con il DB. Non ero molto felice con Mongovie, ma sembra che fosse l'opzione migliore al momento.

Tuttavia, SQL DBS sono molto buoni per definire le relazioni nei tuoi dati. Per esempio. Fare riferimento a una voce sul tavolo A da una voce sulla Tabella B, e quel tipo di roba. Usando quelle relazioni, puoi unirti a tavoli e fare molte cose interessanti. Penso, è buono per te avere anche una certa esperienza su questo campo.

Mongodb non è costruito per definire le relazioni (per quanto ho capito). Ha il concetto di "Documenti", in cui si memorizzano le informazioni in un formato JSON simile (con chiave / valori nidificati). Puoi interrogare documenti, ma aderire a sembrare l'hacking sulla sua strada intorno al suo normale utilizzo: Come posso eseguire il SQL Iscriviti equivalente a MongoDB? Inoltre, garantendo la coerenza dei dati (in modo veramente affidabile) quando si utilizzano relazioni in Mongodb sembra piuttosto impossibile per me. Ma anche se ho torto ed è possibile, sarà 10 volte più difficile raggiungerlo rispetto a SQL DBS.

Ma puoi dare un'occhiata all'elenco in Wikipedia e potrebbe esserci un'alternativa migliore del mongolodb per te.

Ma puoi usare puro JSON pure senza sistema DB.

Quindi, in sintesi stoccaggio JSON-simile ha (almeno) questi problemi:

.
• non è buono per definire e utilizzare le relazioni
• Quando si utilizzano le relazioni, l'integrità dei dati (o più probabile, l'integrità di riferimento) è difficile.
• Se non si utilizza un buon sistema DB, ma è solo scaricare JSON in un file, quando quel file diventa troppo grande, avrai problemi di prestazioni. Immagina di interrogare una matrice codificata da 1 GB JSON di oggetti per ottenere quelli che vuoi. Dovrai caricare l'intero array sulla memoria, eseguirlo attraverso l'intero (dal momento che non avrai indici) e quindi (se non hai esaurito la memoria e la connessione: quando si utilizza una rete- non è scaduta) otterrà un risultato. La maggior parte dei DBS No-SQL come MongoDB e la maggior parte dei DBS SQL non hanno tali problemi (almeno entro quantità ragionevoli di dati). Sono sintonizzati, supportano indicizzazione, riferimenti, permessi, ruoli e puoi anche definire il codice di esecuzione a livello DB (come trigger e procedure memorizzate). Certamente sono più complessi, ma quella complessità potrebbe essere richiesta la maggior parte dei tempi per ottenere il risultato finale.

Answer 2

JSON o JavaScript Notation Object, è un formato standard aperto che utilizza il testo leggibile dall'uomo per trasmettere oggetti di dati costituiti da coppie di valore attribuiscano.Viene utilizzato principalmente per trasmettere dati tra un server e un'applicazione Web, come alternativa a XML.

Sei più guardando il confronto tra Database vs Archiviazione flat-file davvero. .

Answer 3

Anche quando si utilizza un DB relazionale, l'integrità dei dati (o l'integrità referenziale) è ancora difficile perché le righe sono, di solito, timestamped.Abbastanza spesso le chiavi straniere non sono applicate a causa di questo.Quando si verifica un aggiornamento della riga, hai 2 scelte.In primo luogo, "dimentica" la versione precedente.In secondo luogo, aggiorna la riga originale e copia la versione precedente in una tabella di cronologia "non relazionale" a tempo in cui i tasti estranei sono inutili.La maggior parte dei dati aziendali richiede aggiornamenti.Le caratteristiche per mantenere l'integrità referenziale nei database relazionali sono inutili per questo tipo di dati aziendali (che rappresenta la maggior parte dei dati aziendali). Ciò che è necessario è un database temporale o un livello di astrazione che presenta un utente con la versione appropriata di una riga in base a un contesto temporale.Idealmente in 2 dimensioni I.E. Tempo di transazione e tempo di attività (aka Valid Time).