Ответ на все ваши вопросы действительно зависит от того, для чего нужны данные JSON, и от того, понадобится ли вам когда-либо использовать какое-либо свойство этих данных, чтобы определить, какие строки возвращаются.
Если ваши данные действительно не имеют схемы, и вы действительно просто используете ее для хранения данных, которые будут использоваться приложением, которое знает, как извлечь правильную строку по некоторым другим критериям (например, одному из других полей) каждый раз нет причин хранить его как что-либо кроме того, что ожидает его приложение (в данном случае, JSON).
Если данные JSON содержат некоторую структуру, одинаковую для всех записей, и если полезно запрашивать эти данные непосредственно из базы данных, вы можете создать одну или несколько таблиц (или, может быть, просто несколько дополнительных полей) для держать эти данные.
В качестве практического примера этого, если поля данных содержат сервисы перечисления JSON для этого пользователя в массиве, и каждый сервис имеет уникальный идентификатор, тип и цену, вам может потребоваться отдельная таблица со следующими полями (используя ваши собственные соглашения об именах):
serviceId (integer)
userName (string)
serviceType (string)
servicePrice (float)
И каждый сервис для этого пользователя получит свою собственную запись. Затем вы можете запросить пользователей, у которых есть конкретный сервис, что в зависимости от ваших потребностей может быть очень полезным. В дополнение к простым запросам, индексирование определенных полей отдельных таблиц также может привести к очень БЫСТРЫМ запросам.
Обновление: основываясь на вашем объяснении хранимых данных и способах их использования, вы, вероятно, хотите, чтобы они были нормализованы. Примерно так:
# 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)
Затем вы можете запросить примерно так:
# 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');
Обратите внимание, сколько еще вы можете сделать с нормализованными данными, и насколько это просто? Обнаружить, обновить, добавить или удалить любой конкретный компонент тривиально.