![[Valid RSS]](images/valid-rss-rogers.png "Valid RSS")
This is a valid RSS feed.
This feed is valid, but interoperability with the widest range of feed readers could be improved by implementing the following recommendations.
<p>Now if you have a large number of attributes that you need to index for s ...
<article class="onebox-body">
<article class="onebox-body">
<?xml version="1.0" encoding="UTF-8" ?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/"> <channel> <title>Advice for modeling a database for multiple games</title> <link>https://www.mongodb.com/community/forums/t/advice-for-modeling-a-database-for-multiple-games/112594</link> <description>I have multiple games I want to store data for. The data for each player is stored in a single document with a UUID to identify it. The two options I have thought of so far is:1. Have one collection per game.2. Have one collection for all games. The problem with option 1 is that I do not know how I would get all stats for all games per player while having good performance. Sending a query to each collection simultaneously to get all their stats seems wrong, although I think this is the best option so far. For option 2, I would not be able to create indexes on the fields that needs to be indexed because the number of games and fields per game could be expanded at any time. It would also be very many read and write operations on a single collection which seems very wrong. Does anyone have any advice on this?</description> <language>en</language> <lastBuildDate>Thu, 11 Apr 2024 18:58:22 +0000</lastBuildDate> <category>Working with Data</category> <atom:link href="https://www.mongodb.com/community/forums/t/advice-for-modeling-a-database-for-multiple-games/112594.rss" rel="self" type="application/rss+xml" /> <item> <title>Advice for modeling a database for multiple games</title> <dc:creator><![CDATA[steevej]]></dc:creator> <description><![CDATA[ <p>This looks a lot like a ChatGPT created post. A lot of words, nothing really specific. May be you can elaborate.</p><p>I do not really the hybrid part of point 1. Player info into a player collection and game info in a game collection.</p><p>Could you provide examples of game-specific fields?</p><p>As for .3, how could we use MongoDB’s aggregation framework to retrieve relevant data across multiple collections?</p><p>By the way I flagged your other posts as spam and I started to follow you to catch your next attempt faster.</p> <p><a href="https://www.mongodb.com/community/forums/t/advice-for-modeling-a-database-for-multiple-games/112594/7">Read full topic</a></p> ]]></description> <link>https://www.mongodb.com/community/forums/t/advice-for-modeling-a-database-for-multiple-games/112594/7</link> <pubDate>Sun, 28 Jan 2024 15:16:39 +0000</pubDate> <guid isPermaLink="false">www.mongodb.com-post-112594-7</guid> <source url="https://www.mongodb.com/community/forums/t/advice-for-modeling-a-database-for-multiple-games/112594.rss">Advice for modeling a database for multiple games</source> </item> <item> <title>Advice for modeling a database for multiple games</title> <dc:creator><![CDATA[Jennifer_Lisa]]></dc:creator> <description><![CDATA[ <ol><li><strong>Consider Hybrid Approach:</strong> Create a separate collection for player data and a collection for each game. Store player-related data in the player collection and game-specific data in respective game collections. This allows for efficient retrieval of player stats while maintaining game-specific details.</li><li><strong>Use Indexing Wisely:</strong> For the player collection, focus on indexing fields crucial for player-related queries. For game collections, consider indexing game-specific fields. This balances performance without excessive indexing on a single collection.</li><li><strong>Optimize Query Patterns:</strong> Design your queries to minimize the number of database hits. Utilize MongoDB’s aggregation framework to efficiently retrieve relevant data across multiple collections, reducing the need for simultaneous queries.</li><li><strong>Keep Collections Lean:</strong> Avoid unnecessary duplication of data across collections. Store shared player information in the player collection and only game-specific details in game collections. This helps in managing data consistency and reduces storage overhead.</li><li><strong>Monitor and Scale:</strong> Regularly monitor database performance and adjust your approach based on evolving needs. If performance issues arise, consider sharding, caching, or other scaling strategies to ensure efficient handling of growing data volumes.</li></ol> <p><a href="https://www.mongodb.com/community/forums/t/advice-for-modeling-a-database-for-multiple-games/112594/6">Read full topic</a></p> ]]></description> <link>https://www.mongodb.com/community/forums/t/advice-for-modeling-a-database-for-multiple-games/112594/6</link> <pubDate>Thu, 25 Jan 2024 20:47:25 +0000</pubDate> <guid isPermaLink="false">www.mongodb.com-post-112594-6</guid> <source url="https://www.mongodb.com/community/forums/t/advice-for-modeling-a-database-for-multiple-games/112594.rss">Advice for modeling a database for multiple games</source> </item> <item> <title>Advice for modeling a database for multiple games</title> <dc:creator><![CDATA[steevej]]></dc:creator> <description><![CDATA[ <p>I flagged the first post as spam rather than the last one.</p><p>I do not see the option to undo my mistake.</p> <p><a href="https://www.mongodb.com/community/forums/t/advice-for-modeling-a-database-for-multiple-games/112594/5">Read full topic</a></p> ]]></description> <link>https://www.mongodb.com/community/forums/t/advice-for-modeling-a-database-for-multiple-games/112594/5</link> <pubDate>Tue, 25 Apr 2023 18:39:52 +0000</pubDate> <guid isPermaLink="false">www.mongodb.com-post-112594-5</guid> <source url="https://www.mongodb.com/community/forums/t/advice-for-modeling-a-database-for-multiple-games/112594.rss">Advice for modeling a database for multiple games</source> </item> <item> <title>Advice for modeling a database for multiple games</title> <dc:creator><![CDATA[Jussi_R1]]></dc:creator> <description><![CDATA[ <p>HI <a class="mention" href="https://www.mongodb.com/community/forums/community/forums/u/pavel_duchovny">@Pavel_Duchovny</a>,</p><p>Thanks for the good reference to Henriks problem. I have bit similar, and did some research about patterns.</p><p>I have a followup question and thought perhaps it would be ok to continue in this thread, feel free to move or ask me to create a new topic.</p><p>I’m tracking users progress like following. User has few paths to complete. Paths have few stages to complete that are basically different games.</p><p>The data is used to give feedback to the user and also for analytical purposes and exported to olap(bq).I was also thinking about having different games data<br>in their own collections, but Pavel didn’t suggest that approach. Different games amount would be less than fifty.</p><p>I was thinking something like following, but started thinking that maybe all the stage data should be as key-value pairs? Also if want at some point more detailed data about gameplay for analytical purposes,<br>maybe that data should be in its own collection to prevent not to fill 15 mb limit and because it is not accessed by the app?</p><pre><code class="lang-auto">"Paths":{ "PathOrder": [Path1, Path3, Path4, Path2] "Path1": { "Stage1": { "GameName": "SpeedDrill", "PlayTime":92, "FirstPlayTime": 168123123, "LastPlayTime": 168124567, "SpecData": {[ {"key": "Crashes", "value": 2}, {"key": "AvgSpeed", "value": 65}, {"key": "Laps", "value": 7} ]} "completed": false, "attempts": 1 }, "Stage2": { "GameName": "AccuracyDrill", ... } } "Path2": ...</code></pre> <p><a href="https://www.mongodb.com/community/forums/t/advice-for-modeling-a-database-for-multiple-games/112594/3">Read full topic</a></p> ]]></description> <link>https://www.mongodb.com/community/forums/t/advice-for-modeling-a-database-for-multiple-games/112594/3</link> <pubDate>Tue, 25 Apr 2023 08:33:24 +0000</pubDate> <guid isPermaLink="false">www.mongodb.com-post-112594-3</guid> <source url="https://www.mongodb.com/community/forums/t/advice-for-modeling-a-database-for-multiple-games/112594.rss">Advice for modeling a database for multiple games</source> </item> <item> <title>Advice for modeling a database for multiple games</title> <dc:creator><![CDATA[Pavel_Duchovny]]></dc:creator> <description><![CDATA[ <p>Hi <a class="mention" href="https://www.mongodb.com/community/forums/community/forums/u/henrik">@Henrik</a> ,</p><p>Having a collection per game doesn’t sound right. We have a known antipatterns of having to many collections and indexes and we should avoid it as much as possible.</p><p>The MongoDB locking is per document so writing similar objects to the same collection should not interfere with concurrency as long as you hit different documents.</p><p>Additionally, as your database grow and you wish going to sharding the deployment having single collection to be sharded makes more sense than lots of small ones which doesn’t.</p><p>You might consider having a hybrid solutions if the single collection doesn’t work like collection per month or per 6 months for all games.</p><p>Now if you have a large number of attributes that you need to index for search you may consider the attribute pattern for each game</p><aside class="onebox allowlistedgeneric" data-onebox-src="https://www.mongodb.com/blog/post/building-with-patterns-the-attribute-pattern"> <header class="source"> <img src="https://www.mongodb.com/community/forums/uploads/default/original/3X/e/0/e05510e24bc504d73dd7cea40fd3386920393e4b.png" class="site-icon" width="16" height="16"> <a href="https://www.mongodb.com/blog/post/building-with-patterns-the-attribute-pattern" target="_blank" rel="noopener">MongoDB</a> </header> <article class="onebox-body"> <div class="aspect-image" style="--aspect-ratio:690/258;"><img src="https://www.mongodb.com/community/forums/uploads/default/optimized/1X/e62fd5c92363774b8ecdd39ed568870e5047ec69_2_690x258.jpeg" class="thumbnail" width="690" height="258" srcset="https://www.mongodb.com/community/forums/uploads/default/optimized/1X/e62fd5c92363774b8ecdd39ed568870e5047ec69_2_690x258.jpeg, https://www.mongodb.com/community/forums/uploads/default/optimized/1X/e62fd5c92363774b8ecdd39ed568870e5047ec69_2_1035x387.jpeg 1.5x, https://www.mongodb.com/community/forums/uploads/default/optimized/1X/e62fd5c92363774b8ecdd39ed568870e5047ec69_2_1380x516.jpeg 2x" data-dominant-color="99A8AB"></div> <h3><a href="https://www.mongodb.com/blog/post/building-with-patterns-the-attribute-pattern" target="_blank" rel="noopener">Building with Patterns: The Attribute Pattern | MongoDB Blog</a></h3> <p>Learn about the Attribute Schema Design pattern in MongoDB. This pattern is used to target similar fields in a document and reducing the number of indexes.</p> </article> <div class="onebox-metadata"> </div> <div style="clear: both"></div></aside> <p>I suggest reading the following articles</p><p><a href="https://www.mongodb.com/article/schema-design-anti-pattern-summary/" class="onebox" target="_blank" rel="noopener">https://www.mongodb.com/article/schema-design-anti-pattern-summary/</a></p><p><a href="https://www.mongodb.com/article/mongodb-schema-design-best-practices/" class="onebox" target="_blank" rel="noopener">https://www.mongodb.com/article/mongodb-schema-design-best-practices/</a></p><p>Best<br>Pavel</p> <p><a href="https://www.mongodb.com/community/forums/t/advice-for-modeling-a-database-for-multiple-games/112594/2">Read full topic</a></p> ]]></description> <link>https://www.mongodb.com/community/forums/t/advice-for-modeling-a-database-for-multiple-games/112594/2</link> <pubDate>Fri, 25 Jun 2021 05:19:26 +0000</pubDate> <guid isPermaLink="false">www.mongodb.com-post-112594-2</guid> <source url="https://www.mongodb.com/community/forums/t/advice-for-modeling-a-database-for-multiple-games/112594.rss">Advice for modeling a database for multiple games</source> </item> <item> <title>Advice for modeling a database for multiple games</title> <dc:creator><![CDATA[Henrik]]></dc:creator> <description><![CDATA[ <p>I have multiple games I want to store data for. The data for each player is stored in a single document with a UUID to identify it. The two options I have thought of so far is:</p><ol><li>Have one collection per game.</li><li>Have one collection for all games.</li></ol><p>The problem with option 1 is that I do not know how I would get all stats for all games per player while having good performance. Sending a query to each collection simultaneously to get all their stats seems wrong, although I think this is the best option so far.</p><p>For option 2, I would not be able to create indexes on the fields that needs to be indexed because the number of games and fields per game could be expanded at any time. It would also be very many read and write operations on a single collection which seems very wrong.</p><p>Does anyone have any advice on this?</p> <p><a href="https://www.mongodb.com/community/forums/t/advice-for-modeling-a-database-for-multiple-games/112594/1">Read full topic</a></p> ]]></description> <link>https://www.mongodb.com/community/forums/t/advice-for-modeling-a-database-for-multiple-games/112594/1</link> <pubDate>Thu, 24 Jun 2021 13:14:29 +0000</pubDate> <guid isPermaLink="false">www.mongodb.com-post-112594-1</guid> <source url="https://www.mongodb.com/community/forums/t/advice-for-modeling-a-database-for-multiple-games/112594.rss">Advice for modeling a database for multiple games</source> </item> </channel></rss> If you would like to create a banner that links to this page (i.e. this validation result), do the following:
Download the "valid RSS" banner.
Upload the image to your own server. (This step is important. Please do not link directly to the image on this server.)
Add this HTML to your page (change the image src attribute if necessary):
If you would like to create a text link instead, here is the URL you can use:
