Sto sviluppando un generatore di moduli e mi chiedevo se sarebbe stato male mojo archiviare JSON in un database SQL?Memorizzazione di JSON in un database msSQL?
voglio mantenere il mio database & tavoli semplice, così mi stavo per avere
`pKey, formTitle, formJSON`
su un tavolo, e quindi memorizzare
{["firstName":{"required":"true","type":"text"},"lastName":{"required":"true","type":"text"}}
in formJSON.
Qualsiasi input è apprezzato.
Uso intensamente JSON nel mio CMS (che ospita circa 110 siti) e trovo la velocità dei dati di accesso molto veloce. Sono rimasto sorpreso dal fatto che non ci fosse più degrado della velocità. Ogni oggetto nel CMS (pagina, layout, elenco, argomento, ecc.) Ha una colonna NVARCHAR (MAX) chiamata JSONConfiguration. Il mio strumento ORM sa cercare quella colonna e ricostituirla come oggetto se necessario. Oppure, a seconda della situazione, lo passerò al client solo per jQuery o Ext JS da elaborare.
Per quanto riguarda la leggibilità/manutenibilità del mio codice, si potrebbe dire che è migliorato perché ora ho classi che rappresentano molti degli oggetti JSON memorizzati nel DB.
Ho usato JSON.net per tutte le serializzazioni/deserializzazione. http://james.newtonking.com/default.aspx
Uso anche una singola query per restituire meta-JSON con i dati effettivi. Come nel caso di Ext JS, ho delle query che restituiscono sia la struttura dell'oggetto Ext JS che i dati di cui l'oggetto avrà bisogno. Questo taglia un back-round post/back SQL.
Sono stato anche sorpreso dalla velocità con cui il codice è stato in grado di analizzare un elenco di oggetti JSON e mapparli in un oggetto DataTable che ho poi passato a GridView.
L'unico svantaggio che ho visto usando JSON è l'indicizzazione. Se hai una proprietà del JSON che devi cercare, devi salvarla come colonna separata.
Ci sono JSON DB là fuori che potrebbero soddisfare meglio le vostre esigenze: CouchDB, MongoDB e Cassandra.
Sarà più lento del modulo definito nel codice, ma una query aggiuntiva non dovrebbe causare molto danno. (Non lasciare che 1 query aggiuntiva diventi 10 query aggiuntive!)
Modifica: Se si seleziona la riga per formTitle anziché pKey (perché, in tal caso, il codice sarà più leggibile), inserire un indice su formTitle
Non lo consiglio.
Se si desidera eseguire in futuro qualsiasi rapporto o query in base a questi valori, la vita sarà molto più difficile rispetto ad alcune tabelle/colonne aggiuntive.
Perché stai evitando di creare nuovi tavoli? Dico che se la tua applicazione richiede loro di andare avanti e aggiungerli a loro ... Anche se qualcuno deve passare attraverso il tuo codice/db più tardi sarà probabilmente più difficile per loro capire cosa hai fatto (a seconda del tipo di documentazione che hai).
Un modo brillante per creare un database di oggetti da SQL Server.Lo faccio per tutti gli oggetti di configurazione e per tutto il resto che non richiede alcuna query specifica. estendere il tuo oggetto - facile, basta creare una nuova proprietà nella classe e avviare con il valore predefinito. Non hai più bisogno di una proprietà? Basta cancellarlo nella classe. Facile estrazione, facile aggiornamento. Non adatto a tutti gli oggetti, ma se estrai qualsiasi oggetto di scena devi indicizzarlo, continua a utilizzarlo. Modo molto moderno di usare il server sql.
Mi sono imbattuto in molte occasioni in cui sto cercando una soluzione e trovo la mia strada qui. Nella ricerca della soluzione, a volte trovo una risposta migliore altrove e forse con una tecnologia più nuova di quella a cui è stato risposto in quel momento. Non è solo per rispondere alla tua domanda, ma per tutti coloro che si trovano nella stessa situazione in cui ti trovi in futuro. E come KOPEHb, sarò abbastanza cortese da aggiornare o persino fornire soluzioni migliori di quelle a cui ho risposto. – Levitikon
Dovresti essere in grado di utilizzare SisoDb per questo. http://sisodb.com
Qualcuno ha qualche opinione dopo aver usato SisoDB? Sembra promettente, ma questo tipo di libreria può davvero essere azzeccato se usato in pratica ... –
Ciao, sono di parte da quando costruisco SisoDB ma lo stiamo usando in un prodotto commerciale in fase di sviluppo oggi. Viene utilizzato per il mantenimento di modelli di lettura in un ambiente CQRS. – Daniel
Abbiamo utilizzato una versione modificata di XML esattamente per lo scopo che decidi per sette o otto anni e funziona benissimo. Le esigenze di forma dei nostri clienti sono così diverse che non potremmo mai tenere il passo con un approccio da tavolo/colonna. Siamo troppo lontani dalla strada XML per cambiare molto facilmente, ma penso che JSON avrebbe funzionato bene e forse potrebbe anche essere migliore.
La segnalazione non è un problema con un paio di buone funzioni di analisi e vorrei sfidare chiunque a trovare una differenza significativa nelle prestazioni tra i nostri rapporti/analisi e una soluzione tabella/colonna per questa esigenza.
Penso che non sia un'idea ottimale per archiviare dati oggetto in una stringa in SQL. Devi eseguire la trasformazione al di fuori di SQL per analizzarlo. Ciò presenta un problema di prestazioni e si perde la possibilità di utilizzare la funzionalità di analisi dei dati nativi SQL. Un modo migliore sarebbe quello di memorizzare JSON come un tipo di dati XML in SQL. In questo modo, si uccidono due piccioni con una fava: non è necessario creare un carico di merda di tabelle e ottenere comunque tutti i vantaggi di SQL per l'interrogazione nativa.
Spendiamo un sacco di tempo su moduli personalizzati, che in genere contengono le stesse informazioni, la maggior parte di tali informazioni viene memorizzato in solo 3-4 tavoli diversi. COSÌ, se potessi creare i moduli a livello di programmazione e inviarli nelle loro tabelle appropriate, risparmieremmo molto tempo di sviluppo in futuro. – JKirchartz
Penso che in quella situazione probabilmente starà bene. Come Michael dice che sarà solo una domanda in più. Ho pensato che stavi cercando di memorizzare i valori insieme alla struttura del modulo. –