Svaret på alla dina frågor beror verkligen på vad JSON-data är till för, och om du någonsin kommer att behöva använda någon egenskap hos den datan för att avgöra vilka rader som returneras.
Om din data verkligen inte har något schema, och du egentligen bara använder den för att lagra data som kommer att användas av en applikation som vet hur man hämtar rätt rad enligt några andra kriterier (som ett av de andra fälten) varje gång, det finns ingen anledning att lagra det som något annat än exakt som det programmet förväntar sig (i det här fallet JSON).
Om JSON-data INNEHÅLLER någon struktur som är densamma för alla poster, och om det är användbart att fråga dessa data direkt från databasen, skulle du vilja skapa en eller flera tabeller (eller kanske bara några fler fält) för att hålla dessa data .
Som ett praktiskt exempel på detta, om datafälten innehåller JSON-uppräkningstjänster för den användaren i en array, och varje tjänst har ett unikt id, typ och pris, kanske du vill ha en separat tabell med följande fält (med ditt eget namn konventioner):
serviceId (integer)
userName (string)
serviceType (string)
servicePrice (float)
Och varje tjänst för den användaren skulle få sin egen ingång. Du kan sedan fråga efter användare än att ha en viss tjänst, som beroende på dina behov kan vara mycket användbar. Förutom enkla frågor kan indexering av vissa fält i de separata tabellerna också ge mycket SNABB frågor.
Uppdatering:Baserat på din förklaring av lagrad data och hur du använder den, vill du förmodligen att den normaliseras. Något i stil med följande:
# 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)
Du kan sedan fråga så här:
# 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');
Lägg märke till hur mycket mer du kan göra med normaliserade data, och hur enkelt det är? Det är trivialt att hitta, uppdatera, lägga till eller ta bort någon specifik komponent.