No siempre, la normalización hasta el punto de la muerte inflige impactos en el rendimiento, pero es cierto que personalmente no aplico la misma normalización a MongoDB que a SQL.
Si conoce las formas normalizadas ( http://en.wikipedia.org/wiki/Database_normalization ) Me gusta pensar que MongoDB va a 1NF y luego vuelve a desnormalizarse nuevamente.
Oh, sí lo hacemos. Actualizar es una molestia si los datos se duplican incorrectamente.
Déjame darte un ejemplo:category y product serían dos entidades separadas, no se puede negar. Estas dos entidades están normalizadas (los datos repetidos de product ha sido lanzado desde category ). Otra forma de pensarlo es:¿Todos los productos solo existirán en una categoría?
Entonces, en las entidades de nivel superior, como puede ver, las mismas reglas se aplican relativamente con 1NF que se aplica fácilmente a MongoDB.
En el frente de la duplicación, por supuesto, no querrá almacenar cada producto por separado dentro de cada categoría (respondí no a la pregunta anterior), por lo que, naturalmente, querrá separar las categorías y los productos.
Normalmente tendría una relación de muchos a muchos aquí con una tabla media normalizada. Aquí es donde puede entrar la desnormalización. Puede decir que una categoría tendrá una lista de productos que son exclusivos de esa categoría, por lo que podría desnormalizar la tabla relacional de muchos a muchos en la fila de categoría como una lista. (o al revés en la fila del producto). Esto no generará duplicación ya que esa lista es única para esa categoría (más que probable). Por supuesto, esto significa que la categoría o los productos albergarían una lista _id s de la fila relacionada en lugar del objeto en sí.
Hay momentos en los que la duplicación es necesaria, principalmente para la optimización o soluciones para no tener JOIN; esta regla también se aplica a SQL si alguna vez ha creado un sitio lo suficientemente grande.
Los escenarios de uso típicos de la duplicación son campos de agregación de estadísticas, como publicaciones y comentarios de Facebook, y tal vez incluso los 5 últimos comentarios de esa publicación también se duplicarían en la fila de la publicación.
Por lo tanto, no se trata de ignorar el diseño del esquema, sino más bien de ajustarlo para las características de MongoDB. Normalmente, si hace eso, encontrará que, naturalmente, diseña un buen esquema.
Como referencia adicional, puede consultar aquí:http://docs.mongodb.org/ manual/núcleo/modelado de datos
