Stocker des données dans MySQL en JSON

Question

Je pensais que c'était un n00b chose à faire, et donc je ne l'ai jamais fait que j'ai vu que FriendFeed fait et fait fait de leur échelle de DB de mieux et une diminution de la latence. Je suis curieux de savoir si je dois faire cela et si oui, quelle est la bonne façon de le faire?

Fondamentalement, ce qui est un bon endroit pour apprendre comment stocker le tout dans MySQL comme un couchDB sorte de DB. Le stockage de tout ce que JSON semble qu'il serait plus simple et plus rapide (pas de construire, moins de latence).

Aussi, est-il facile de modifier/supprimer/etc choses stockées sous forme de JSON sur la DB?

Answer 1

Tout le monde en commentant semble être à venir à ce à partir d'un mauvais angle, c'est bien pour stocker du code JSON via PHP dans un monde relationnel et il va en fait être plus rapide à charger et afficher des données complexes comme ceci, cependant, vous aurez des considérations de conception telles que la recherche, l'indexation, etc.

La meilleure façon de le faire est d'utiliser hybride de données, par exemple si vous avez besoin de faire une recherche basée sur datetime de MySQL (la performance à l'écoute) va être beaucoup plus rapide que PHP et pour quelque chose comme la recherche de la distance des lieux de MySQL devrait également être beaucoup plus rapide (avis de recherche de ne pas l'accès). Les données que vous n'avez pas besoin de faire une recherche sur peut alors être stocké dans JSON, BLOB ou tout autre format que vous vraiment le jugent nécessaire.

Données dont vous avez besoin pour accéder très facilement stockées sous forme de JSON par exemple une base de cas par cas la facture du système. Ils ne bénéficient que très peu de SGBDR, et peut être stocké dans JSON juste par json_encoding($_POST['entrées']) si vous avez le bon formulaire HTML structure.

Je suis heureux que vous êtes heureux à l'aide de MongoDB et j'espère qu'il continue à bien vous servir, mais ne pense pas que MySQL va toujours être hors de votre radar, comme votre application augmente en complexité, vous pourriez bien finir par avoir besoin d'un SGBDR pour certaines fonctionnalités et caractéristiques (même si c'est juste pour prendre sa retraite de données archivées ou business reporting)

Answer 2

CouchDB et MySQL sont deux choses très différentes bêtes. JSON est le natif de manière à stocker des choses dans CouchDB. Dans MySQL, le mieux que vous pourriez faire est de stocker les données JSON sous forme de texte dans un champ unique. Ce serait tout à fait à l'encontre du but de les stocker dans un SGBDR et compliquerait grandement toutes les transactions de base de données.

Ne le faites pas.

Cela dit, FriendFeed semble utiliser un extrêmement un schéma personnalisé sur le dessus de MySQL. Cela dépend vraiment de ce que vous souhaitez exactement magasin, il n'y a pas une réponse définitive sur la façon d'abuser d'un système de base de données de sorte qu'il fait sens pour vous. Étant donné que l'article est d'un an et demi d'existence et leur principale raison contre Mongo et le Canapé a été immaturité, je l'avais re-évaluer ces deux si MySQL ne coupe pas pour vous. Ils doivent avoir beaucoup grandi maintenant.

Answer 3

json personnages n'ont rien de spécial quand il s'agit de stockage, des caractères tels que

{,},[,],',a-z,0-9.... sont vraiment rien de spécial et peuvent être stockés en tant que texte.

le premier problème que vous allez avoir, c'est de cette

{ profile_id: 22, nom d'utilisateur: 'Robert', mot de passe: 'skhgeeht893htgn34ythg9er' }

que stockées dans une base de données n'est pas simple de mettre à jour, sauf si vous aviez votre propre procédure et a développé une jsondecode pour mysql

UPDATE users SET JSON(user_data,'username') = 'New User';

De sorte que vous ne pouvez pas faire cela, vous devez d'abord SÉLECTIONNER le json, de Décoder, de le modifier, de le mettre à jour, donc, en théorie, vous pourriez aussi bien passer plus de temps à construire un adaptées structure de base de données!

Je ne l'utilisation de json pour stocker des données, mais seuls les Méta-Données, les données qui n'obtiennent pas souvent mis à jour, non liées à l'utilisateur spécifique.. exemple, si un utilisateur ajoute un post, et, dans ce post, ajoute-t-il des images de mauvais analyser les images et de créer des vignettes, et ensuite utiliser le pouce url dans un format json.

Answer 4

Pour illustrer la difficulté d'obtenir des données JSON à l'aide d'une requête, je vais partager la requête que j'ai faite pour gérer cela.

Il ne prend pas en compte les tableaux ou autres objets, mais uniquement les types de données de base. Vous devez remplacer les 4 instances de colonne par le nom de colonne contenant le JSON et modifier les 4 instances de myfield par le champ JSON auquel vous souhaitez accéder.

 SELECT
    SUBSTRING(
        REPLACE(REPLACE(REPLACE(column, '{', ''), '}', ','), '"', ''),
        LOCATE(
            CONCAT('myfield', ':'),
            REPLACE(REPLACE(REPLACE(column, '{', ''), '}', ','), '"', '')
        ) + CHAR_LENGTH(CONCAT('myfield', ':')),
        LOCATE(
            ',',
            SUBSTRING(
                REPLACE(REPLACE(REPLACE(column, '{', ''), '}', ','), '"', ''),
                LOCATE(
                    CONCAT('myfield', ':'),
                    REPLACE(REPLACE(REPLACE(column, '{', ''), '}', ','), '"', '')
                ) + CHAR_LENGTH(CONCAT('myfield', ':'))
            )
        ) - 1
    )
    AS myfield
FROM mytable WHERE id = '3435'
 

Answer 5

Je dirais que les deux seules raisons à prendre en compte sont les suivantes:

• la performance n'est tout simplement pas assez bon avec une approche normalisée
• vous ne pouvez pas facilement le modèle de votre particulièrement fluide/flexible/modification des données

J'ai écrit un peu sur ma propre approche ici:

http://stackoverflow.com/questions/2285045/what-scalability-problems-have-you-solved-using-a-nosql-data-store/2316921#2316921

(voir le haut de réponse)

Même JSON n'était pas tout à fait assez vite, nous avons donc utilisé un format de texte approche. De travail continue à bien fonctionner pour nous.

Est-il une raison quelconque vous n'êtes pas en utilisant quelque chose comme MongoDB? (peut-être pour MySQL est "nécessaire"; juste curieux)