It's hard to believe, but I've been working on my startup for just over a year now, which sucks because, honestly, this product should have taken me about 3 months to build if I was able to do it full time. But, I have a job, a family and life is super-busy so I work on my startup when I can and that's not very often.

Anyway, back to the point of this post. I've mentioned Marten before, but now that I've been using it for a while, I want to re-iterate just how much I like it. Since my startup product isn't out in the wild yet, I can't yet speak to real-world performance, but in my testing so far, it's pretty fast. And the convenience of storing documents over using a relational model is great.

Of course, there are drawbacks to using a document store. For instance, in my app there are account reviews for transactions. So you sell a camera to Joe Jackson and you can review Joe after the sale goes down and Joe can review you regarding the transaction as well. Good old social proof. To facilitate this feature, I have a POCO called AccountReivew and it looks like this:

public class AccountReview : DocumentBase
        public Guid AccountReviewerId { get; set; }
        //TODO: these name properties will not be updated if the account changes their name. Fix that in the future
        public string AccountReviewerName { get; set; }
        public Guid AccountReviewedId { get; set; }
        public string AccountReviewedName { get; set; }
        public string Review { get; set; }
        public int Rating { get; set; }
        public bool Flagged { get; set; } = false;
        public DateTime? FlaggedOn { get; set; }
        public ReviewType Type { get; set; }
        public DateTime Created { get; set; } = DateTime.Now;
        public Guid ListingId { get; set; }

For the sake of convenience, I'm adding each account name to my document (this class will be serialized as a JSON document in Postgres). But, there's a problem with this class as noted in my comment. Because I'm saving this as a document with the account names included, if Joe Jackson changes the name of his account in the future, that change won't be reflected in any reviews he's associated with. The reviews will show his old account name unless they're updated.

I could fix this by excluding the account names and using the account id's to look up the accounts, grab them from the database and associate the names in my view model and then display them. But, that kind of sucks to have to pull both accounts from the database for this simple review and if this review is part of a long list of reviews, that's a lot of database chatter.

The other approach is to keep the names there just as I have them and write my UpdateAccountAsync method in such a way that I check all of my account review documents for Joe's account name and update them with the new name. It's a trade off and that's what I find a lot of when using a document database. There are a lot of small trade offs. It's a matter of deciding which path is better.

In this case, I think it's better to keep the names in the review class and update them if the account name changes because I don't think account names will change very often. I could be wrong. How would/have you approached this type of decision when using a document database?