-
Notifications
You must be signed in to change notification settings - Fork 30
/
10s-denormalization.md.erb
53 lines (34 loc) · 4.33 KB
/
10s-denormalization.md.erb
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
---
title: Desnormalización
slug: denormalization
date: 0010/01/02
number: 10.5
points: 10
sidebar: true
photoUrl: http://www.flickr.com/photos/ikewinski/9283093547/
photoAuthor: Mike Lewinski
contents: Comprenderemos qué es la desnormalización.|Compararemos Mongo con las bases de datos tradicionales.|Aprenderemos cuándo *no* debemos desnormalizar nuestros datos.
paragraphs: 15
---
Desnormalizar los datos significa no almacenar esos datos de una manera "normal". En otras palabras, significa tener múltiples copias de la misma porción de datos.
En el capítulo anterior, desnormalizamos la cantidad de comentarios dentro del objeto post para evitar tener que cargar todos los comentarios todo el tiempo. Teniendo en cuenta el modelado de datos, esto es redundante, ya que en su lugar podríamos simplemente contar el número correcto de comentarios en cualquier momento para averiguar su valor (dejando de lado las consideraciones de rendimiento).
Desnormalizar a menudo significa un trabajo extra para el desarrollador. En nuestro ejemplo, cada vez que agregamos o eliminamos un comentario además tenemos que acordarnos de actualizar el post en cuestión para asegurarnos de que el campo `commentsCount` siga siendo correcto. Esto es exactamente la razón por la cual las bases de datos relacionales como MySQL desaprueban esta técnica.
De todas maneras, la técnica normal también tiene sus desventajas: sin una propiedad `commentsCount`, necesitaríamos enviar _todos_ los comentarios todo el tiempo tan sólo para poder contarlos, que es lo que estábamos haciendo en un principio. Desnormalizar permite evitar esto último.
<% note do %>
### Una publicación especial
*Sería* posible crear una publicación especial que solo envíe la cantidad de comentarios que nos interesan (por ejemplo, la cantidad de comentarios en los posts que actualmente estamos viendo, haciendo más consultas al servidor).
Pero vale la pena considerar si la complejidad de dicha publicación superaría o no las dificultades creadas al desnormalizar…
<% end %>
Por supuesto, dichas consideraciones son específicas para cada aplicación: si estás escribiendo código donde la integridad de datos es fundamental, entonces evitar inconsistencias en los datos es de lejos más importante y de mayor prioridad que cualquier mejora de rendimiento.
### Incrustar Documentos o Usar Múltiples Coleciones
Si tienes experiencia con Mongo, podrás haberte sorprendido al ver que hemos creado una segunda colección solo para los comentarios: ¿por qué no simplemente integrar los comentarios en una lista dentro del documento post?
Resulta que muchas de las herramientas que Meteor nos da, trabajan mucho mejor operando a un nivel de colección. Por ejemplo:
1. El ayudante `{{#each}}` es muy eficiente cuando itera sobre un cursor (el resultado de `collection.find()`). Pero no lo es cuando itera sobre un array de objetos dentro un documento más grande.
2. `allow` y `deny` operan a nivel de documento, por consiguiente, facilita la tarea de asegurarse que cualquier modificación de un comentario individual es correcta. Esto sería mucho más complejo si operara a nivel de post.
3. DDP opera a nivel de los atributos "top-level" de un documento. Esto significa que si `comments` fuese una propiedad de un `post`, cada vez que un comentario fuese creado en un post, el servidor debería enviar toda la lista de comentarios actualizada para ese post a cada uno de los clientes conectados.
4. Publicaciones y suscripciones son mucho más fáciles de controlar a nivel de documentos. Por ejemplo, si quisiéramos paginar comentarios en un post sería muy difícil a menos que los comentarios estuviesen en su propia colección.
Mongo sugiere incrustar documentos para reducir la cantidad de consultas necesarias para buscar los documentos. De todos modos, esto es un problema mínimo cuando se tiene en cuenta la arquitectura de Meteor: la mayor parte del tiempo estamos consultando comentarios en el *cliente*, donde el acceso a la base de datos prácticamente no tiene coste.
<% note do %>
### Las Desventajas de la Desnormalización
Hay buenos argumentos sobre por qué *no deberías* desnormalizar tus datos. Para ver un buen caso contra la desnormalización, recomendamos [Por qué nunca deberías usar MongoDB](http://www.sarahmei.com/blog/2013/11/11/why-you-should-never-use-mongodb/) por Sarah Mei.
<% end %>