What you are describing is normalized data. Normalization in databases is a characteristic of relational databases. No-sql documented databases such as MongoDB use a different paradigm in which you structure dtaa around the doucmnet paradigm. In this world, data is organized into documents (JSON structures). You can point to other structures, but there is always a trade-off. You have to decide what level of data redundancy works, but this is really a minor issue. Your first priority in a world like MongoDB is to figure out what makes the most sense in the context. For example, you may have a document representing an invoice with embedded items, as well as a pointer to a separate customer object. But you can also create in the same database a document created around a client that has nested invoice headers or even nested invoice lines or invoice headers nested in invoice lines nested inside or in products purchased with or without catalog information her.
Connections are generally expensive in the MongoDB world, but the wealth of data stored in several ways for a variety of purposes is a function that should be used in the right context.
You should not see MongoDB as a replacement for a relational DBMS, but rather as part of a larger polygonal (multilingual) persistence project. You can also use other data tools like Redis and Neo4J as part of this world to do different things.
Horses for courses; MongoDB is not for everything.