2009-02-02 9 views
5

Sto memorizzando una stringa JSON nel database che rappresenta un insieme di proprietà. Nel codice sottostante, lo esporto e lo uso per alcune logiche personalizzate. Essenzialmente, lo sto usando solo come meccanismo di archiviazione. Capisco che XML sia più adatto per questo, ma ho letto che JSON è più veloce e preferito.JSON è utilizzato solo per JavaScript?

È consigliabile utilizzare JSON se l'intenzione non è quella di utilizzare la stringa sul lato client?

risposta

8

JSON è un modo perfettamente valido di archiviare dati strutturati e più semplice e più conciso di XML. Non penso che sia una "cattiva pratica" usarlo per la stessa ragione per cui qualcuno userebbe l'XML purché tu capisca e sia soddisfatto dei suoi limiti.

2

Sì, penso che JSON sia fantastico. È uno standard aperto e può essere utilizzato da qualsiasi linguaggio di programmazione. La maggior parte dei linguaggi di programmazione dispone di librerie per analizzare e codificare anche JSON.

5

Che si tratti di buone pratiche, non posso dirlo, ma mi sembra strano. Avere campi XML nel proprio database SQL sono quantomeno query (SQL Server 2000 o successivo, MySQL e altri) ma il più delle volte è l'ultima risorsa per i metadati.

JSON è di solito il vettore tra il JavaScript e il vostro back-end, non è l'archiviazione in sé a meno che non si dispone di un back-end JSON document orientated database come CouchDB o SOLR come JSON si presta perfettamente per la memorizzazione dei documenti.

Non dire che non sono d'accordo con l'utilizzo di JSON come serial serial di dati semplice (cioè non serializzazione dei riferimenti) su XML, ma non andrò in un rant JSON vs XML solo per il gusto di farlo:).

Se non si utilizza JSON per la sua portabilità tra 2 lingue, e si è certi che non si interrogheranno mai i dati da SQL, sarà meglio con la serializzazione predefinita di .NET.

0

JSON è più corto, quindi utilizzerà meno spazio nel database. probabilmente userei al posto di XML o scrivere il mio proprio formato.

D'altra parte, la ricerca di corrispondenze succhierà - si sta andando ad avere per usare "dove JSON come '% somevalue%'", che sarà dolorosamente lenti. Questa è la stessa limitazione con qualsiasi altra strategia di memorizzazione del testo (incluso xml).

2

JSON è solo un linguaggio di markup come XML e, a causa delle sue specifiche più restrittive, è di dimensioni più piccole e più veloce da generare e analizzare. Quindi da questo aspetto è perfettamente accettabile l'uso nel database se è necessario un markup strutturato ad-hoc (e si è assolutamente certi che l'utilizzo di tabelle non sia possibile e/o la soluzione migliore).

Tuttavia, non si dice quale database si sta utilizzando. Se è SQL Server 2005 o versioni successive, il database stesso dispone di funzionalità estese quando si ha a che fare con XML, incluso un tipo di dati XML, il supporto XQuery e la capacità di ottimizzare le espressioni XQuery come parte di un piano di esecuzione. Quindi, se questo fosse il caso, sarei molto più incline a usare XML e ad approfittare delle funzionalità del database.

4

Non sei l'unico ad usare JSON per la memorizzazione dei dati. CouchDB è un database orientato ai documenti che utilizza JSON per l'archiviazione delle informazioni. Inizialmente memorizzavano tali informazioni come XML, quindi passavano a JSON. La ricerca avviene tramite il buon vecchio HTTP.

A proposito, CouchDB ha ricevuto una certa attenzione ultimamente ed è sostenuta da IBM e la Apache Software Foundation. È scritto in Erlang e promette molto (IMHO).

1

Basta ricordare che JSON ha tutti gli stessi problemi che XML ha come archivio dati di back-end; vale a dire, non sostituisce in alcun modo un database relazionale o anche un formato binario di dimensioni fisse. Se hai milioni di righe e hai bisogno dell'accesso casuale, ti imbatterai in tutti gli stessi problemi di prestazioni fondamentali con JSON che faresti con XML. Dubito che tu abbia intenzione di usarlo per questo tipo di scenario dell'archivio dati, ma non si sa mai ... sono state provate cose estranee :)

-1

Non si deve usare JSON o XML per memorizzare i dati in un rapporto relazionale Banca dati. JSON e XML sono formati di serializzazione che sono utili per la memorizzazione di dati in file o l'invio su cavo.

Se si desidera memorizzare un set di proprietà, è sufficiente creare una tabella per esso, con ogni riga di una proprietà. In questo modo puoi interrogare i dati usando l'ordinario SQL.

+0

Lo memorizzo in un database quando so che l'oggetto non dovrà essere separato per essere interrogato. – Nosredna

+0

Esattamente - anche se non è ottimale, ci sono casi in cui si desidera archiviare dati strutturati che sono "atomici", cioè utilizzati solo come entità, non a pezzi. Se è così, sezionarlo a righe e colonne è solo sopra la testa. E mentre memorizzarli in RDBMS è di per sé uno spreco (gli archivi di chiavi/valore sarebbero migliori), potrebbe essere un'opzione decente se tutto ciò che si ha è un DB. – StaxMan

Problemi correlati