Въз основа на информацията, която предоставихте, бих препоръчал два възможни подхода, като се започне от една и съща основа:
Бих препоръчал този подход, ако:
- Имате висока кардиналност както на документите за статии, така и на платформите
-
Искате да можете да управлявате и двата обекта независимо, като същевременно синхронизирате препратки между тях
// articles collection schema { "_id": ..., "title": "I am an article", ... "platforms": [ "platform_1", "platform_2", "platform_3" ], ... } // platforms collection schema { "_id": "platform_1", "name": "Platform 1", "url": "http://right/here", ... }, { "_id": "platform_2", "name": "Platform 2", "url": "http://right/here", ... }, { "_id": "platform_3", "name": "Platform 3", "url": "http://right/here", ... }
Дори и този подход да е доста гъвкав, той си има цена - ако имате нужда както от данни за статия, така и от платформа, ще трябва да задействате повече заявки към вашия екземпляр на MongoDB, тъй като данните са разделени в две различни колекции.
Например, когато зареждате страница със статия, имайки предвид, че искате да покажете и списък с platforms , ще трябва да задействате заявка към articles collection и след това задействайте търсене в platforms collection за извличане на всички обекти на платформата, на които тази статия е публикувана чрез членовете на platform s масив в article document .
Въпреки това, ако имате само малко подмножество от често достъпни platform attributes които трябва да имате на разположение, когато зареждате article document , можете да подобрите platforms масив в articles collection за съхраняване на тези атрибути в допълнение към _id препратка към документите на платформата:
// enhanced articles collection schema
{
"_id": ...,
"title": "I am an article",
...
"platforms": [
{platform_id: "platform_1", name: "Platform 1"},
{platform_id: "platform_2", name: "Platform 2"},
{platform_id: "platform_3", name: "Platform 3"}
],
...
}
Този хибриден подход би бил подходящ, ако platform data attributes които често извличате, за да ги покажете заедно със специфичните за статията данни, не се променят толкова често.
В противен случай ще трябва да синхронизирате всички актуализации, които се правят на platform document attributes в platforms collection с подмножеството от атрибути, които проследявате като част от масива на платформите за документи за статии.
Що се отнася до управлението на списъци със статии за отделни платформи, не бих препоръчал да съхранявате N-към-N препратки и в двете колекции, тъй като гореспоменатият механизъм вече ви позволява да извличате списъци със статии чрез заявка към articles collection използвайки заявка за намиране с _id стойност на platform document :
Approach #1
db.articles.find({"platforms": "platform_1"});
Approach #2:
db.articles.find({"platforms.platform_id": "platform_1"});
След като представих два различни подхода, това, което бих ви препоръчал сега, е да анализирате моделите на заявки и праговете на производителност на вашето приложение и да вземете изчислено решение въз основа на сценариите, които срещате.
