-1

データ モデルをさまざまな方法で構造化することの長所と短所を評価しようとしています。複雑なネストされたデータ型を SQL テーブルの個々の列に詰め込むことで自分自身を撃つことになるかどうかを知りたいです。 .

たとえば、構造体の配列 (さらに悪いことに、ハッシュのハッシュの配列) をシリアル化し、それを 1 つの列に保存したいとします。ほとんどの場合、多少ネストされた JSON ディクショナリになります。何かのようなもの：

user_id | user_related_data_blob
---------------------------
1       | { .... }

一部のデータがユーザーにあまり密接に関連していない場合に備えて、すぐにわかる明らかな短所はデータ結合です。取得された各行のサイズもあるため、特にほとんどのデータがクライアントによってすぐに必要とされない場合は、Web からのフェッチがかなり遅くなる可能性があります。それらの列で SQL を実行することも、それをサポートするための特別な技術がない限り、かなり複雑になります (そしておそらくインデックス付けできません)。

唯一の利点は、コンテキストによっては重要かもしれませんが、複雑なスキーマを作成したくない場合、すべての制約が正常であることを確認するのに多くの時間を費やしたくない場合と、はるかに少ない制約があることです。可動部品。簡単なプロトタイプのようなものでは、それは理にかなっているかもしれません.

ここで何か不足していますか？SQL の世界では、個々の列にデータをネストしてはならないという経験則はありますか? 良いガイドラインはありますか？

4

3 に答える 3

2

SQL の世界では、個々の列にデータをネストしてはならないという経験則はありますか?

最初の正規形を開始します。おそらく、NoSQL ソリューションを求めていますか?

于 2013-01-20T08:42:22.133 に答える
0

主な問題は、データを効果的に更新できるようにするために、データを別の環境に取得する必要があり、最も効果的な方法でデータにアクセスできる可能性が低いことです。たとえば、Postgresにはjsonデータ型と、型の検証を含むデータを取得および保存するためのいくつかの関数がありますが、データベースからオブジェクトを取得し、コードでシリアル化してから、必要な方法でアクセスする必要があります。

データストアにはさまざまな種類があるため、特定の形式でデータを保存する必要がある場合は、その周りに設計されたオプションを探します。たとえば、MongoとCouchbaseは、JSONでエンコードされたデータを格納するための優れたエンジンであり、JSONオブジェクトにその自然な型としてアクセスできます。

少しPostgresに戻ると、JSONとしてフォーマットされたテーブル行を返すrow_to_json（）関数が提供されます。JSONデータをフラットなテーブル構造に簡単にマッピングできる場合、これはいくつかの可能性を提供する可能性があります。もちろん、非構造化データや半構造化データには役立ちません。

于 2013-01-20T11:22:45.487 に答える
0

SQLデータベースにblobデータを格納することは、SQLがそれを理解せず、それを操作するための便利なツールを提供しないため、悪い考えです。

  1. BLOBデータを検索またはフィルタリングする方法はありません
  2. BLOBの一部だけを取得する方法はありません。すべて、または何もありません。
  3. ほとんどのSQLデータベースは、BLOBを処理するために内部的に構築されていません

SQLで文字列操作を使用してblobのコンテンツへのアクセスを制限するという汚い回​​避策を見つけることができますが、これらは実装と保守が非常に遅く、面倒です。

ただし、ネストされたドキュメントがデータを表現するための最良の方法である場合は、ドキュメントの個々のフィールドを検索、フィルタリング、および変更するためのツールを提供するMongoDBやCouchDBなどのドキュメント指向データベースの使用を検討する必要があります。

于 2013-01-20T13:42:42.933 に答える