DOCS-201 merging in review comments from antoine

Author: Sam Kleinman

draft/use-cases/gaming-user-state.txt

@@ -140,6 +140,12 @@ There are a few things to note about this document:
    character record means you don't have to perform a separate query
    to fetch item details necessary for display.
 
+.. should note that using unbounded lists on items can be an issue, past 1000 entries should prob normalize.
+   Also if it ends up being much larger than core data itself, may want to split into own document, to better use RAM.
+
+.. Dont understand why the whole location info is stored here: lots of duplication and consistency issues.
+   Should normalize here and just store location name / coordinates
+
 Items
 `````
 
@@ -189,6 +195,9 @@ attribute of the ``character`` documents. The application will use
 ``location`` as the system of record for interactions between multiple
 characters or between characters and non-inventory items.
 
+.. should avoid storing player information in list here, it may grow and get updated too often if it's MMO.
+   Instead rely on index on location on the user collection
+
 Operations
 ----------
 
@@ -233,7 +242,7 @@ window, you need to merge the information from the ``armor`` and
 ``weapons`` attributes with information from the ``inventory``
 attribute.
 
-Suppose, for instance, that your code is displays armor data using the
+Suppose, for instance, that your code displays armor data using the
 following Jinja2 template:
 
 .. code-block:: html
@@ -391,6 +400,8 @@ and adds it to their inventory:
            { '_id': character['location']['id'] },
            { '$pull': { 'inventory': { 'id': item_id } } })
 
+.. should not require the $pull from location.inventory
+
 While the above code may be for a single-player game, if you allow
 multiple players, or non-player characters, to pick up items at the
 same time, you may introduce a problem when two characters attempt try
@@ -477,6 +488,10 @@ In this code, you:
   *in his own inventory*, update the character's inventory
   representation of the container.
 
+.. I think that the item documents should be immutable, describing types of times in the game.
+   Instances of items exists either in a user or location documents.
+   A backpack can contain other items, but if player picks up backpack he just get the contained items in his inventory.
+
 Moving the Character to a Different Room
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -507,6 +522,8 @@ location:
 This operation updates the old room, the new room, and the character
 document to reflect the new state.
 
+.. this should not change the location document using earlier changes
+
 Buying an Item
 ~~~~~~~~~~~~~~
 

draft/use-cases/serving-ads.txt

@@ -75,6 +75,8 @@ The schema for storing available ads consists of a single collection,
        ... ]
    }
 
+.. kind of confusing to call this collection "ad.zone", esp since there is only 1 and zone is just property
+
 For each (``site``, ``zone``) combination you'll store a list of ads,
 sorted by their ``ecpm`` values.
 
@@ -102,6 +104,10 @@ maximize the ad network's profits. This query resembles the following:
        ecpm, ad_group = ecpm_groups.next()
        return choice(list(ad_group))
 
+.. should be noted that here the list of ads get sorted client side for every call.
+   also full list gets pulled every time.
+   In case that the list is long, would be better to normalize, then use index on {site, zone, ecpm}
+
 Indexing
 ````````
 
@@ -225,6 +231,11 @@ This schema:
   timestamp. This facilitates rapid lookups of a stream of a
   particular type of event.
 
+.. probably should warn that storing impressions and clicks within user document can backfire.
+   Could grow very large, e.g. if it's a bot, and past 1000 will start slowing down db.
+   A more robust solution would keep each impression with its possible click in a separate document.
+   Could be in a capped collection if impressions do not need to be kept for long.
+
 Choosing an Ad to Serve
 ~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -411,3 +422,7 @@ customize the value of some keywords, but this is beyond the scope of
 this document. Because the ad service must sort all ads at display
 time, you may find performance issues if you if there are a large
 number of ads competing for the same display slot.
+
+.. here the processing will be done client side for every request.
+   This can become very expensive if a page gets hit a lot and has many possible ads.
+   Again here if normalize each ad, can use index on { site, zone, keywords }

draft/use-cases/social-networking-updates-and-profiles.txt

@@ -112,6 +112,10 @@ Consider the following features of this schema:
   sub-document, so that you may iterate the schema can evolve as
   necessary without affecting other fields.
 
+..  storing followers in a list would not work well at all in case like twitter, it would grow way too large.
+    should only store people that user is following, and index that to get follower list of a user.
+    Also could use a mapping table for further flexibility in relationship.
+
 Posts, of various types, reside in the ``social.post`` collection:
 
 .. code-block:: javascript
@@ -250,6 +254,11 @@ Consider the following features of this schema:
   certain number of comments because the :operator:`$size` query
   operator does not allow inequality comparisons.
 
+..  not sure this collection is useful, instead just use the post collection.
+    Posts should have an index on {user, time} and hence it is efficient to retrieve the wall.
+    Also wall may be scrolled down to get further items.
+    Dont think it's worth updating this document every time a user posts.
+
 The second dependent collection is is ``social.news``, which collects
 posts from people the user follows. These documents duplicate
 information from the documents in the ``social.wall`` collection:
@@ -263,11 +272,16 @@ information from the documents in the ``social.wall`` collection:
       posts: [ ... ]
    }
 
+..  This is probably too expensive.
+    If someone is followed by 1000+ people, that's a lot of documents to write to.
+    Instead system should use a $in query with people that user is following, sorted by time, with a limit.
+    This query is actually slow today but got improved a lot in 2.2 and there are good workarounds with 2.0.
+
 Operations
 ----------
 
 The data model presented above optimizes for read performance at the
-possible expense of write performance. To As a result, you should ideally
+possible expense of write performance. As a result, you should ideally
 provide a queueing system for processing updates which may take longer
 than your desired web request latency.