To, co opisujesz, to znormalizowane dane. Normalizacja w bazach danych jest cechą relacyjnych baz danych. Zorientowane na dokumenty bazy danych bez sql, takie jak MongoDB, używają innego paradygmatu, w którym struktura dtaa jest oparta na paradygmacie doucmnet. W tym świecie dane są ułożone w dokumenty (struktury JSON). Możesz wskazywać na inne struktury, ale zawsze istnieje kompromis. Musisz zdecydować, jaki poziom nadmiarowości danych działa, ale to naprawdę jest problem wtórny. Twoim głównym priorytetem w świecie MongoDB jest ustalenie, co jest najbardziej sensowne w kontekście. Na przykład możesz mieć dokument reprezentujący fakturę z osadzonymi elementami zamówienia, ale także wskaźnik do oddzielnego obiektu klienta. Ale możesz również, w tej samej bazie danych, mieć dokument zaprojektowany wokół klienta, który ma zagnieżdżone nagłówki faktury, a nawet zagnieżdżone wiersze faktury, lub nagłówki faktury zagnieżdżone z liniami faktury zagnieżdżonymi wewnątrz lub kupionymi produktami, z lub bez informacji o katalogu produktów .
Łączenia są zazwyczaj drogie w świecie MongoDB, ale bogactwo danych przechowywanych na wiele sposobów w różnych celach jest cechą, którą warto wykorzystać - w odpowiednim kontekście.
Nie powinieneś widzieć MongoDB jako zamiennika relacyjnego DBMS, ale raczej jako część większego projektu poliglota (wielojęzykowego). Możesz także użyć innych narzędzi danych, takich jak Redis i Neo4J jako część tego świata, aby robić różne rzeczy.
Konie na kursy; MongoDB nie jest dla wszystkiego.