Yes, you'd do something just like that. Document databases aren't relational databases. People need to think about solving the same problems a little differently. A lot of folks used to relational databases push for some perfect third normal form like disk space is still the major constraint in massive databases. For document databases, you design them based on how they are going to be used. Even if that means duplication of data like storing the lowercase version of something for indexing or rolling up your data into summary collections instead of performing those sorts of queries or collection aggregations on-demand.
Relational DBs often involve duplication for these kinds of use cases. Simple case-insensitive match can be handled with a custom index that's automatically derived from the col data, but there are more advanced cases where you need manually denormalized tables. Or sometimes it makes sense for performance reasons, but you only do this after you notice the normalized way being too slow.
Sure. It's not like all folks who lean on relational databases are third normal form zealots. But third normal form zealots exclusively come from a relational database background. Which makes sense.
