Odpowiedź na wszystkie Twoje pytania naprawdę zależy od tego, do czego służą dane JSON i czy kiedykolwiek będziesz musiał użyć jakiejś właściwości tych danych, aby określić, które wiersze są zwracane.
Jeśli twoje dane naprawdę nie mają schematu i naprawdę używasz ich tylko do przechowywania danych, które będą używane przez aplikację, która za każdym razem wie, jak pobrać poprawny wiersz według innych kryteriów (takich jak jedno z pozostałych pól), nie ma powodu, aby przechowywać go jako coś innego niż dokładnie tak, jak oczekuje tego aplikacja (w tym przypadku JSON).
Jeśli dane JSON zawierają jakąś strukturę, która jest taka sama dla wszystkich wpisów i jeśli przydatne jest zapytanie o te dane bezpośrednio z bazy danych, warto utworzyć jedną lub więcej tabel (lub może tylko kilka pól), aby przechowywać te dane .
Jako praktyczny przykład tego, jeśli pola danych zawierają wyliczanie usług JSON dla tego użytkownika w tablicy, a każda usługa ma unikalny identyfikator, typ i cenę, możesz potrzebować oddzielnej tabeli z następującymi polami (przy użyciu własnego nazewnictwa konwencje):
serviceId (integer)
userName (string)
serviceType (string)
servicePrice (float)
Każda usługa dla tego użytkownika dostanie swój własny wpis. Możesz wtedy zapytać o użytkowników, niż mieć konkretną usługę, która w zależności od Twoich potrzeb może być bardzo przydatna. Oprócz łatwego wykonywania zapytań, indeksowanie niektórych pól w oddzielnych tabelach może również zapewnić bardzo SZYBKIE zapytania.
Aktualizacja:Na podstawie wyjaśnień dotyczących przechowywanych danych i sposobu ich używania prawdopodobnie chcesz je znormalizować. Coś takiego:
# 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)
Możesz wtedy zapytać w ten sposób:
# 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');
Zauważ, o ile więcej możesz zrobić ze znormalizowanymi danymi i jakie to proste? Łatwo jest zlokalizować, zaktualizować, dołączyć lub usunąć dowolny konkretny komponent.
