問題タブ [schema-design]

次の状況で、2つのdbスキーマアプローチのどちらを採用すべきかについて混乱しています。

Webサイトの複数の属性（ページサイズ、単語数、カテゴリなど）を保存する必要があり、属性の数は将来増加する可能性があります。目的は、このテーブルをユーザーに表示することであり、ユーザーはデータ間ですばやくフィルター/並べ替えを実行できる必要があります（したがって、テーブル構造は高速のクエリと並べ替えをサポートする必要があります）。また、変更のタイムラインを維持するために、以前のデータのログを保持したいと思います。したがって、私が考えた2つのテーブル構造オプションは次のとおりです。

オプションA

website_attributes

id、website_id、page_size、word_count、category_id、title_id、......（最大18列になり、null値がいくつかある可能性があり、将来的にさらに列を追加する必要がある可能性があることに注意する必要があります）

website_attributes_change_log

上記と同じテーブル構造に「change_update_time」の列が追加されています

このスキーマの利点は、一部の属性が他のテーブルにリンクされている場合でもクエリを簡単に記述できることと、並べ替えが簡単になることです。後で列を追加することの欠点は、ALTERTABLEが大きなデータテーブルで実行するのに非常に長い時間がかかることで問題になる可能性があります+多くのnull列を持つ多くの行が存在する可能性があります。

オプションB

website_attribute_fields

attribute_id、attribute_name（eg page_size）、attribute_value_type（eg int）

website_attributes

id、website_id、attribute_id、attribute_value、last_update_time

ここでの利点は、いつでも列を追加でき、ストレージスペースを節約できるという点で、このアプローチの柔軟性にあるようです。ただし、このアプローチを採用したいのですが、テーブルを表示する必要がある場合、クエリの記述は特に複雑になると思います[一度に複数のサイトのレコードを表示する必要があり、相互参照もあるためです。特定の属性の他のテーブルとの値の比較]+データの並べ替えは難しい場合があります[これが列ベースのアプローチではない場合]。

私が見ているもののサンプル出力は次のようになります。

Site-A.com、232032バイト、232ワード、PR 4、不動産[カテゴリテーブルにリンク]、..

サイト-B.com、...、...、...、..。

また、ユーザーはすべての数値ベースの列で並べ替えることができる必要があります。その場合、アプローチBは難しい場合があります。

ですから、私はオプションAを使用して正しいことをしているのか、それともそもそも考えもしなかったかもしれない他のより良いオプションがあるのか​​を知りたいのです。

オブジェクトがあり、Web アプリmongoからアクセスしたいと考えています。mongoose私が定義したスキーマには、Object格納されているユーザー ID と 3 レベルの値 (はい、多分、またはいいえ) があります。

例えば

上記id_value_*の s はユーザーのセッション ID であるため、ランダムな文字の長い文字列です。このための を作成するにはどうすればよいmongoose Schemaですか?

1. うまくいくでしょうかuser_info: {String, String}？

2. user_infoがオブジェクトの配列になるように再構築できます{ "sessionid": "<value>", "value: "y"}が、これは最適なオプションですか?

mongodbのコレクションごとに複数のスキーマを使用したかったのですが、どのように使用するのですか？
実行しようとすると、次のエラーが発生します。

エラー：

allUsersOverwriteModelError：コンパイル後にモデル を上書きすることはできません。OverwriteModelError：コンパイル後にモデル
を上書きすることはできません。checkInOut

これが私のschema.jsです

Rails と Mongoid をよりよく理解するために、Rails でフォーラム システムを構築しています。私が追加したい機能は、ユーザーがお互いにメッセージを送るために使用できるプライベート メッセージ システム フォーラムです。スキーマ設計に関しては、次の 2 つの解決策が考えられます。

解決策 1

ユーザーとメッセージは、"has_many" と "belongs_to" を使用して互いにリンクされた別個のドキュメントです。

ユーザー文書

has_many :messages_sent, :class_name => 'Message', :inverse_of => :message_sender

has_many :messages_received, :class_name => 'Message', :inverse_of => :message_recipient

と

メッセージ文書

フィールド :created、タイプ: DateTime、デフォルト: -> { Time.now }

フィールド:コンテンツ、タイプ:文字列

所属先 :message_sender, :class_name => 'User', :inverse_of => :messages_sent

所属先:message_recipient, :class_name => 'User', :inverse_of => :messages_received

ユーザーに自分の受信トレイを表示するために、並べ替えとフィルター処理を行って、最後のメッセージが送信された時刻でsome_user.messages_received並べ替え:createdられた一意の送信者 ID のリストを作成しsome_userます。

次に、特定の会話を表示するには、2 人の参加者間のすべてのメッセージを取得し、タイムスタンプに従ってインターリーブします。

messages_in = some_user.messages_received.where(:message_sender => selected_correspondent)

messages_out = some_user.messages_sent.where(:message_recipient => selected_correspondent)。

私はこの解決策が好きではありません。メッセージ コレクションに "where" クエリを何度も実行し、送受信されるメッセージを手動でフィルタリングおよびインターリーブする必要があるからです。努力。

解決策2（現在使用しています）

会話ドキュメントにメッセージを埋め込みます。以下に、ユーザー、メッセージ、および会話のコードを示します。has_and_belongs_to_many会話は、(ユーザーは多くの会話を持つ場合があるため、nn)を介して 2 人以上のユーザーにリンクされます。これにより、マルチユーザーの会話が可能になる可能性もあります。

私がこのソリューションを気に入っているのは、ユーザーの受信トレイを表示するために、会話ドキュメントに保存および更新されたsome_user.conversations順序で使用するだけでよく:last_message_received、フィルター処理が不要だからです。特定の会話を表示するために、送受信されたメッセージをインターリーブする必要はありません。メッセージは既に会話ドキュメントに正しい順序で埋め込まれているからです。

このソリューションの唯一の問題は、メッセージを追加するときに、2 人 (またはそれ以上) のユーザーが共有する正しい会話ドキュメントを見つけることです。ここで 1 つの解決策が提案されています: mongodb conversation systemですが、クエリが比較的高価に見え、マルチユーザーの会話のスケーリングが難しくなるように見えるため、私はそれが好きではありません。:lookup_hash代わりに、会話に参加している各ユーザーのオブジェクト ID から計算された SHA1 ハッシュであるという名前の会話ドキュメントにフィールドがあります。このように、2 人以上のユーザーがいる場合、対応する会話ドキュメントを見つけるのは簡単です (または、まだ存在しない場合は作成します)。

会話にメッセージを追加するには、Conversation.add_message(会話がまだ存在しない可能性があるため、インスタンス メソッドではなく、クラス メソッドを使用します) を使用して、送信者、受信者、および新しいメッセージ オブジェクトを指定します。

質問

私の質問は次のとおりです。Mongoid (または一般的に NoSQL) スキーマ設計のベスト プラクティスを考慮して、明らかに間違ったことをしていますか? ソリューションを改善するためにできることはありますか? ハッシュを使用して会話を検索するという私の考えは悪い考えですか?

コード

user.rb

会話.rb

メッセージ.rb

私は以下のようなスキーマ要素ノードを持っています

<MESSAGE>Employees eligibility for a benefit granted by a banking department agency of security.</MESSAGE>

このノードのスキーマを開発しているときに、次のような警告が見つかりました。

警告BEC2004：''、16進値0x19は無効な文字です。行20、位置26。

誰かがこれについて私を助けてくれますか？

スキーマを構築しようとしている以下の XML 形式を見つけてください。

Chich record -> ANNUALCOMPCOLLECTION -> ANNUALCOMP -> COMMISSION & BONUS Elements が常に繰り返されていない場合。

このため、私のスキーマ検証インスタンスは次のような警告をスローします

エラー BEC2004: 要素 'ANNUALCOMP' に無効な子要素 'OTHER' があります。予想される可能な要素のリスト: 'OVERTIME, COMMISSION'.

エラー BEC2004: 要素 'ANNUALCOMP' に無効な子要素 'OTHER' があります。予想される可能な要素のリスト: 'OVERTIME, COMMISSION'.

この検証を正しく行うには、どのようなプロパティを設定する必要がありますか?

はるかに柔軟な MongoDB を使用して、非常に正規化されたデータベースを再設計しています。現在の問題は、MySQL スキーマを大幅に変更しない限り、既存の構造が実装されている新しいプロセスをサポートしていないことです。既存のシステムを変更するのではなく、MongoDB の哲学は、ビジネスの将来にとってより意味のあるものになるようです。

ビジネス ルールは次のとおりです。

原材料を追跡する必要があります。この原材料に関するログは、分析に基づいて作成されます。原材料が加工され、部品に変わります。この多段階変換に関するログを保持する必要があります。コンポーネントはパーツに加工されます。このプロセスに関するログを保持する必要があります。パーツはアセンブリで使用できます。部品またはアセンブリを顧客に出荷できます。また、変換を完了するためのプロセスのシステムは、材料によって異なります。さらに、最適化されたプロセスが発見された場合に備えて、動的である必要があります。

コレクションとドキュメント:

• システム - プロセスのグループ
• プロセス - システムごとに多くのプロセスを持つシステムのサブドキュメント
• ログ - マシンまたはオペレーターによって記録されたデータと事実を含むタイムスタンプ付きの情報のログ。ログには、適用されるプロセスに応じてさまざまな種類があります。各ログ エントリは、上記のプロセスとコンポーネントのいずれかにリンクされます。
• 原材料 - 原材料の追跡項目
• コンポーネント - 原材料からコンポーネントに変換されたアイテムの追跡
• パーツ - コンポーネントまたは原材料から変換されたアイテムの追跡

私の質問は、親オブジェクトと孫オブジェクトの関係に関するものです。サブドキュメント、IE (孫はパーツを表す) と同じドキュメントに含める必要があります。

孫がたくさんいると予想されますが、これに対処する最善の方法は何ですか?

今ではかなり明白なパターンに気づきました。これについてあなたの意見を聞く必要があります。

リレーショナル モデルで、テーブル 1 からテーブル 2 への 1 対多の関係があるとします。たとえば、テーブル 1 はユーザー テーブルであり、テーブル 2 はすべてのユーザー ログインを記録するログイン テーブルである可能性があります。1 人のユーザーが複数回ログインできます。ユーザーを指定すると、そのユーザーによるすべてのログインを見つけることができます。

頭に浮かぶ最初のアイデアは、ログインをログイン テーブルにのみ格納することです。これがデザインワンです。

しかし、いくつかのユースケースで、ユーザーの特定のログイン (最後のログインなど) に関心がある場合は、最後のログイン時刻をユーザー テーブル自体にキャッシュするのが「一般的に良い考え」です。そうですか？

設計 2 は、結合を実行してから以前のログイン以外をすべて破棄することで、常に最後のログイン時刻を見つけることができるため、明らかに冗長です。

1 人のユーザーの場合、どちらでも問題ありません。しかし、すべてのユーザーの最終ログイン時刻を SQL クエリで調べたい場合、デザイン 1 では結合とサブクエリを使用して、不要な結果を除外します。

しかし、私たちのユースケースを考えると、最後にログインした時刻を user テーブル自体に保存することをお勧めします。これにより、結合を回避できます。そうですか？

これは、スキーマの設計時に見られる一般的なパターンですか?

クライアント管理 Web アプリケーションを作成しています。クライアントと支払いの関係を管理する正しい方法を見つけようとしています。1日に1回、アプリケーションが別のAPIにリクエストを送信し、データベースに保存する各クライアントの支払い額を同期しています。クライアントのタイプ (contract_type、sale_date など) に基づいて、支払い (支払い額) に関するレポートを常に実行する必要があります。すでにclientsコレクションを持っています。私は2つのスキーマから選択しようとしています:

各ドキュメントpaymentsがpayment. clientクエリごとにすべてのドキュメントが膨大な量のデータに成長するため、これらの種類のデータを分離する方が良いと思います（特定のフィールドを選択している場合でも、大量のメモリが必要になります）。しかし一方で、集計レポートを実行することはできません (2 つの異なるコレクションのデータに基づいているため)。最善のアプローチは何ですか？それらを分離し、サーバー側 (php) で 2 つの異なるクエリを使用して集計を行う必要がありますか?

相互に外部キーを持つために 2 つのモデルが必要な Django プロジェクトがあります。ただし、2 つの Python ファイルが相互にインポートする必要があり、Python では許可されていないため、これは不可能です。この問題を解決する最善の方法は何ですか?

したがって、私のコードは現在次のようになっています。

国/models.py:

ユーザー/models.py:

与えられたエラー: ImportError: 名前プロファイルをインポートできません