すべての質問に対する答えは、JSONデータの目的と、返される行を決定するためにそのデータのプロパティを使用する必要があるかどうかによって異なります。
データに本当にスキーマがなく、他の基準(他のフィールドの1つなど)によって毎回正しい行を取得する方法を知っているアプリケーションが使用するデータを格納するために実際に使用している場合は、そのアプリケーションが期待するもの(この場合はJSON)以外のものとして保存する理由はありません。
JSONデータにすべてのエントリで同じ構造が含まれていて、データベースからこのデータを直接クエリするのに役立つ場合は、このデータを保持するために1つ以上のテーブル(またはいくつかのフィールド)を作成する必要があります。 。
この実際的な例として、データフィールドにそのユーザーのJSON列挙サービスが配列に含まれ、各サービスに一意のID、タイプ、価格がある場合は、次のフィールドを含む個別のテーブルが必要になる場合があります(独自の命名規則を使用)規則):
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');
正規化されたデータでどれだけ多くのことができるか、そしてそれがどれほど簡単であるかに注目してください。特定のコンポーネントを見つけたり、更新したり、追加したり、削除したりするのは簡単です。