Est-il sage de stocker une grosse morceau de JSON sur une ligne de base de données
J'ai ce projet qui stocke des détails sur les produits d'Amazon dans la base de données.
Juste pour vous donner une idée de la taille:
[{"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":""}]
Donc, la structure de la table est la suivante:
- un péché
- titre
- détails (les détails du produit dans JSON)
La performance souffrira-t-elle si je dois stocker comme 10 000 produits? Y a-t-il une autre façon de faire cela? Je pense à ce qui suit, mais la configuration actuelle est vraiment la plus commode puisque je dois également utiliser les données du côté du client:
- stockez les détails du produit dans un fichier. Alors quelque chose comme asin123.json
- stockez les détails du produit dans un grand fichier. (Je suppose que ce sera une traînée pour extraire des données de ce fichier)
- conservez chacun des champs dans les détails de son propre champ de table
Merci d'avance!
MISE À JOUR
Merci pour les réponses! Je veux juste ajouter quelques détails supplémentaires à ma question. Premièrement, les enregistrements sont mis à jour pour un intervalle spécifique. Seules des données spécifiques telles que le prix ou le titre sont mises à jour.
Deuxièmement, j'utilise également les données codées JSON au côté client, donc je pensais au début, il serait plus facile de l'avoir codé JSON afin que je puisse facilement l'utiliser de côté client sans avoir à convertir. Cela change-t-il votre opinion sur simplement stocker les champs dans un champ de table régulier dans une configuration de la SGBDM?
La taille n'est pas une quantité d'un problème, la possibilité d'interroger et de maintenir les données cependant est.
Si, par exemple, Greenhaven Press décide qu'ils veulent changer de nom à Greenhaven Press International, vous devrez trouver le disque, le désérialiser, le changer, le sérialiser, la pompier dans la base de données.
Considérez ceci: stocke ces objets comme des données sérialisées vous offrent une valeur claire valeur ajoutée sur le stockage sous une forme relationnelle? Si la réponse est non, cela ne vaut peut-être pas le problème.
MISE À JOUR
En ce qui concerne votre mise à jour de votre question: je suis enclin à dire non, cela rend peu ou pas de différence. Que vous mettez à jour un champ ou que tous dans cette chaîne JSON ne soit pas pertinent, car tout le processus est identique.
N'oubliez pas que vos besoins pourraient changer; Même si vous utilisez JSON du côté du client maintenant ne signifie pas que vous aurez besoin de JSON à l'avenir. Le stockage de vos données de manière relationnelle garantit une indépendance technologique tout en préservant les relations, les contraintes de données et les métadonnées requéres: c'est là que la valeur réelle d'un dB relationnel réside. Jeter ces avantages ne vous donnera ni un gain de performance, ni rendre votre application plus évolutive ou flexible.
Est-il sage de stocker une grosse morceau de JSON sur une ligne de base de données?
Non, généralement c'est une mauvaise idée de stocker des données multi-appréciations dans une cellule d'une base de données relationnelle, car elle va à l'encontre de la structure/des règles de base des SGDBR (comme mentionné dans l'autre réponse).
Cependant, vous pouvez examiner la possibilité d'utiliser l'une des bases de données non relationnelles (no-SQL), telles que MongoDB, qui vous aidera à stocker des objets JSON et à rechercher des données à l'intérieur de ces objets.
En supposant que vous n'ayez pas besoin d'intervenir sur ces terrains JSON, il n'ya rien de mal à cette approche, tant que le succès de la performance de désérialisement/sérialisement n'est pas un problème pour votre programme.
Plus tard, disons que l'exigence est comprise entre commande/filtre en fonction de ce champ "Sales_Rank" JSON. Vous écririez un programme pour exécuter les données et désherialiser l'objet, copiant ce champ à une colonne dédiée dans la table, qui serait alors indexée. Vous aurez besoin d'une routine de sérialisation/mise à jour personnalisée pour vous assurer de conserver cette colonne discrète conservée en synchronisation avec l'objet JSON, mais ce n'est pas difficile.
Ce type d'approche hybride peut être très utile lorsque vous déterminez toujours la fonctionnalité de l'application, car vous obtenez la vitesse de développement rapide de NOSQL, avec l'avantage de la modélisation relationnelle pour les champs qui en ont besoin.
Il est parfois préférable d'être mieux adapté à l'application de stocker un document complet comme une entité. Ce n'est pas une coïncidence que les bases de données NOSQL et Document sont à la hausse.
Si vous connaissez les inconvénients, cela peut être une approche OK, mais vous devez également envisager une réelle base de données de documents au lieu d'inventer votre choix.
SQL Server 2016 vous permet également de stocker JSON et de le traiter, presque comme tous les dbs NOSQL. Je suis toujours d'accord avec la plupart des gens là-bas que l'approche SMDBMS est probablement la meilleure voie et vous donne la plus grande flexibilité.
Avec l'approche SQL Server 2016 JSON, je ne sais pas combien de puissance il a (édition, suppressions; Je sais que vous pouvez rechercher des champs/propriétés dans les lignes JSON) mais sa option qui mérite d'être examinée.