È consigliabile archiviare un grosso pezzo di json su una riga del database

6

Ho questo progetto che memorizza i dettagli del prodotto da Amazon nel database.

Solo per darti un'idea di quanto sia grande:

[{"title":"Genetic Engineering (Opposing Viewpoints)","short_title":"Genetic Engineering ...","brand":"","condition":"","sales_rank":"7171426","binding":"Book","item_detail_url":"http://localhost/wordpress/product/?asin=0737705124","node_list":"Books > Science & Math > Biological Sciences > Biotechnology","node_category":"Books","subcat":"","model_number":"","item_url":"http://localhost/wordpress/wp-content/ecom-plugin-redirects/ecom_redirector.php?id=128","details_url":"http://localhost/wordpress/product/?asin=0737705124","large_image":"http://localhost/wordpress/wp-content/plugins/ecom/img/large-notfound.png","medium_image":"http://localhost/wordpress/wp-content/plugins/ecom/img/medium-notfound.png","small_image":"http://localhost/wordpress/wp-content/plugins/ecom/img/small-notfound.png","thumbnail_image":"http://localhost/wordpress/wp-content/plugins/ecom/img/thumbnail-notfound.png","tiny_img":"http://localhost/wordpress/wp-content/plugins/ecom/img/tiny-notfound.png","swatch_img":"http://localhost/wordpress/wp-content/plugins/ecom/img/swatch-notfound.png","total_images":"6","amount":"33.70","currency":"$","long_currency":"USD","price":"$33.70","price_type":"List Price","show_price_type":"0","stars_url":"","product_review":"","rating":"","yellow_star_class":"","white_star_class":"","rating_text":" of 5","reviews_url":"","review_label":"","reviews_label":"Read all ","review_count":"","create_review_url":"http://localhost/wordpress/wp-content/ecom-plugin-redirects/ecom_redirector.php?id=132","create_review_label":"Write a review","buy_url":"http://localhost/wordpress/wp-content/ecom-plugin-redirects/ecom_redirector.php?id=19186","add_to_cart_action":"http://localhost/wordpress/wp-content/ecom-plugin-redirects/add_to_cart.php","asin":"0737705124","status":"Only 7 left in stock.","snippet_condition":"in_stock","status_class":"ninstck","customer_images":["http://localhost/wordpress/wp-content/uploads/2013/10/ecom_images/51M2vvFvs2BL.jpg","http://localhost/wordpress/wp-content/uploads/2013/10/ecom_images/31FIM-YIUrL.jpg","http://localhost/wordpress/wp-content/uploads/2013/10/ecom_images/51M2vvFvs2BL.jpg","http://localhost/wordpress/wp-content/uploads/2013/10/ecom_images/51M2vvFvs2BL.jpg"],"disclaimer":"","item_attributes":[{"attr":"Author","value":"Greenhaven Press"},{"attr":"Binding","value":"Hardcover"},{"attr":"EAN","value":"9780737705126"},{"attr":"Edition","value":"1"},{"attr":"ISBN","value":"0737705124"},{"attr":"Label","value":"Greenhaven Press"},{"attr":"Manufacturer","value":"Greenhaven Press"},{"attr":"NumberOfItems","value":"1"},{"attr":"NumberOfPages","value":"224"},{"attr":"ProductGroup","value":"Book"},{"attr":"ProductTypeName","value":"ABIS_BOOK"},{"attr":"PublicationDate","value":"2000-06"},{"attr":"Publisher","value":"Greenhaven Press"},{"attr":"SKU","value":"G0737705124I2N00"},{"attr":"Studio","value":"Greenhaven Press"},{"attr":"Title","value":"Genetic Engineering (Opposing Viewpoints)"}],"customer_review_url":"http://localhost/wordpress/wp-content/ecom-customer-reviews/0737705124.html","flickr_results":["http://localhost/wordpress/wp-content/uploads/2013/10/ecom_images/5105560852_06c7d06f14_m.jpg"],"freebase_text":"No around the web data available yet","freebase_image":"http://localhost/wordpress/wp-content/plugins/ecom/img/freebase-notfound.jpg","ebay_related_items":[{"title":"Genetic Engineering (Introducing Issues With Opposing Viewpoints), , Good Book","image":"http://localhost/wordpress/wp-content/uploads/2013/10/ecom_images/140.jpg","url":"http://localhost/wordpress/wp-content/ecom-plugin-redirects/ecom_redirector.php?id=12165","currency_id":"$","current_price":"26.2"},{"title":"Genetic Engineering Opposing Viewpoints by DAVID BENDER - 1964 Hardcover","image":"http://localhost/wordpress/wp-content/uploads/2013/10/ecom_images/140.jpg","url":"http://localhost/wordpress/wp-content/ecom-plugin-redirects/ecom_redirector.php?id=130","currency_id":"AUD","current_price":"11.99"}],"no_follow":"rel=\"nofollow\"","new_tab":"target=\"_blank\"","related_products":[],"super_saver_shipping":"","shipping_availability":"","total_offers":"7","added_to_cart":""}]

Quindi la struttura per la tabella è:

  • ASIN
  • titolo
  • dettagli (i dettagli del prodotto in json)

La performance risentirà se dovrò memorizzare come 10.000 prodotti? C'è un altro modo per farlo? Sto pensando a quanto segue, ma l'attuale configurazione è davvero la più comoda in quanto devo anche usare i dati sul lato client:

  • memorizza i dettagli del prodotto in un file. Quindi qualcosa come ASIN123.json
  • memorizza i dettagli del prodotto in un unico grande file. (Immagino che sarà un trascinamento per estrarre i dati da questo file)
  • memorizza ciascuno dei campi nei dettagli nel proprio campo della tabella

Grazie in anticipo!

Aggiorna

Grazie per le risposte! Voglio solo aggiungere qualche altro dettaglio alla mia domanda. Innanzitutto, i record vengono aggiornati per un intervallo specifico. Vengono aggiornati solo dati specifici come il prezzo o il titolo.

In secondo luogo, sto anche utilizzando i dati json codificati sul lato client, quindi ho pensato che inizialmente sarebbe stato più semplice avere JSON codificato in modo da poterlo facilmente utilizzare sul lato client senza dover convertire. Questo cambia la tua opinione circa la semplice memorizzazione dei campi in un normale campo di tabella in un'impostazione RDBMS?

    
posta Wern Ancheta 24.10.2013 - 09:52
fonte

4 risposte

25

La dimensione non è tanto un problema, tuttavia la possibilità di interrogare e gestire i dati è.

Se, ad esempio, Greenhaven Press decide di voler cambiare il proprio nome in Greenhaven Press International, dovrà trovare il record, deserializzarlo, cambiarlo, serializzarlo, rimetterlo nel database.

Considera questo: la memorizzazione di questi oggetti come dati serializzati offre un chiaro valore aggiunto rispetto alla memorizzazione in forma relazionale? Se la risposta è no, allora potrebbe non valere la pena.

Aggiorna

Per quanto riguarda l'aggiornamento della tua domanda: sono incline a dire di no, fa poca o nessuna differenza. Se si aggiorna un campo o tutti in questa stringa json è irrilevante perché l'intero processo è identico.

Non dimenticare che i tuoi requisiti potrebbero cambiare; anche se stai usando json sul lato client ora non significa che avrai bisogno di JSON in futuro. Memorizzare i tuoi dati in una forma relazionale garantisce l'indipendenza dalla tecnologia preservando le relazioni, i vincoli sui dati e i metadati interrogabili: è qui che risiede il vero valore di un db relazionale. Scartare questi vantaggi non ti darà un vantaggio in termini di prestazioni né renderà la tua applicazione più scalabile o flessibile.

    
risposta data 24.10.2013 - 10:10
fonte
5

Is it wise to store a big lump of json on a database row?

No, in genere è una cattiva idea memorizzare dati multivalore in una cella di un database relazionale perché va contro la struttura / le regole di base di RDBMS (come menzionato nell'altra risposta).

Tuttavia, è possibile esaminare la possibilità di utilizzare uno dei database non relazionali (no-sql), come MongoDB, che consente di memorizzare oggetti JSON e cercare dati all'interno di tali oggetti.

    
risposta data 24.10.2013 - 14:08
fonte
3

Supponendo che non hai una necessità immediata di interrogare su quei campi JSON, allora non c'è niente di sbagliato in questo approccio, a patto che il successo di deserializzazione / serializzazione delle prestazioni non sia un problema per il tuo programma.

Più avanti, diciamo che il requisito arriva per ordinare / filtrare in base a quel campo JSON "sales_rank". Scriveresti un programma per eseguire i dati e deserializzare l'oggetto, copiando quel campo su una colonna dedicata nella tabella, che verrebbe quindi indicizzata. Avrai bisogno di una routine di serializzazione / aggiornamento personalizzata per assicurarti di mantenere questa colonna discreta mantenuta sincronizzata con l'oggetto JSON, ma non è difficile.

Questo tipo di approccio ibrido può essere molto utile quando si sta ancora cercando di capire le funzionalità dell'app, poiché si ottiene la rapida velocità di sviluppo di NoSQL, con il vantaggio della modellazione relazionale per i campi che ne hanno bisogno.

    
risposta data 25.09.2015 - 14:49
fonte
1

A volte è meglio adattarsi all'applicazione per archiviare un documento completo come un'unica entità. Non è una coincidenza che i database di nosql e di documenti siano in aumento.

Se sei a conoscenza degli svantaggi, può essere un buon approccio, ma dovresti anche prendere in considerazione un vero database di documenti invece di inventarne uno tuo.

    
risposta data 25.09.2015 - 07:40
fonte

Leggi altre domande sui tag