Svaret på alle dine spørgsmål afhænger virkelig af, hvad JSON-dataene skal bruges til, og om du nogensinde bliver nødt til at bruge en eller anden egenskab for disse data for at bestemme, hvilke rækker der returneres.
Hvis dine data virkelig ikke har noget skema, og du virkelig bare bruger dem til at gemme data, der vil blive brugt af et program, der ved, hvordan man henter den korrekte række ud fra nogle andre kriterier (såsom et af de andre felter) hver gang, der er ingen grund til at gemme det som noget andet end nøjagtigt, som det program forventer det (i dette tilfælde JSON).
Hvis JSON-data INDEHOLDER en eller anden struktur, der er den samme for alle indgange, og hvis det er nyttigt at forespørge disse data direkte fra databasen, vil du gerne oprette en eller flere tabeller (eller måske bare nogle flere felter) til at indeholde disse data .
Som et praktisk eksempel på dette, hvis datafelterne indeholder JSON-optællingstjenester for den pågældende bruger i et array, og hver tjeneste har et unikt id, type og pris, vil du måske have en separat tabel med følgende felter (ved at bruge dit eget navn konventioner):
serviceId (integer)
userName (string)
serviceType (string)
servicePrice (float)
Og hver tjeneste for den bruger ville få sin egen adgang. Du kan derefter forespørge efter brugere end at have en bestemt tjeneste, hvilket afhængigt af dine behov kan være meget nyttigt. Ud over nem forespørgsel kan indeksering af visse felter i de separate tabeller også give meget HURTIGE forespørgsler.
Opdatering:Baseret på din forklaring af de lagrede data, og måden du bruger dem på, vil du sandsynligvis have dem normaliseret. Noget i stil med følgende:
# 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 derefter forespørge sådan:
# 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æg mærke til, hvor meget mere du kan gøre med normaliserede data, og hvor nemt det er? Det er trivielt at finde, opdatere, tilføje eller slette en specifik komponent.