タグ付けされた質問 「mongodb」

辞書のエントリ（通常は単一の単語）とその意味を別の言語で保存するデータベースを設計および設定する予定です。したがって、たとえば、テーブル用語集にはエントリと定義が必要であり、各テーブルレコードには、格納されているレコードのIDへの参照がありますTag（各エントリにはタグまたはカテゴリが必要です）。 私のデータは構造を持っているので、SQLデータベース（MySQLなど）を使用することは悪い考えではありません。しかし、人々はMongoDBの方がパフォーマンスがはるかに優れていると言います。 クライアント側では、アプリケーションは、バックエンドが提供するREST APIを使用するオートコンプリートを備えた検索ボックスを提供できる必要があります。このようなシナリオでMySQLを使用するのは安全ですか？または、これに他のソリューションのMongoDBまたはElasticSearchを使用する必要がありますか？このようにして、数十万件のレコードが保存およびアクセスされることになっています。

55 database-design  data-structures  mysql  relational-database  mongodb 

ユーザーがさまざまなウィッシュリストにアイテムを追加できるウィッシュリストシステムに取り組んでおり、ユーザーが後でアイテムを再注文できるようにする予定です。これをデータベースに保存して高速で混乱を起こさない最善の方法については本当にわかりませんものをきれいにするため）。 最初にpositionコラムを試しましたが、アイテムを移動するときに他のすべてのアイテムの位置の値を変更する必要があるのは非常に効率が悪いようです。 自己参照を使用して前の（または次の）値を参照する人を見てきましたが、繰り返しますが、リスト内の他の多くの項目を更新する必要があるようです。 私が見た別の解決策は、小数を使用し、それらの間の隙間にアイテムを貼り付けるだけです。これはこれまでの最良の解決策のように思えますが、より良い方法が必要だと確信しています。 通常のリストには最大で約20個程度のアイテムが含まれ、おそらく50個に制限されます。並べ替えはドラッグアンドドロップを使用し、おそらく競合状態などを防ぐためにバッチで実行されますajaxリクエスト。必要に応じて（Herokuで）postgresを使用しています。 誰にもアイデアはありますか？ 助けてください！

54 database  database-design  mongodb  postgres 

ユーザーがオンラインとオフラインの両方で作業できるWebベースのプロジェクトがあり、クライアント側でレコードの一意のIDを生成する方法を探しています。ユーザーがオフライン（つまり、サーバーと通信できない）で機能し、一意であることが保証され、安全なアプローチが必要です。「安全」ということで、クライアントが重複したIDを（悪意のあるかどうかに関係なく）送信し、それによってデータの整合性が破壊されることを特に心配しています。 これがすでに解決された問題であることを願って、私はいくつかのグーグルをしてきました。特に本番システムで使用されているアプローチに関して、非常に決定的なものは見つかりませんでした。ユーザーが作成したデータのみにアクセスするシステムの例をいくつか見つけました（たとえば、複数のデバイスでアクセスするTodoリストですが、作成したユーザーのみがアクセスできます）。残念ながら、もう少し洗練されたものが必要です。私はここでいくつかの本当に良いアイデアを見つけましたが、それは私が物事がうまくいくと思っていた方法と一致しています。 以下は私の提案するソリューションです。 いくつかの要件 IDはグローバルに一意（または、システム内で少なくとも一意）である必要があります クライアント上で生成されます（つまり、ブラウザーのJavaScriptを介して） セキュア（上記およびその他の概要に従って） データは、作成していないユーザーを含む複数のユーザーが表示/編集できます。 バックエンドデータベース（MongoDBやCouchDBなど）に重大なパフォーマンスの問題を引き起こさない 提案されたソリューション ユーザーがアカウントを作成すると、サーバーによって生成され、システム内で一意であることがわかっているuuidが与えられます。このIDは、ユーザー認証トークンと同じであってはなりません。このIDをユーザーの「IDトークン」と呼びましょう。 ユーザーが新しいレコードを作成すると、javascriptに新しいuuidが生成されます（window.cryptoを使用して生成されます（使用可能な場合はこちらを参照）。このIDは、ユーザーがアカウントを作成したときに受け取った「IDトークン」と連結されます。この新しい複合ID（サーバー側IDトークン+クライアント側UUID）は、レコードの一意の識別子になりました。ユーザーがオンラインで、この新しいレコードをバックエンドサーバーに送信すると、サーバーは次のことを行います。 これを「挿入」アクション（更新や削除ではない）として識別します 複合キーの両方の部分が有効なuuidであることを検証します 複合IDの指定された「IDトークン」部分が現在のユーザーに対して正しいことを検証します（つまり、アカウントを作成したときにサーバーがユーザーに割り当てたIDトークンと一致します） すべてがcopaseticである場合、dbにデータを挿入します（id が既に存在する場合、誤って既存のレコードを更新しないように、「upsert」ではなく挿入を行うように注意してください） クエリ、更新、削除には特別なロジックは必要ありません。従来のアプリケーションと同じ方法で、レコードのIDを使用するだけです。 このアプローチの利点は何ですか？ クライアントコードはオフラインで新しいデータを作成し、そのレコードのIDをすぐに知ることができます。クライアント上で一時IDが生成され、システムがオンラインのときに「最終」IDに交換される代替アプローチを検討しました。しかし、これは非常に脆い感じがしました。特に、更新が必要な外部キーを使用して子データを作成することを検討し始めたとき。IDが変更されたときに変更されるURLの処理は言うまでもありません。 IDをクライアント生成値とサーバー生成値の複合にすることにより、各ユーザーはサンドボックスにIDを効率的に作成します。これは、悪意のある/悪意のあるクライアントが行うことができる損害を制限することを目的としています。また、idの衝突はユーザーごとに発生し、システム全体にグローバルではありません。 ユーザーIDトークンはアカウントに関連付けられているため、IDは、認証されたクライアント（つまり、ユーザーが正常にログインした場所）によってのみユーザーサンドボックスで生成できます。これは、悪意のあるクライアントがユーザーの不正なIDを作成しないようにすることを目的としています。もちろん、ユーザー認証トークンが悪意のあるクライアントに盗まれた場合、悪いことをする可能性があります。しかし、認証トークンが盗まれると、アカウントはとにかく危険にさらされます。これが発生した場合、被害はシステム全体ではなく、侵害されたアカウントに限定されます。 懸念事項 このアプローチに関する私の懸念のいくつかを以下に示します これにより、大規模なアプリケーションに対して十分に一意のIDが生成されますか？これがIDの衝突を引き起こすと考える理由はありますか？javascriptはこれが機能するために十分にランダムなUUIDを生成できますか？window.cryptoはかなり広く利用可能であり、このプロジェクトはすでに合理的な最新のブラウザを必要としているようです。（この質問には、独自のSO質問があります） 悪意のあるユーザーがシステムを危険にさらす可能性のある抜け穴がありますか？ 2つのuuidで構成される複合キーを照会するときに、DBのパフォーマンスを心配する理由はありますか。最高のパフォーマンスを得るには、このIDをどのように保存する必要がありますか？2つの別々のフィールドまたは単一のオブジェクトフィールド？Mongo対Couchに異なる「最良の」アプローチはありますか？連続していない主キーがあると、挿入時に顕著なパフォーマンスの問題が発生することがあります。主キーに自動生成された値を持ち、このIDを別のフィールドとして保存する方が賢明でしょうか？（この質問には、独自のSO質問があります） この戦略を使用すると、特定のレコードセットが同じユーザーによって作成されたことを簡単に判断できます（すべてのユーザーが同じ公開IDトークンを共有するため）。これに関する差し迫った問題はありませんが、必要以上に内部の詳細についての情報を漏らさない方が良いです。別の可能性は、複合キーをハッシュすることですが、それはそれが価値があるよりももっと面倒かもしれません。 ユーザーのID衝突が発生した場合、回復する簡単な方法はありません。クライアントは新しいIDを生成できたと思いますが、これは実際には発生しないはずのエッジケースでは多くの作業のようです。私はこれを未解決のままにするつもりです。 認証されたユーザーのみがデータを表示および/または編集できます。これは私のシステムにとって許容できる制限です。 結論 合理的な計画を超えていますか？この一部は、問題のアプリケーションの完全な理解に基づいた判断の呼び出しに帰着することを理解しています。

47 javascript  mongodb  offline  uuid 

MongoDBは、非常に使いやすいことがわかっているNoSQLデータベースです。最近、HTTPリクエストを使用していくつかのデータを収集し、データの処理後に結果を保存する必要のある簡単なアプリケーションを開発する必要があり、MongoDBを使用してみました。 この経験から、私は従来のリレーショナルデータベースよりもはるかに使いやすく、DBAではなく開発者であるため、作業が大幅に簡素化されました。 それでも、SQL ServerやMySQLのような従来のリレーショナルデータベースの代わりにMongoDBをいつ使用すべきかわからないことがあります。 その場合、リレーショナルデータベースの代わりにMongoDBを使用できるのはいつですか？MongoDBに関して、状況によっては不適切となる、非常に大きな警告がありますか？

17 database  nosql  mongodb 

第一に、これはプログラミングの問題というよりも設計上の問題です。 既存のJSONデータを取得してMongoDBに挿入する必要があるアプリケーションを作成しています。一部のJSONドキュメントには.キーにピリオドが含まれていることがわかりました。MongoDBのドキュメントで.、クエリに使用されるピリオドはMongoDBのキーとして許可されていないことを読みました。 私はWebアプリケーションに多くの挿入を行いません。それはほとんど一度だけの挿入です。また、すべてのデータを取得する必要があるため、ドキュメントの一部を照会するのではなく、ほとんどの場合ドキュメント全体を取得します。 したがって、私の要件を考慮して、JSONドキュメントを保存する方法には2つの選択肢があります。 キーのピリオドをJSONで検索してエスケープし、MongoDBに挿入します。 JSON全体をBSON形式に変換して保存し、エスケープの必要性を回避し、MongoDBの外部で必要に応じてJSONを手動で解析します 結論を出すことができないため、どちらがより良い設計になるか教えてください。

14 json  mongodb 

この男が言うことに基づいて：http : //toddfredrich.com/ids-in-rest-api.html UUIDを使用してAPIリソースを識別することについて彼が正しいと仮定します。次に、そのように実装しようとすると問題が発生します。これは次のとおりです。 class FooEntity { final String id = null; //auto-generated by my backend (mongodb), not shared final UUID uid = UUID.randomUUID(); //the resource id } （クライアントとサーバー間では、データベースエンティティではなく、送受信されるDTOです。） 問題は、id私がもう使用していないので役に立たないということです。クライアントがリクエストを行うuidので、なぜ2つのIDを処理する必要があるのですか？次に、最初の同じ問題に戻ります。UUIDを主キー（_id）として設定すると、バックエンドIDが公開されます。 そのほかに、効率性のトピックがあります。ObjectIdによるインデックス作成はUUIDよりもはるかに効率的であると読みました。

13 database  api-design  mongodb 

スキーマ設計を適切に文書化したいMongoDBデータベースがあります。MongoDBはNoSQLデータベースであり、本質的にスキーマレスであることを知っていますが、アプリケーションを通じてスキーマを強制し、findOne()結果の印刷よりも優れた方法でスキーマを表現したいと考えています。 私は多くの人がERまたはUMLを使用しているのを見ていますが、私のNoSQLデータベースをリレーショナルDBとして表すのは概念的に正しいとは思えません。少なくとも、奇妙に見えます。 UMLを使用した例：MongoDB：論文でスキーマ図を表す方法は？ 人々は異なるモデルを使用していると思いました。私が検索したところ、スキーマを理解するための素晴らしいTreeビューを提供するMongoVUEがありましたが、プリンターには適していません。 NoSQLの世界で他に見逃しているものはありますか？または、私は休んで伝統的なUMLに固執するべきですか？

13 documentation  uml  nosql  mongodb  diagrams 

閉まっている。この質問はトピックから外れています。現在、回答を受け付けていません。 この質問を改善してみませんか？ 質問を更新して、ソフトウェアエンジニアリングスタック交換のトピックになるようにします。 6年前休業。 3つの主要な部分で構成されるWebアプリで構成される、Railsで最初の実際のプロジェクトを構築します。 データベースを使用しない静的部分 各ユーザーの行は同じフィールドを持つため、データベースを必要とし、MySQLを使用できるユーザー登録部分 ユーザーがコレクション内のアイテムを作成、整理、編集し、他のユーザーと共有できる「アプリ」 いくつかのアイテムタイプがあり、それぞれに異なるオプションがあります。たとえば、次のオプションを持つ「ビデオ」アイテムがあるとします。 id ユーザーID collection_id 題名 プラットフォーム（埋め込まれている場合） URL（埋め込まれている場合） ファイル名（アプリでホストされている場合） ファイルサイズ（アプリでホストされているID） 「マップ」アイテム： id ユーザーID collection_id 題名 プラットフォーム（Googleマップ、Bingマップ...） ロケーション url 地図のサイズ ユーザーがMySQLをアイテムに使用している間、各アイテムが別のアイテムとは異なるオプションを必要とする可能性があるため、MongoDBの柔軟性が役立つ場合があります。 これまで私は常にPHPとMySQLを使用してきました（常に小規模なプロジェクトでは共有ホスティングを使用しています）。スケーラビリティは私にとってまったく新しい言葉です。 学ぶ時間はありますが、1か月くらいで具体的なことができるようになりたいです。 私はMongoDBとNoSQLとRDMSとMySQLについてたくさん読んだので、それを試した後、MongoDBがどのように機能するかが好きだと言っておく必要があります。 私の状況では何をしますか？どうして？ スケーラビリティについて、MongoDBに問題がある可能性はありますか？はいの場合（DBサイズに関して）、これらの問題によりアプリが大幅に遅くなる可能性がありますか？ 編集：アプリの仕組み 多くの人がこれを私がアプリをどのように機能させたいかを尋ねたので： ユーザーがサインアップ 彼はログインしています 彼は無限のアイテムを作成できる彼の最初のコレクションisideを作成します アイテムにはさまざまなタイプがあり、タイプごとに異なるデータをデータベースに保存する必要があり、アイテムのタイプを追加または変更できます ユーザーはその中に他のコレクションやアイテムを作成できます。 そのため、コレクションとその内部のアイテムのCRUDがあり、各コレクション/アイテムは特定のユーザーに参照されます MySQLの主な問題は、柔軟なスキーマがないことです。これを解決する方法があります（回避策？）？ NoSQLについて考えるときの唯一の疑問は、結合に関するものです。たとえば、特定のコレクションがあり、コレクション内のID = user_idフィールドを持つユーザーに関連するデータを取得したい場合 編集：MySQLを使い続けるためのアイデア 「items」テーブルに、オプション設定を含むフィールドを作成します。各設定は|で区切られます。または別のシンボル。 次に、各アイテムのオプション設定の構造をどこかに保存します。たとえば、「ノート」アイテムタイプには、MySQLからデータを取得するときに、2つのオプション設定「color」と「strange_setting」が必要です。オプション設定のフィールドを配列の最初の項目が「色」用であることを認識する配列など。 どう思いますか？その解決策に問題がありますか？他にアイデアはありますか？

9 database  mysql  nosql  rdms  mongodb 

休業。この質問には、より焦点を当てる必要があります。現在、回答を受け付けていません。 この質問を改善してみませんか？質問を更新して、この投稿を編集するだけで1つの問題に焦点を当てます。 5年前休業。 私はMongoDBの使い方を学んでいるだけで、他のプログラマーと話し合うときに、従来のRDBMSと比較してNoSQLが優れた選択肢である理由の簡単な例が必要です。 たとえば、大量のトラフィックを含むブログは関係的に表すことができますが、パフォーマンスのチューニングとテーブル間の結合が必要になります（完全な非正規化が使用されていると想定）。一方、MongoDBでは、1つのコレクションから直接取得して同じ効果を得ることができます。 しかし、私が他のプログラマーから得ている反応は、「なぜそれをリレーショナルに保ち、後で簡単なキャッシングを追加しないのか」です。 MongoDBが実際に輝き、リレーショナルデータベースがはるかに速くフォールオーバーするという、それほど単純な例はありませんか？プロジェクト/システムが小さければ小さいほど、意見の不一致の余地が少なくなるため、優れています。 ブログの例の複雑さの線に沿った何かが本当に役立つでしょう。 ありがとう。

8 relational-database  mongodb