A resposta para todas as suas perguntas realmente depende da finalidade dos dados JSON e se você precisará usar alguma propriedade desses dados para determinar quais linhas são retornadas.
Se seus dados realmente não tiverem esquema e você estiver apenas usando-o para armazenar dados que serão usados por um aplicativo que sabe como recuperar a linha correta por alguns outros critérios (como um dos outros campos) todas as vezes, não há razão para armazená-lo como algo que não seja exatamente como o aplicativo espera (neste caso, JSON).
Se os dados JSON contiverem alguma estrutura que seja a mesma para todas as entradas e se for útil consultar esses dados diretamente do banco de dados, convém criar uma ou mais tabelas (ou talvez apenas mais alguns campos) para armazenar esses dados .
Como um exemplo prático disso, se os campos de dados contiverem serviços de enumeração JSON para esse usuário em uma matriz e cada serviço tiver um ID, tipo e preço exclusivos, talvez você queira uma tabela separada com os seguintes campos (usando sua própria nomenclatura convenções):
serviceId (integer)
userName (string)
serviceType (string)
servicePrice (float)
E cada serviço para esse usuário teria sua própria entrada. Você pode então consultar usuários que possuem um serviço específico, o que, dependendo de suas necessidades, pode ser muito útil. Além da consulta fácil, a indexação de certos campos das tabelas separadas também pode resultar em consultas muito RÁPIDAS.
Atualização:com base em sua explicação dos dados armazenados e na maneira como você os usa, provavelmente deseja normalizá-los. Algo como o seguinte:
# 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)
Você poderia então consultar assim:
# 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');
Observe o quanto mais você pode fazer com dados normalizados e como é fácil? É trivial localizar, atualizar, anexar ou excluir qualquer componente específico.
