10s-denormalization.md.erb

---
title: Денормалізація
slug: denormalization
date: 0010/01/02
number: 10.5
sidebar: true
contents: Дізнаєтеся, що таке денормалізація.|Порівняєте Mongo з традиційними реляційними базами даних. |Дізнаєтеся, коли дані *не варто* денормалізовувати.
paragraphs: 15
---

Денормалізація даних означає, що дані не зберігаються у "звичайному" форматі. Іншими словами, денормалізація означає безліч копій одних і тих самих даних, але в різних місцях.

У попередньому розділі ми денормалізумали кількість коментарів в об’єкт з постом, щоб не запитувати всі коментарі з сервера кожен раз. З точки зору архітектури даних, ми могли би цьогому запобігти, адже в будь який момент можна порахувати правильну кількість коментарів, запитавши їх з бази даних. Це було би повільніше, але точніше.

Деормалізація часто означає додаткову роботу для програміста. У нашому випадку, кожен раз, коли ми добавляємо чи видаляємо коментар, нам також потрібно оновити відповідні пости, щоб їх поле `commentsCount` відібражало правильну кількість коментарів. По цій самій причині реляційні бази даних на кшталт MySQL презирливо дивляться в сторону такогго підходу.

З іншого боку, у реляційного підходу є і свої мінуси. Без параметра `commentsCount` нам довелося б запросити _всі_ коментарі з сервера кожного разу, коли нам треба було б порахувати їх кількість - те ж саме, що творилося у нас з самого початку. Денормалізація даних допомагає повністю уникнути цього.

<% note do %>

### Особлива Публікація

Насправді *можливо* створити особливу публікацію, яка буде відсилати тільки значення з кількістю коментарів - саме те, в чому ми зацікавлені.

З іншого боку, завжди варто зважувати складність створення подібної публікації проти складнощів підходу з денормалізації даних.

<% end %>

Звичайно, подібні міркування завжди повинні спиратися на завдання додатка, що розробляється. Якщо ви розробляєте код, в якому точність даних ставиться понад усе, можливо варто пожертвувати швидкістю роботи програми на користь цієї самої точності.

### Впроваджувані Документи або використання безлічі Колекцій

Якщо ви вже працювали з Mongo, ймовірно, ви здивувалися, коли ми створили окрему колекцію для коментарів. Замість цього ми цілком могли б впровадити лист коментарів прямо в документ з постом.

Виявляється, більшість вбудованих інструментів Meteor працюють набагато краще, якщо вони оперують на рівні колекції. Наприклад:

1. Функція-помічник `{{each}}` набагато ефективніша, коли вона працює з курсором (результатом запиту функції `collection.find ()`). Ця ж функція набагато менш ефективна, коли потрібно переглядати масив об'єктів, впроваджений у великий документ.
2. `allow` і` deny` працюють на рівні документа. З цієї причини фільтрування коментарів легко втілити, коли вони знаходяться в окремій колекції - і набагато складніше, якщо вони впроваджені в іншу колекцію.
3. DDP працює на рівні атрибутів першого рівня у документів. Це означає, якщо у `comments` є властивість` post`, то кожен раз, коли новий коментар доданий до посту, сервер буде посилати оновлений лист з усіма коментарями на всі підключені клієнти.
4. Контролювати публікації і підписки набагато простіше на рівні документів. Наприклад, якби ми хотіли розбити довгий список коментарів на кілька сторінок, це виявилося б складніше, якби коментарі не були збережені в своїй окремій колекції.

Mongo пропонує впроваджувати документи, щоб зменшити кількість запитів до бази даних. З іншого боку, якщо ми згадаємо про архітектуру Meteor - велика частина запитів відбувається на *клієнті*, де запити до MiniMongo відбуваються миттєво.

<% Note do%>

### Зворотний бік денормалізації

Є хороший аргумент, згідно з яким вам *не варто* денормалізовувати дані. Ми рекомендуємо прочитати наступний блогпост [Почему вам никогда не стоит использовать MongoDB] (http://www.sarahmei.com/blog/2013/11/11/why-you-should-never-use-mongodb/) від Sarah Mei.

<% end %>