問題タブ [non-relational-database]

「地域マネージャー」が複数の地区にある複数の学校を管理するのに役立つ大規模な Web アプリを構築しています。

合計で、約 400,000 人の学生と教師がいます。

成績管理などの当たり前の管理に加えて、出席管理（毎日）も必要になります。

私は、Heroku にデプロイする小規模な Web アプリを構築することに慣れています。この規模のシステムを考えると、今後は非リレーショナル DB の使用を検討する必要がありますか?それとも PostgreSQL に固執し、高速性とデータの整合性を確保するために特定の最適化を行う必要がありますか?

明確でない場合、主な懸念は、リレーショナル db システムで、非常に多くのテーブルにわたって非常に多くのレコードを管理するのに非常に遅いシステムの 1 つです。

また、リレーショナル DB を使用することが推奨される場合、速度を確保するために実行できる一般的な最適化は何ですか? 最も大きく、最も明白なものは、最も頻繁にアクセスされる情報にインデックスを使用することです....それ以外のものは大歓迎です。

ありがとう。

PS 私のチームは、私たちが何をすべきかについて分かれているので、皆さんはバランスを崩すのに役立つ意見を貸してくれるでしょう :)

私の職場には Django アプリケーションがあり、内部ネットワークでのみ使用できます。

現在、Excel を使用してデータをインポートしていますが、これはエラーが発生しやすいプロセスであり、置き換えたいと考えています。

メインの Django アプリケーション (メニューのルックアップ値) からのすべてのデータではなく一部のデータを公開する Javascript のリッチ Web アプリケーションを提供したいと考えています。これは、外部から見えるサーバー上で実行されます。

では、これに対する良いアプローチは何ですか？

管理者は、メインの Django アプリを外の世界で利用できるようにするためのセキュリティについて懸念しています。私は中間層も好みます。現在のコードを調べて確認するよりも、小さなサーバー側のアプリを作成する方が簡単だと思います。それは外の世界に対して十分に安全です (私は Django がこのアプリを構築することを学びました。そのため、古いコードの一部はベスト プラクティスに従って実行されていませんが、必要に応じて機能します)。また、メイン データベースにインポートする前に誰かがチェックするまで、新しいデータを保持したいと考えています。(私は唯一の開発者なので、時間の考慮事項があります)。

ということで、今考えられる選択肢は2つ。

1: 外部に面したサーバーに小さな Django アプリを配置します。これにより、メイン アプリと通信してルックアップに必要な値を取得し、インポートする前に入力を保存できます。テーブルは基本的にメイン アプリをミラーリングし、メイン アプリ テーブルが変更されたときに更新する必要があります。

2: 同様のものを用意しますが、データベースを使用するのではなく、外部に面したサーバーを使用して内部サーバーの REST インターフェイスに接続します。Django 非リレーショナルを使用して、メイン アプリの REST インターフェイスからデータを取得するようなものです。メイン データベース サーバーにインポート テーブルを配置して、承認用のデータを保存します。

これらの良い/悪いアプローチのどちらですか? 他の提案はありますか？n 層アプリについて学習するための適切なリソースはありますか?

私の mongoDB コレクション内のすべてのドキュメントには、整数の配列があります。各整数に 32 ビットを超える必要はなく、整数配列の長さは各ドキュメントで同じになります。

私のアプリケーションのクライアントは、配列内の個々のフィールドを頻繁に更新します。

256 個の整数の配列を持つ 5000 から 10000 のドキュメントがある場合、mongo db はスペースを浪費しますか?配列の内容を整数以外のデータ型に変更したり、配列の長さを変更したりするために準備する必要があるからです。

mongoDB の設計により、従来のリレーショナル データベースと比較して、配列内の個々の整数の更新が非常に非効率になりますか?

ここで説明する更新配列構文を使用していると仮定します: http://docs.mongodb.org/manual/applications/update/#update-arrays

私はMongoDBを使用していますが、最終的に2つのコレクションになりました(意図せず)。

最初のコレクション (サンプル) には、次の構造を持つ 1 億件のレコード (ツイート) があります。

2 番目のコレクション (users) には、ツイート コレクションからの 3,000 万件のユニーク ユーザーのレコードが含まれており、次のようになります。

ここで、users コレクションの _id はつぶやきコレクションの user.screen_name であり、ターゲットはステータス (スパマーかどうか) であり、最後に value.count は最初のコレクション (サンプル) コレクションに表示されたユーザーの数です (例: numberキャプチャされたツイートの

ここで、次のクエリを作成したいと思います。

ユーザーがターゲット値 = 1 を持つサンプル コレクション (ツイート) からすべてのドキュメントを返したい

つまり、たとえば、すべてのスパマーのすべてのツイートを返したいとします。

私はこれをできる限り簡単にしようとします。
MySQL から来て、テーブルの観点から考えて、次の例を使用しましょう。

不動産のウェブサイトを運営していて、家のリストを
通常どおり表示しているとします。次のテーブルを使用します。

• 家 - 手元にある不動産資産
  
• owner - 家の所有者 (家との 1 対多の関係)
  
• 代理店 - 不動産仲介業者 (住宅との多対多の関係)
  
• images - 家屋との多対一の関係
  
• レビュー - 家屋との多対一の関係
  

MongoDB は、リレーショナル データベース (正規化) によく似た一意の ID を持つさまざまなコレクションで Web アプリを設計する柔軟性を提供し、迅速な選択を楽しむために、コレクション、関連するオブジェクト、およびデータ (非正規化) 内にネストできることを理解しています）。

不動産住宅リストに戻ると、通常のリレーショナル DB では、データを入力するために使用されるクエリは非常にコストがかかります。住宅ごとに、その画像、レビュー、所有者、代理店をクエリする必要があり、各エンティティはフィールドを持つ異なるテーブルに存在します。 、おそらく結合を使用し、複数のクエリを1つに結合します-高価です!

MongoDB に入ります - ジョインを必要とせず、家に関連するすべてのデータを家のコレクションの家アイテムに保存できます。
しかし、関連するレビュー/代理店/所有者/画像を追加/更新/削除する必要がある場合はどうなりますか?

これは私にとって謎であり、推測する必要がある場合、関連する各コレクションは家のテーブル内のデータの上に独自のコレクションに存在し、これらの関連データの 1 つが追加/更新/削除されると、独自のコレクションと家のコレクションで更新する必要があります。この更新時に、更新されたすべての関連データでハウス レコードを更新していることを確認するために、他のコレクションにもクエリを実行する必要がありますか?
私はここで推測しているだけであり、あなたのフィードバックを本当に感謝しています.

ありがとう、
アジャール

非リレーショナル データベース IMS に接続するためのツールを探しています。利用可能なツールはありますか？リレーショナル データベースの DBVisualizer に似ています。

メタデータ URL について考えている人は、ホスト名、ポート、および IMS データストアがある場合にメタデータ URL を見つける方法を教えてください。

メタデータ URL に関する以下の情報を取得しました。

ターゲット IMS データベースを表すデータベース メタデータの場所。

MetadataURL プロパティーは、IMS Enterprise Suite Explorer for Development によって生成される Java メタデータ クラスの完全修飾名です。URL には接頭辞として class:// を付ける必要があります (例: class://com.foo.BMP255DatabaseView)。

私はあらゆる種類のDBが初めてです。任意のリレーショナル データベースをグラフ形式 (非常に平坦なグラフである可能性があります) で表すことも、リレーショナル データベース内の任意のグラフ データベース (十分な数のテーブルを使用することもできます) を表すこともできるようです。

グラフは、あるエントリから別のエントリへのハード リンクを持つことにより、他のテーブルでの多くのルックアップを回避できるため、多くの/ほとんどの場合、グラフの速度の利点を確認できます。データが自然に階層化されている場合、特にツリーを形成している場合、リレーショナルよりもグラフの方が論理的/合理的な利点があることがわかります。他のノードにリンクするグラフのノードには、おそらく複数のマップまたはリストが含まれていると思います...これは、グラフのノード内にリレーショナル DB を効果的に含んでいます。

グラフ DB とリレーショナル DB に不利な点はありますか? (注: 私は実装に欠けている機能などに目を向けているのではなく、理論的な長所/短所に注目しています)

リレーショナル データベースを引き続き使用する必要があるのはいつですか? int から int への単一のマッピングが論理的にある場合でも、グラフでそれを行うことができます。

平日をmongodbドキュメントに保存するためのベストプラクティスを探しています。

リレーショナル データベースでは、1-n nn の関係は 2 つ以上のテーブルを意味します。しかし、非リレーショナル データベースでは、これらを 1 つのモデルに直接格納できるため、火曜日に可能なすべてのスケジュールをクエリしたいと考えています。