La réponse à toutes vos questions dépend vraiment de l'utilité des données JSON et de la nécessité ou non d'utiliser une propriété de ces données pour déterminer quelles lignes sont renvoyées.
Si vos données n'ont vraiment pas de schéma et que vous les utilisez simplement pour stocker des données qui seront utilisées par une application qui sait comment récupérer la ligne correcte selon d'autres critères (comme l'un des autres champs) à chaque fois, il n'y a aucune raison de le stocker autrement que exactement comme l'application l'attend (dans ce cas, JSON).
Si les données JSON contiennent une structure identique pour toutes les entrées, et s'il est utile d'interroger ces données directement à partir de la base de données, vous souhaiterez créer une ou plusieurs tables (ou peut-être juste quelques champs supplémentaires) pour contenir ces données .
À titre d'exemple pratique, si les champs de données contiennent des services d'énumération JSON pour cet utilisateur dans un tableau, et que chaque service a un identifiant, un type et un prix uniques, vous voudrez peut-être un tableau séparé avec les champs suivants (en utilisant votre propre nommage conventions):
serviceId (integer)
userName (string)
serviceType (string)
servicePrice (float)
Et chaque service pour cet utilisateur obtiendrait sa propre entrée. Vous pouvez alors interroger les utilisateurs disposant d'un service particulier, ce qui, selon vos besoins, peut s'avérer très utile. En plus de faciliter les requêtes, l'indexation de certains champs des tables séparées peut également permettre des requêtes très RAPIDES.
Mise à jour :sur la base de votre explication des données stockées et de la façon dont vous les utilisez, vous souhaitez probablement qu'elles soient normalisées. Quelque chose comme ce qui suit :
# user table
userId (integer, auto-incrementing)
userName (string)
userEmail (string)
password (string)
deviceID (string)
# note table
noteId (integer, auto-incrementing)
userId (integer, matches user.userId)
noteTime (datetime)
noteData (string, possibly split into separate fields depending on content, such as subject, etC)
# request table
requestId (integer, auto-incrementing)
userId (integer, matches user.userId)
requestTime (datetime)
requestData (string, again split as needed)
Vous pouvez alors interroger comme suit :
# Get a user
SELECT * FROM user WHERE userId = '123';
SELECT * FROM user WHERE userNAme = 'foo';
# Get all requests for a user
SELECT * FROM request WHERE userId = '123';
# Get a single request
SELECT * FROM request WHERE requestId = '325325';
# Get all notes for a user
SELECT * FROM note WHERE userId = '123';
# Get all notes from last week
SELECT * FROM note WHERE userId = '123' AND noteTime > CURDATE() - INTERVAL 1 WEEK;
# Add a note to user 123
INSERT INTO note (noteId, userId, noteData) VALUES (null, 123, 'This is a note');
Remarquez tout ce que vous pouvez faire de plus avec des données normalisées et à quel point c'est facile ? Il est facile de localiser, mettre à jour, ajouter ou supprimer un composant spécifique.
