Niet altijd leidt normalisatie tot op het punt van de dood tot prestatiehits, maar het is waar dat ik persoonlijk niet dezelfde normalisatie op MongoDB toepas als bij SQL.
Als u op de hoogte bent van de genormaliseerde formulieren ( http://en.wikipedia.org/wiki/Database_normalization ) Ik denk graag dat MongoDB naar 1NF gaat en dan weer teruggaat naar gedenormaliseerd.
O ja, dat doen we. Updaten is lastig als de gegevens verkeerd worden gedupliceerd.
Laat me je een voorbeeld geven:category en product twee afzonderlijke entiteiten zouden zijn, valt niet te ontkennen. Deze twee entiteiten zijn genormaliseerd (de herhalende gegevens van product is voortgekomen uit category ). Een andere manier van denken is:Gaan alle producten maar in één categorie?
Dus op entiteiten op het hoogste niveau zijn, zoals u kunt zien, dezelfde regels relatief van toepassing, waarbij 1NF gemakkelijk kan worden toegepast op MongoDB.
Op het eerste gezicht wil je natuurlijk niet elk product apart opslaan binnen elke categorie (ik heb nee geantwoord op de vraag hierboven), dus je zou natuurlijk categorieën en producten willen scheiden.
Normaal gesproken zou je hier een veel-op-veel-relatie hebben met een middelste genormaliseerde tabel. Dit is waar de-normalisatie van pas kan komen. Je kunt zeggen dat een categorie een lijst heeft met producten die uniek zijn voor die categorie, dus je zou de veel-op-veel relationele tabel in de categorierij als een lijst kunnen de-normaliseren (of andersom in de productrij). Dit zal geen duplicatie genereren aangezien die lijst uniek is voor die categorie (meer dan waarschijnlijk). Dit betekent natuurlijk dat de categorie of producten een lijst bevatten _id s van de gerelateerde rij in plaats van het object zelf.
Er zijn momenten waarop duplicatie nodig is, voornamelijk voor optimalisatie of omzeilingen voor het niet hebben van JOIN's; deze regel is ook van toepassing op SQL als je ooit een site hebt gemaakt die groot genoeg is.
Typische gebruiksscenario's van duplicatie zijn aggregatievelden van statistieken zoals een Facebook-posts aandelen en opmerkingen en misschien zouden zelfs de 5 laatste opmerkingen van die post ook worden gedupliceerd naar de berichtenrij.
Het is dus niet een kwestie van het negeren van schema-ontwerp, maar meer van het afstemmen op de kenmerken van MongoDB. Als je dat doet, zul je normaal gesproken merken dat je een goed schema ontwerpt.
Als toegevoegde referentie kun je hier verwijzen:http://docs.mongodb.org/ handleiding/core/data-modellering