Дизайн на схема на база данни Mongodb със споделени данни

Вашето предизвикателство идва от факта, че Prop_Info трябва да се извлече и от двете заявки. Това затруднява намирането в коя колекция Mongo трябва да живее.

В MongoDB вие създавате схемата на вашия документ с идеалната цел един документ да съдържа цялата информация, от която се нуждаете, като имате предвид вашите модели на заявки. В случай, че трябва да имате същите данни D (като Prop_Info във вашия случай), върнат от две отделни заявки срещу две отделни колекции A и B , трябва да избирате между следните три стратегии:

1. Дублиране на D в документите и на двата A и B и наложете последователност с вашия код. Това обикновено е дизайнерският избор на системи с висока производителност, които искат да премахнат необходимостта от второ запитване, дори ако това идва с цената на допълнителна сложност на кода от страна на вмъкване/актуализация и с някои потенциални проблеми с последователността, тъй като Mongo не е ACID.

2. Поставете D в A и съхранява препратка (DBRef или някаква друга комбинация от идентифициращи полета) в B така че да можете да стигнете до него с второ запитване. Това обикновено е изборът на дизайн, когато броят на заявките към A надвишава броя на заявките към B . Той запазва D локално към по-често търсената колекция. В този шаблон за проектиране на схема трябва само да направите втора заявка, когато заявите B .

3. Поставете D в нова колекция C и направете второ запитване към него от двете A и B . Това обикновено е изборът на дизайн в лицето на много несигурни бъдещи изисквания, при които не е ясно какви ще бъдат компромисите, ако изберете (1) или (2) по-горе. Това е най-„подобната на релация“ схема и тази, която ще ви принуди да направите втора заявка, когато заявите и двете A и B .

Коя стратегия ще изберете зависи от вашия домейн, моделите на заявките, поддръжката, която получавате от вашата рамка за обектно-релационно картографиране (ORM) (ако използвате такава) и не на последно място, вашите предпочитания.

В ситуациите, които съм срещал, никога не съм избирал (3). Използвал съм (1) в ситуации с висока производителност (системи за анализ). Използвал съм (2) навсякъде другаде, тъй като моделите за достъп до заявките направиха очевидно къде трябва да живеят „споделените“ данни.

След като изберете стратегията си, ако все още имате нужда от помощ, публикувайте друг SO въпрос, който конкретно се фокусира върху проблема с дизайна на схемата, предвид избраната стратегия.

Три последни съвета:

1. Ако споделените данни D има кратност на връзката, по-голяма от 1, използвайте масив. Можете да индексирате цели масиви и да правите заявки точно вътре в масиви, като използвате $elemMatch .

2. За да актуализирате D в стратегия (1) или (2) използвайте атомния модификатор на MongoDB операции , много от които са проектирани да работят с масиви.

3. Този SO въпрос покрива модела на DBRef две заявки в отговора на @Stennie. (@Stennie работи за 10gen, маркерите на MongoDB.)

Късмет!