問題タブ [datamodel]

CoreDataで使用したいかなり高度なDataModelについて質問があります。

これまでにやったことの詳細に入る前に、やりたいことを説明します。

私は1つの部屋に滞在し、好みを持っているホテルのゲストのリストを持っています。準備ができたら、ユーザーはゲストを選択してデータを表示し、新しいゲストを追加できるようにする必要があります。また、部屋を選択し（アプリケーションによっても維持されます）、好みを選択します（ユーザーは新しい好みを追加することもできます）。ゲストは、設定をまったくまたは多く持つことができません。

これが私がこれまでに持っているものです。私は3つのエンティティを作成しました：-部屋番号のある部屋-名前のある設定-名前のあるGuestInfo->これらの関係の部屋（宛先の部屋）と設定（「To-ManyRelationship」のある宛先の設定）

これで、これらすべてを実行して、管理対象オブジェクトクラスを作成しました。ここまでは順調ですね。問題は、いくつかの警告が表示されることです。

1. GuestInfo.room-関係には逆はありません
2. GuestInfo.prefs --to-many関係には逆はありません：これは詳細設定です（特定の関係の複数の宛先にオブジェクトを配置することはできません）

これは私が無視できる単なる警告ですか？つまり、部屋の場合、各ゲストの部屋番号は常に1つだけですが、1つの部屋にさらに多くのゲストがいる可能性があるため、ここで逆の関係を設定することはできません。また、設定については、各ゲストの設定がないか、それ以上になることはありません。

データモデル図で指定する関係は何ですか? また、3つのテーブルがあることに1つ疑問があります

テーブル A (emp Id(pk) ,name) テーブル B (empId(pkfk),depno(pk),department) テーブル C -( オフィスの部門リストを含む)

テーブル B の作成では、Fk を empid と呼んだので、テーブル A とテーブル B の間の関係を描画しました。しかし、テーブル B の部門では、テーブル c からの部門のリストが含まれているドロップダウン リストを作成しました。テーブル b と c の間の関係を指定する必要がありますか?階層データモデルで。

データ層を構築するときに、休止状態や Microsoft Entity フレームワークなどのリレーショナル マッピング レイヤーへのオブジェクトを使用する利点または欠点があるかどうかを判断しようとしています。

長い目で見れば、手動で sql を使用してオブジェクトをマッピングする方がよいでしょうか、それともこれらのマッピング テクノロジのいずれかを活用する方がよいでしょうか?

ツールは単純なマッピングと sql を処理できるため、時間を節約できるため、単純なアプリの場合、追加のマッピング レイヤーが有利になる可能性がありますが、オブジェクト モデルがより複雑になった場合はどうでしょうか?

また、もしあればパフォーマンスへの影響は何ですか？

あなたが持っているかもしれない洞察をありがとう。

値を使用して Cassandra からデータを取得する方法

投稿 ID を使用して投稿を取得できます 特定のユーザーに関連する投稿を取得できますか

例のように user_id=4 に関連する投稿を取得することを意味します (user_id 属性を使用したクエリ)

よろしく

私の同僚の 1 人がテーブル スキーマを設計しました。テーブルの 1 つで、列は別の列の値に応じて異なるテーブルの主キーを参照できます。私はそれが別様に間違っていることを知っていますが、私をサポートする理論を見つけることができません. 彼のスキーマは次のようになります。

の場合item_type='V'、item_id はテーブル ビデオの ID であり、item_type='A'item_id はテーブル ビデオの ID です。

item_type( 、 )の組み合わせitem_idはユニークですが、実際にはまったく外部キーではありません。単一のテーブルを指していないため、外部キーとして定義することはできません。DDL 構文では許可されていません。

誰かがここで違反している原則または規則を見つけることができますか?

私はさまざまな種類のNoSQLデータベースの種類を調査しており、Bigtable、HBase、Cassandraなどの列ファミリーストアのデータモデルに頭を悩ませようとしています。

最初のモデル

一部の人々は、列ファミリーを行のコレクションとして説明します。各行には列^{[ 1 ]、[ 2 ]}が含まれます。このモデルの例（列ファミリーは大文字です）：

2番目のモデル

他のサイトでは、列ファミリーを行内の関連する列のグループとして説明しています ^{[ 3 ]、[ 4 ]}。この方法でモデル化された前の例のデータ：

最初のモデルの背後にある考えられる理論的根拠は、すべての列ファミリーがのような関係を持っているわけではないというUSERことBOOKMARKです。これは、すべての列ファミリーに同一のキーが含まれているわけではないことを意味します。カラムファミリーを外側のレベルに配置することは、この観点からより自然に感じます。

「列ファミリー」という名前は、列のグループを意味します。これはまさに、 2番目のモデルで列ファミリーが表示される方法です。

どちらのモデルもデータの有効な表現です。私は、これらの表現が人間に向けてデータを伝達するためだけのものであることを理解しています。アプリケーションは、そのような方法でデータを「考え」ません。

質問

列ファミリーの「標準」定義とは何ですか？それは行のコレクションですか、それとも行内の関連する列のグループですか？

私はこのテーマについて論文を書かなければならないので、人々が通常「コラムファミリー」の概念を他の人々にどのように説明するかにも興味があります。これらのモデルは両方とも互いに矛盾しているようです。コラムファミリーストアを説明するために、「正しい」または一般的に受け入れられているモデルを使用したいと思います。

アップデート

私の論文でデータモデルを説明するために、2番目のモデルに落ち着きました。コラムファミリーストアのデータモデルを他の人にどのように説明するかについては、まだ興味があります。

Amazon S3 のようなアプリケーションのデータ モデルを設計する必要があります。この問題を、ユーザー、バケット、オブジェクトという 3 つの主要な概念に単純化してみましょう。このモデルを設計するには多くの方法がありますが、ここでは 2 つ挙げます。

1. 3 種類 - ユーザー、バケット、オブジェクト。各オブジェクトには、その親としてバケットがあります。各バケットには、その親としてユーザーがあります。ユーザーはルートです。

2. 動的種類 - ユーザーはユーザーの種類に保存され、バケットはバケットの種類に保存されます - #1 と同じです。ただし、バケット内のオブジェクトは、「<BucketID>_Object」という名前の動的な種類に格納されます。バケットとオブジェクト エンティティの間に親子関係はなくなりました。この関係は、オブジェクトの種類の名前によって確立されます。

#1 はもちろん、より直感的で伝統的なモデルです。#2 は急進的であると主張する人もいれば、ばかげていると言う人もいるかもしれません。

なぜ私は＃2について考えているのですか？- 私のアプリケーションでは、オブジェクトに定義されたプロパティがバケットごとに異なる場合があります。これらのプロパティは、バケットの作成時にユーザーによって指定されます。また、オブジェクトのすべてのプロパティはクエリ可能である必要があります。バケットごとの動的なオブジェクトの種類により、これらの要件をサポートできます。さらに、オブジェクトの種類がルートの種類になったため、先祖フィルターを適用する必要がなくなりました。つまり、各オブジェクト プロパティのインデックスを無料で取得できます。モデル #1 では、祖先フィルターを適用する必要があります。つまり、クエリを実行するすべてのプロパティに対してカスタム インデックスが必要です。

雑な説明で申し訳ありません。わからなかったらもっと頑張ります。

私の質問は - #2 は完全に法外なモデルですか? ＃2では、私の種類は潜在的に数万に及ぶ可能性があります. それは大丈夫ですか？カスタム インデックスの数に制限があることは理解しています。しかし、動的な種類にカスタム インデックスを作成するのではなく、自動インデックスのみに依存しています。

ありがとう、キール

PenWag.comでMySQLからCassandraへの変換を急いでいるところです。Cassandraでは、GUIDからキーオフされたユーザーを保存していますが、ユーザーはGUIDではなく電子メールでサインインします（明らかに）。ユーザーのキーとしてのGUIDは、2つの理由から、電子メールよりも私にとって理にかなっています。実用的な観点からは、すべてのSuperColumnsを含む行を変更または削除/追加するのは面倒すぎるようです。理論的な観点からは、それはまだ同じユーザーですが、なぜ彼らのキーを変更する必要がありますか？

それでも、私の質問は次のとおりです。別のColumnFamilyにインデックスを作成し、ログインをサポートするようにemail->GUIDをマッピングしています。これは標準タイプのCFであり、列名は電子メールで、値はGUIDです。マッピングごとにSC全体がロードされないようにするのは、SuperではなくStandardです。「メールの変更」のサポートは簡単で、列の削除/追加だけです。ただし、これに代わる方法は、インデックスを列ではなく行として格納することです。行キーは電子メールであり、列はGUIDを保持します。管理する列（GUID）しかないため、これらの行の削除/追加は面倒ではありません。

どちらのアプローチでもうまくいくようです。それぞれの長所と短所は何ですか？ベストプラクティスはありますか？

これは、このディスカッションに対する Drew Sears の回答に対するフォローアップの質問です。

App Engine データストア - データ モデルに関する質問

バケットをオブジェクトの種類の参照プロパティとしてモデル化し、サイズが 1000 を超えるバケット 1234 のオブジェクトをクエリしたい場合、クエリは「where bucket = key('Bucket', 1234) and size > 1000」のようになります。 .

これには、バケットとサイズのプロパティにカスタム インデックスが必要になると想定しています。その仮定は間違っていますか？そうでない場合、元の質問のモデル＃2（動的種類）は、自動インデックスで機能させる唯一の方法ですか？別の方法があることを願っています。

ありがとう、キール

JSON はデータ交換においてますます重要になってきていますが、JSON 仕様はいくつかの点でかなり緩いです:

オブジェクト内の名前は一意である必要があります。

実装は、受け入れるテキストのサイズに制限を設定する場合があります。実装では、ネストの最大深さに制限を設定できます。実装によって、数値の範囲に制限が設定される場合があります。実装によって、文字列の長さと文字の内容に制限が設定される場合があります。

ほとんどの JSON パーサーは重複したオブジェクト キーを無視し、マイナス ゼロ (-0) とゼロを区別しないと思います。ほとんどの場合、数値を 32 ビット浮動小数点数または符号付き整数に制限する場合もあります。さらに、JSON には、有効な Unicode コード ポイントではない文字を含めることができます (この質問を参照してください)。また、基本多言語面 (U+0000 から U+FFFF) を超える Unicode 文字に関して実装に問題がある可能性があるに違いありません。しかし、JSON 仕様でもありません。CouchDB、MongoDB、Persevere/Dojo などの JSON データベースも制限を追加します。各システムで特別な意味を持つ可能性があるため、すべての JSON ストアでid、_id、およびのようなオブジェクト キーを使用できるとは思えません。$ref

これはなんとなくイライラします。JSON は簡単なはずですが、よく見ると多くの障害が見つかります。すべてのパーサーとデータベースで安全に使用できる JSON の一般的な (あまり制限されていない) サブセットはありますか?それとも、NoSQL の動きにより、JSON ドキュメントで使用してはならない拡張機能と特別な構造がますます追加されますか?