Document the different approaches we took wrt foreign key constraints

Signed-off-by: Pierre-Yves Chibon <pingou@pingoured.fr>

docs/datanommer_datagrepper/pg_timescaledb.rst

@@ -58,11 +58,40 @@ Finally, you can check that the extension was activated for your database:
 Findings
 --------
 
+Partitioned table
+~~~~~~~~~~~~~~~~~
+
 After converting the `messages` table to use timescaledb, we've realized that
 timescaledb uses table partitioning as well.
 This leads to the same issue with the foreign key constraints that we have seen
 in the plain partitioning approach we took.
 
+Foreign key considerations
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+For a better understanding on the challenges we've encountered with foreign key
+constraints, here is a graphical representation of the datanommer database:
+
+.. image:: _static/datanommer_db.jpeg
+        :target: _images/datanommer_db.jpeg
+
+So here are the issues we've faced:
+
+* To make the `messages` table a hypertable (ie: activate the timescaledb plugin
+  on it), the tables need to be empty and the data imported in a second step.
+* Once the `messages` table is a hypertable, we cannot add foreign key constraints
+  from the `user_messages` or `package_messages` tables to it. It is just not
+  supported in timescaledb (cf https://docs.timescale.com/latest/using-timescaledb/schema-management#constraints )
+* We tried creating the foreign key constraints before making the `messages` table
+  a hypertable and then importing the data in (tweaking the primary key and
+  foreign keys to include the timestamp, following https://stackoverflow.com/questions/64570143/ )
+  but that resulted in an error when importing the data.
+
+So we ended up with: Keep the same data structure but to not enforce the foreign
+key constaints on `user_messages` and `package_messages` to `messages`. As that
+database is mostly about inserts and has no updates or deletes, we don't foresee
+much problems with this.
+
 
 Open questions
 --------------