2016-11-21 12 views
2

私に何かが不足していますか?従来のデータベースと比較して、関係を同期させるためにORMでより多くの努力が必要なのはなぜですか。たとえば、次のようにします。マングースとMongoDB、関係との同期外

var UserSchema = new Schema({ 
    username: {type: String, required: true, index:{unique:true}}, 
    password: {type: String, required: true}, 
    events: [{type: Schema.Types.ObjectId, ref:'Event'}] 
}); 

var EventSchema = new Schema({ 
    _creator: {type:Schema.Types.ObjectId, ref: 'User'}, 
    post: {type: String, required: true} 
}); 

UserSchemaには、イベントスキーマが1人のユーザー作成者に属する多くのイベントがあります。

.delete(function(req, res){ 
     Event.remove({ 
      _id:req.params.event_id 
     },function(err,response){ 
      if(err) 
       res.send(err); 
      res.json({message:'Successfully Deleted'}); 
     }); 
    }); 

私がイベントを作成し、作成者などのユーザーオブジェクトを追加する場合、それは成功したテーブルを結合するが、私は、イベントを削除した場合。イベントは表示されなくなりますが、IDはユーザークエリの下に表示されます。以下は

は私のユーザーのクエリは、私が

[ 
    { 
    "_id": "5831be814f8df40646fed954", 
    "password": "$2a$10$MNbwpj0qi9.rhEPmCHe5mOc8crrEo/CwbxVSbjjLSw28GdcQ0O6Um", 
    "username": "klaus", 
    "__v": 1, 
    "events": [ 
     "5831c216a3d6810692bdf381" 
    ] 
    } 
] 

がどのように私は、ユーザーのスキーマからそのIDを削除するに行くか、ユーザーに属しているイベントを削除した後にどのように見えるのですか?イベントスキーマとユーザースキーマをリンクしないほうがよいでしょうか?なぜこれはお尻の痛みで、なぜこれは未来ですか?

+0

[私の回答](http://stackoverflow.com/questions/40723019/mongoose-and-mongodb-out-of-sync-with-relationships/40723300#40723300)を更新しました。私はそれが今より役立つことを願っています。 – rsp

答えて

2

これはORMではなく、結合がなく、テーブルがありません。 Mongoをリレーショナルデータベースのように使用しようとしていますが、そうではありません。

あなたの質問に「なぜこれはお尻に痛みがあり、これはなぜ将来ですか? - Mongoをドキュメントストアとして認識し、それをそのまま使用しない限り、あなたはいつも失望します。

今、いくつかの背景。リレーショナルデータベースでは、別のリレーションで参照されているタプルを削除できないか、または削除することができますが、操作がカスケードして削除されることを保証できる外部キー、制約およびトリガーを持つことができます。キーが存在しないため、データベースの矛盾が発生します。これは通常1つのトランザクションでも行われるため、データの一貫性のないビューが誰にも表示されないようにすることができます。

モンゴでは、このような保証はありません。 validationsがありますが、それらはbypassedです。

別のドキュメントへの参照を格納する場合、それは単なるStringまたはObjectIdインスタンスで、データベースには存在していなくてもかまいません。しかし、クライアントサイドのアプリケーションは、参照を解決するためにフォローアップクエリを発行する必要があります。つまり、正規化されたデータモデルでは、サーバーへのより多くのラウンドトリップが必要になる可能性があります。 (Normalized Data Modelsを参照)つまり、関係の有効性が強制されるだけでなく、実際の「参加」はデータベース内ではなくクライアント側で、別のクエリ(可能な競合条件で)で行われます。

さらに、トランザクションがないため、1つのアトミック操作でドキュメントとそのすべての参照を削除することはできません。しかし、たとえ可能であったとしても、まだMongoにはスキーマはありません。したがって、ObjectIdをフィールドの値として持つと、Mongoはどのコレクションが参照されるべきか分かりません。探す。

これは、別のドキュメントで参照される可能性のあるデータを削除した後、手動でクリーンアップする必要があることを意味します。しかし、データベースは、削除しようとしている文書のObjectIdをどこに保存するかを教えてくれないので、そのことを知って、データベースを一貫性を保つことを確実にする責任があります。

今、スキーマの場合。 Mongoにはスキーマという概念はありません。モンゴースにはスキーマがありますが、モンゴにはありません。"MongoDBのデータにはという柔軟なスキーマがあります。コレクションは文書構造を強制しません。 (Data Modelingを参照してください)その "フレキシブルなスキーマ"はスキーマを全く持たないことを意味します。実際には、スキーマはMongooseのクライアント側にのみ存在します。偉大なMongooseスキーマを持つことができますが、複数のアプリケーションが同じデータベース(または同じアプリケーションの2つのバージョン)に接続している場合、これらのアプリケーションは矛盾したスキーマを持ち、データベースを黙って破損する可能性があります。

Mongoは、一貫した保証、トランザクション、外部キー、結合、強制スキーマ、および他のデータベースとの作業に精通している他の機能が必要ない場合にのみ使用するようアドバイスします。そうでなければ、それはあなたがそれを記述したときにいつも痛みになるでしょう。

+0

私はそれをドキュメントストアとして認識しています。しかし、開発者はこれをデータベースとして使用しますか?または私は間違っていますか?私はこれを答えとして受け入れることはできません。 – numerical25

+0

@数値25開発者はMongo **がデータベースであるためデータベースとして使用します。 **リレーショナルデータベースではありません。ジョインもテーブルもトランザクションもなく、MongooseはObject Relational Mapperではありません。真剣に、Mongoは特に洗練されたデータベースではなく、あなたがそれがそうだと思うなら、あなたは失望します。あなたが "将来"を望むなら、RethinkDBかCassandraを試してみてください。また、良いデータベースが必要な場合は、Postgresに固執することもできます。真剣に、私はここで参考にしようとしている。あなたの質問に対する唯一の答えを投票することは、あなたの質問に対する答えを将来的に奨励する良い方法ではありません。 – rsp

関連する問題