La risposta a tutte le tue domande dipende davvero dall'utilità dei dati JSON e dalla necessità di utilizzare alcune proprietà di tali dati per determinare quali righe vengono restituite.
Se i tuoi dati non hanno davvero uno schema e li stai solo usando per archiviare i dati che verranno utilizzati da un'applicazione che sa come recuperare la riga corretta in base ad altri criteri (come uno degli altri campi) ogni volta, non c'è motivo per archiviarlo come qualcosa di diverso da esattamente come l'applicazione lo aspetta (in questo caso, JSON).
Se i dati JSON contengono una struttura che è la stessa per tutte le voci e se è utile interrogare questi dati direttamente dal database, ti consigliamo di creare una o più tabelle (o forse solo alcuni più campi) per contenere questi dati .
Come esempio pratico, se i campi dati contengono servizi di enumerazione JSON per quell'utente in un array e ogni servizio ha un ID, un tipo e un prezzo univoci, potresti volere una tabella separata con i seguenti campi (usando la tua denominazione convenzioni):
serviceId (integer)
userName (string)
serviceType (string)
servicePrice (float)
E ogni servizio per quell'utente otterrebbe la propria voce. Potresti quindi interrogare gli utenti che dispongono di un servizio particolare, che a seconda delle tue esigenze potrebbe essere molto utile. Oltre a eseguire facilmente query, l'indicizzazione di determinati campi di tabelle separate può anche rendere le query molto VELOCI.
Aggiornamento:in base alla tua spiegazione dei dati memorizzati e al modo in cui li usi, probabilmente vorrai che si normalizzassero. Qualcosa come il seguente:
# 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)
Potresti quindi interrogare in questo modo:
# 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');
Nota quanto puoi fare in più con i dati normalizzati e quanto è facile? È banale individuare, aggiornare, aggiungere o eliminare qualsiasi componente specifico.
