問題タブ [schema-design]

多言語のeコマースサイトをデザインしています。製品にはさまざまな特性があります。一部のプロパティは言語ごとに異なり（色など）、他のプロパティはすべての言語で同じです（SKUなど）。プロパティは事前定義されていません。たとえば、車にはエスプレッソマシン以外のプロパティがあります。

次のようにデータベーススキーマを設計したいと思います。

1. カテゴリxのすべての製品を言語yで検索して表現するのは高速です
2. 重複データの量が少ない
3. 翻訳付きのファイルを使いたくない

私はこのようなスキーマを使用することを考えています：

このスキーマに代わるより良い方法はありますか？このスキーマを使用すると、どのような問題が発生しますか？

このパラダイムを学びながら、教育目的で NFL 統計に基づいてデータ ウェアハウスを構築しています。次のモデリングの問題があります。

プレーヤーは、異なるチームで異なる年にプレーできます。同様に、コーチは、キャ​​リアの異なる年に異なるチームを指導できます。プレーヤーは、別の年に別のポジションでプレーする可能性もあります (まれですが可能性があります)。

異なる年の選手、コーチ、チーム間の割り当てをモデル化する最良の方法は何ですか?

さまざまな年の名簿情報をディメンションに格納しますか? たとえば、TimeKey、TeamKey、および CoachKey を持つ DimTeamRoster (チームには 1 人のヘッド コーチしか存在できないため) と、TeamRosterKey、PlayerKey、Positionkey を持つ FactTeamRoster があります。

それとも、TimeKey、TeamKey、PlayerKey、PositionKey を持つ FactTeamRoster を使用しますか? しかし、このファクト テーブルには実際にはメジャーが保存されず、単にその年の割り当てが保存されるだけなので、このアプローチは理にかなっていますか?

他の可能な解決策と、各アプローチの長所/短所/正しさは何ですか?

ユーザーと投稿のコレクションがあるとします。投稿収集では、ユーザー名をキーとして投票保存します。

投稿ごとにグループ化したいと思います。タイトルと、さまざまなユーザー年齢での投票数を調べます。

私は検索しましたが、mongodbmapreduceの2つのコレクションにアクセスする方法が見つかりません。再削減で達成することは可能でしょうか？

ユーザードキュメントを投稿に埋め込むのは非常に簡単ですが、実際のユーザードキュメントには多くのプロパティがあるため、これを行うのは良い方法ではありません。簡略化されたバージョンのユーザードキュメントを含めると、分析の次元が制限されます。

私はバックグラウンドから来てMySQL、頭を包み込もうとしていMongoDBます。特に、n:n関係を「Mongoway」でモデル化する方法を概念化するのに苦労しています。

この例では、collections：usersと。が2つあるとしinterestsます。データ内のいくつかのことを表現または照会できる必要があります。

• ユーザーの興味
• 「好き」や「嫌い」などのユーザーの関心の評価
• 特定の関心を持つユーザー
• 関心のある各評価のカウンター（インクリメント/デクリメント可能）
• インタレスト名

で、ユーザーIDとインタレストIDの両方でインデックス付けさMySQLれたテーブルを作成します。カウンターの場合、評価タイプごとに個別の列があり、ユーザーが関心を評価/非評価するたびに、カウントが誤っていないことを確認するためにトランザクションを実行しました。users_interests

いくつかのスキーマ設計について読んでみましたが、役に立ちませんでした。

あなたは失われた魂が道を見つけるのを手伝うことができますか？

音楽アプリのスキーマデザインに問題があると思います。

私は3つのコレクションを持っています：Artists、、。および3つのクラス：、およびTracksAlbumsartistsalbumstracks

からのドキュメントartists：

からのドキュメントalbums：

からのドキュメントtracks

まず第一に、その優れたスキーマ設計ですか??！多対多の関係があるため、このスキーマをこのように設計しました。トラックには2人のアーティストがいて、アルバムには2人のアーティストがいる場合があります。

とにかく、特定のトラックに添付されているアルバムのクエリに問題があります。

アーティストページにいるとしましょう

1. すべてのアーティストのアルバムとトラックを取得する必要があるので、これを行います。

   /li>

2. すべてのトラックをループしてアルバム名を取得する必要があります。このアーティストには3000トラックあるとしましょう。非常に遅いと思いますが、...

だから私の質問は：それは良いスキーマ設計ですか？

ユーザーがメンバーになっているリストを表す配列フィールドを持つmongoDBコレクションがあります。

*listed_in*フィールドを使用してメンバーリストを取得しています

また、特定のユーザーを照会して、そのユーザーが特定のリストのメンバーであるかどうかを知る必要があります

この場合、すべてのメンバーを含む*listed_in*フィールドを取得します。

私の質問は：mongoDBのカスタムフィールドを事前に計算する方法はありますか？user1.isInList1、user1.isInList2のようなフィールドを取得できる必要があります

今のところ、ユーザーが「list1」のメンバーであるかどうかを知るために* listed_in *配列を反復処理することにより、クライアント側でそれを行う必要がありますが、*listed_in*には1000個の要素が含まれる可能性があります。

Rails アプリケーション用の PostgreSQL データベースがあります。「public」という名前のスキーマには、主要なRailsモデルのテーブルなどが格納されています。「discogs」スキーマを作成しました。これには、「public」スキーマと同じ名前のテーブルが含まれることがあります。これが理由の1つです。これを整理するためにスキーマを使用しています。

アプリで「discogs」スキーマからモデルをセットアップするにはどうすればよいですか? Sunspot を使用して、Solr がこれらのモデルにもインデックスを作成できるようにします。あなたがこれをどのように行うかわかりません。

ユーザー テーブル、トランザクション テーブル、および user_transaction テーブルがあります。ユーザー数は約 75,000 です。アプリケーションで可能な一意のトランザクションの数は約です (トランザクション テーブルの行は 100 万から 300 万の間です)。user_transaction は、ユーザーがどの日時にどのトランザクションを行ったかを格納する上記の 2 つのテーブルの結合です。そのため、このテーブルは 1 年間のデータに対して巨大になります (アクティブなデータをテーブルから削除し、1 年後にアーカイブします)。年）。カウントは約 5,000 ～ 6,000 万行になると予想されます。これは、年末の最終的なデータ サイズになります。

平均サイズは約 3,000 万レコードだと思います。また、毎晩のインポート ジョブはこれらすべてのテーブルを更新し、これらのテーブルで挿入が行われるときの唯一の部分であり、アプリからデータにアクセスする (選択クエリを使用する) だけです。

結合テーブルを設計して巨大なトランザクション テーブルからの取得を高速化するにはどうすればよいでしょうか?テーブルに多くのフィールドを追加して非正規化し、結合を減らし、ほぼすべてのデータをトランザクション テーブルと user_transaction テーブルでのみ使用できるようにしました。

テーブルを分割したい場合、どのように分割しますか? アプリケーションは、最近のデータを最も頻繁に照会するために使用されます。

トランザクション テーブルを月ごとに分割することを考えているので、毎月 1 つのテーブルを持つことになります。

私たちが考えていた他のオプションは、1 週間の 1 日ごとに 7 つのテーブルを持つことですが、休止状態を使用していることを考えると、これはクエリの複雑さを大幅に増加させます。

約6000万の巨大なテーブルをどう設計するか

要求に応じて詳細:
スキーマから図を作成する必要があります。当面の間、さらに情報を示します: 関係は複雑ではありません。ユーザー、トランザクション、users_transaction、リソース テーブルの約 4 つのテーブルがあります。user_transaction は、他の 3 つのテーブル ID をすべて含む結合テーブルです。これは、これらの ID ごとに個別のエントリがあり、タイムスタンプに基づいて個別のエントリがあるため、非常に大きくなります。
現在、アプリケーションのユーザー数は 20 人未満です。（ただし、今後増える可能性があります）。
テーブルの主な消費者は次のとおりです。
1)毎週の自己監査レポートこれらのテーブルから過去 1 週間のユーザー アクティビティの詳細を含む電子メールとして送信されます。これらは (最終的に) 75,000 人のユーザーに送信され、レポートの生成と 1 人のユーザーへの電子メールの送信には、現在約 1 分かかります (パイロット フェーズでのテスト)。メールあたり 5 秒未満になるように、これに関するパフォーマンスを真剣に改善する必要があります。これは夜間に実行されるバックエンド ジョブです (最大で 3 ～ 4 時間かかります)
2)これらのテーブルからのトランザクションの要約ビューを示すグラフを含むダッシュボード。これらのクエリは、日付範囲のさまざまなフィールドに基づいてデータを実行および要約します。したがって、他のすべてのフィールド (ユーザー ID、リソース ID、resource_eventid、場所) が同じである場合、日ごと (時間を含まない) のカウントを格納する user_transactions テーブルを要約することを計画しています。
そして、月に基づいてこれらの要約テーブルを分割します。(毎月 1 つ)
注意点:このソリューションは、Oracle だけでなく、すべてのデータベース (MySQL、DB2 など) に適している必要があります。

よろしく、 Priyank Devurkar

だから私はフォーラムのモデルを作成しています。スレッドとコメントの束を考えてください。スレッドには多くのコメントがあります。RDBMSの世界では、私はこれをそのように設計します

さて、これで、データ/スキーマは多くの標準形式の1つに従うと思います（どれか忘れました）。そして、これが最も理にかなった方法だと思います。しかし、NoSQL の世界 (MongoDB) でこれを行う場合、この関係を設計する最善の方法は何でしょうか? RDBMS の方法でほとんど実行できましたが、埋め込みオブジェクトを使用する利点が失われます。何らかの理由で、私はそれを次のようにする傾向があります

これを行う最も賢明な方法は何でしょうか。それが私が求めていることだと思います。なぜ？