私は現在モンゴイドで水域をテストしており、これまでのところeコマースストアで開始しています. もちろん、mongoid にはトランザクションがないので、認証、承認、製品情報などを含むほとんどのアプリに mongoid を理想的に使用したいと思います。
ただし、トランザクションがないため、rdbms に戻す必要があります。rdbms は、金融取引を記録するためだけに使用されます。
これはレールで可能で、誰かがそれをやったことがありますか?
私は一般的にレールの経験が限られていますが、安全な部分をエンジンとしてマウントし、URL を secure.myapp.com または myapp.com/secure/ の下にスコープすると、ラックが物事を処理している間、ユーザーは ssl にリダイレクトされると思います共有セッションのように。
これは機能しますか？または、これを実装するより良い方法を見つけた人はいますか?
mongoDBと従来のRDMSを混在させることは可能ですが、ORMが異なるため、ActiveRecordオブジェクトがMongoDBオブジェクトと通信するようにする場合は、追加のコーディングが必要になる場合があります。MongoDBは複数のドキュメントにわたるトランザクションをサポートしていませんが、「トランザクション」アトミック更新をサポートしていることを覚えておいてください。つまり、更新するすべてのデータが1つのドキュメントに含まれていれば、心配する必要はありません。トランザクションについて。MongoDBは安全な更新もサポートしているため、データがn個の異なるレプリカサーバーに書き込まれ、ディスクに永続化されていることを確認できます。
HTTPSとHTTP間の共有セッションに関しては、これは心配する必要はありません。セッションストアは、MongoDB、MySQL、Memcached、または私の推奨事項であるCookieのいずれかとして定義します。ドメインを「.myapp.com」として定義している限り、Cookieは、プロトコルに関係なく、アプリケーションのすべてのサブドメイン間で共有されます。
最初の投稿者の回答と同様に、質問のレールの側面について直接コメントすることはできませんが、MongoDBはトランザクションの更新をサポートしています。システム全体をMongoまたはRDBMSに実装する方がおそらく簡単です。
本当の問題は、ここでmongoを使用する動機は何ですか？ドキュメントデータベースモデルから何を得たいと思っていますか？RoRオブジェクトを直接mongoにリッピングしたいだけですか？
（抽象的に）単なる提案ですが、オブジェクトを前もって厳密に定義し、その定義をRDBMSで表すこともできます。Mongoを使用する明確な動機がない場合は、おそらく多くの時間を節約できます。Mongoは素晴らしいテクノロジーですが、厳密なデータ構造を表すのではなく、データの並べ替えとデータのカタログ化に最適です（必ずしもそうすることができないわけではありませんが、ドキュメントデータベースを使用すると、それぞれのコンテンツの柔軟性が大幅に向上します。データベース内のオブジェクト）。
幸運を！