🚧 WIP 📝 Update Readme

README.md

@@ -2,10 +2,15 @@
 
 - [About](#about)
     - [🗂️DCM](#dcm)
+        - [`Trainer`](#trainer)
+        - [`Pokemong`](#pokemong)
+        - [`Move`](#move)
+        - [`Type`](#type)
     - [🧬UML Class diagram](#uml-class-diagram)
     - [🗺NoSQL Schema Versioning Strategy](#nosql-schema-versioning-strategy)
         - [Schema Versioning Pattern](#schema-versioning-pattern)
         - [Incremental Document Migration](#incremental-document-migration)
+    - [📇Indexes](#indexes)
     - [🐕‍🦺Services](#services)
     - [🌺Special requests](#special-requests)
         - [`Pokemong` by nickname](#pokemong-by-nickname)
@@ -46,15 +51,21 @@ Let's cover the entities and relationships in this Data Concept Model:
 These are the individuals who capture and train `pokemongs`. They can engage in battles with other `trainers.`
 
 * a `trainer` has fought between 0 and many `trainers`
+    * we will use *referencing*, since this is a reflexive relationship
 * a `trainer` owns between 0 and many `pokemongs`
+    * we will use *referencing with denormalizing*, since `pokemongs` have lifecycles of their own
 
 #### `Pokemong`
 
 These are the creatures that `trainers` capture and train. They can be trained or wild.
 
 * a `pokemong` is owned by 0 or 1 `trainer`
+    * we will use *referencing*, since `trainers` have lifecycles of their own, but no denormalizing, since no queries
+      need that
 * a `pokemong` has 1 or 2 `types`
-* a `pokemong` knows between 0 and 4 `moves`,
+    * we will use *embedding*, since `types` don't have lifecycles of their own
+* a `pokemong` knows between 0 and 4 `moves`
+    * we will use *referencing with denormalizing*, since `moves` have lifecycles of their own
 
 #### `Move`
 
@@ -62,14 +73,18 @@ These are the abilities or actions that a `pokemong` can perform. This covers th
 different `moves` can have different effects and powers depending on the type of the `pokemong` and the `move`.
 
 * a `move` can be known by between 0 and zillions of `pokemongs`
+    * we will let `pokemongs` refer to `moves`, and not the other way around
 * a `move` has 1 and only 1 `type`
+    * we will use *embedding*, since `types` don't have lifecycles of their own
 
 #### `Type`
 
 These define the elements or categories that a `pokemong` or a `move` can belong to.
 
 * a `type` can define between 0 and zillions of `pokemongs`
+    * see [`Pokemong`](#pokemong)
 * a `type` can define between 0 and zillions of `moves`
+    * see [`Move`](#move)
 
 <img src="./docs/mcd.png" alt="Data Concept Model" title="Data Concept Model">
 
@@ -195,6 +210,10 @@ allowing the schema migration to happen gradually over time.
 
 However, note that this strategy increases write operations to the database, which could affect application performance.
 
+### 📇Indexes
+
+// TODO pick it up here
+
 ### 🐕‍🦺Services
 
 Each entity (`Pokemong`, `Trainer`, `Move`) in the application has a corresponding service class. These service

docs/DB.md

@@ -19,11 +19,14 @@
 
 * _id: ObjectId
 * nickname: string?
+    * (_indexed_: this field already has a dedicated endpoint for a nickname search filter)
 * dob: date
+    * (_indexed_: this field already has a dedicated endpoint for a date of birth interval search filter)
 * level: int
 * pokedexId: int
 * evoStage: int
-    * (_indexed_: "species" is calculated as evoTrack[evoStage], and would often be queried)
+    * (_indexed_: "species" is calculated as evoTrack[evoStage], and would often be queried.
+      Besides, this field already has a dedicated endpoint for mapping evoStages with number of pokemongs at that stage)
 * evoTrack: array of strings (therefore "species" is evoTrack[evoStage], and "evoBase" is evoTrack[0])
     * (_indexed_: "species" is calculated as evoTrack[evoStage], and would be queried often)
 * trainer: ObjectId? (reference to a trainer) (but can be "wild" instead, if ref is null)