Domain Model has potentially challenging relationships between moods and journals.

[ROgbonna1]

Your domain model suggests a 1:M relationship between moods and journal_entries. As in one mood can belong to many journal_entries. In that case, your foreign key should live on the journal_entries table, not the mood table. As in, journal_entries should have a mood_id, not the other way around, right? ...Since each journal will have one mood (unless you want them to have more... one could image an M:M relationship between journal_entries and moods).

Additionally, you may want to consider the Enum data type in Postgres. If your app will forever have a defined list of mood options that your users can choose from, this may be the best option to keep your domain model simple. However, I see a world where users could potentially generate their own moods, in which case having a moods table makes sense. And even if not, having each mood associate with it's own image may be reason enough to keep this table as is.

[Seal125]

We have our model as a 1:M, but the opposite of what you mentioned. One journal_entry can have one or many moods. Our idea is that the user would be able to openly type in one or more moods linked to that specific journal entry. Every mood is unique because it's a text input in their own journal entry.