La respuesta a todas sus preguntas realmente depende de para qué son los datos JSON y si alguna vez necesitará usar alguna propiedad de esos datos para determinar qué filas se devuelven.
Si sus datos realmente no tienen un esquema, y realmente solo los está utilizando para almacenar datos que serán utilizados por una aplicación que sabe cómo recuperar la fila correcta según algún otro criterio (como uno de los otros campos) cada vez, no hay razón para almacenarlo como algo que no sea exactamente como lo espera la aplicación (en este caso, JSON).
Si los datos JSON SÍ contienen alguna estructura que es la misma para todas las entradas, y si es útil consultar estos datos directamente desde la base de datos, querrá crear una o más tablas (o tal vez solo algunos campos más) para contener estos datos .
Como ejemplo práctico de esto, si los campos de datos contienen servicios de enumeración JSON para ese usuario en una matriz, y cada servicio tiene una identificación, tipo y precio únicos, es posible que desee una tabla separada con los siguientes campos (usando su propio nombre convenciones):
serviceId (integer)
userName (string)
serviceType (string)
servicePrice (float)
Y cada servicio para ese usuario tendría su propia entrada. A continuación, podría consultar por los usuarios que tienen un servicio en particular, que dependiendo de sus necesidades, podría ser muy útil. Además de facilitar las consultas, la indexación de ciertos campos de las tablas separadas también puede generar consultas muy RÁPIDAS.
Actualización:según su explicación de los datos almacenados y la forma en que los usa, probablemente quiera que se normalicen. Algo como lo siguiente:
# 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)
Entonces podría consultar así:
# 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');
¿Observa cuánto más puede hacer con los datos normalizados y lo fácil que es? Es trivial ubicar, actualizar, agregar o eliminar cualquier componente específico.
