オブジェクトをシリアル化されたデータ (json の例) としてリレーショナル データベースに格納することが、これまでに良い方法であるかどうか疑問に思っていました。私はそれが一般的に悪いことであることを知っています、そして私はそれを広範囲に使用するつもりはありませんが、私は考えさせられるケースに出くわしました.
だから、ここに私の状況があります。私は基本的に、ポイント A からポイント B にアイテムを配送するためのモバイル注文システムを構築しています。A は開始アドレス、B は目的地です...どちらもユーザーの現在の GPS 座標です (通りの名前、通りの番号などの読み取り可能なデータと一緒に) .
要件は次のとおりです。
- 各注文には開始アドレスがあります
- 宛先アドレスはオプションです
- 注文と住所が作成されると、住所が更新されることはありません
- 各注文には新しい住所のセットが保存されます。つまり、同じ住所からさらに注文がある場合、以前に保存された住所は再利用されません。
- フィルタリング、並べ替えなど、住所データに対するクエリは必要ありません...
- 修正された場合のアドレス データの構造。これがシリアライゼーションの利点であることは知っていますが、私はそれを必要としません。
では、ジレンマは、住所データ (列: id、通り、番地、緯度、経度など) に別のテーブルを使用するか、単に住所を JSON 文字列として保存するかということです。
JSON の唯一の欠点は、データをシリアル化/逆シリアル化する必要があることです。いくつかのフィールドしかないため、大きな違いはありません。
一方、別のテーブルには気に入らないことがいくつかあります。
- 表示目的でのみ必要な何百万行もある可能性があります
- すべてが 1 つのテーブルにあると、データを監視しやすくなります
- 注文に関する情報が表示される場合は常にデータが必要になるため、これら 2 つのテーブルを常に結合する必要があります。
- 可能性は非常に低いですが、理論的には、自動インクリメントされた ID が不足する可能性があります
標準的なリレーショナル アプローチを使用してアドレスを別のテーブルに保存することで大きな間違いはないと思いますが、実際の利点は見当たりません。