TL; DR
Нормалізація в RDBMS дозволяє використовувати сили реляційної парадигми.
Денормалізація в NoSQL дозволяє використовувати сили парадигми NoSQL.
Довга відповідь
RDBMS чудові тим, що вони дозволяють моделювати унікальні структуровані сутності (з можливістю зміни або ні) та їх взаємозв'язки. Це означає, що дуже легко працювати на рівні сутності, оновлюючи їх властивості, вставляючи інший, видаляючи його тощо. Але це також чудово для динамічної агрегації: собака з її власником, собака з будинками, в яких вона проживає тощо. . RDBMS дає вам інструменти для полегшення всього цього. Він приєднається до вас, він буде обробляти атомні зміни для усіх об'єктів для вас тощо.
Бази даних NoSQL є чудовими, оскільки вони дозволяють моделювати напів / неструктуровані агрегати та динамічні об'єкти. Це означає, що дуже легко моделювати постійно змінюються сутності, сутності, які не мають всіх однакових атрибутів та ієрархічних сукупностей.
Для моделювання NoSql вам потрібно думати з точки зору ієрархії та агрегатів замість сутностей та відносин. Таким чином, у вас немає особи, адреси оренди та стосунків між ними. У вас є записи про оренду, які в сукупності для кожної людини визначають, які адреси оренди вони мали.
Вам потрібно запитати, які дані мені потрібно буде разом змінювати. Які дані логічно групують інші дані. У вашому випадку людина звучить як добрий сукупність. Яка логічна точка входу до решти даних.
Скажімо, NoSQL, зберігайте речі, у яких є інші речі, у яких є свої речі. Поверніть мені всю ієрархію речей. Дозвольте мені змінити це, як мені заманеться, тепер замініть всю ієрархію речі на мою змінену. Це майже все, що він дає вам. Чому це корисно? Якщо у вас є ієрархія речей, з якими ви завжди взаємодієте в цілому. Або якщо вам потрібно масово масштабувати.
Все, що вам надає RDBMS, вам доведеться вручну реалізувати в коді та у вашій схемі. Вам доведеться приєднатися до коду, якщо вам коли-небудь знадобиться сукупність агрегатів. Вам доведеться проаналізувати, якщо вам потрібна лише частина сукупності. Вам потрібно буде перевірити унікальність самостійно, якщо ви не хочете повторювати речі. Вам потрібно буде реалізувати власну логіку транзакцій під час роботи над агрегатами тощо.
Тож мати один великий стіл з усім необхідним - це шлях до NoSql. Оскільки атомність гарантована лише на цьому рівні, і продуктивність теж. Визначення ваших відносин на ранніх етапах важливо. Це те, що денормалізація.
У RDBMS денормалізація ефективно калічить ваш БД до NoSQL. Тож зазвичай потрібно протилежне, тобто нормалізація. Якщо ви цього не зробите, вам слід використовувати замість БД NoSQL. Якщо тільки вам не потрібно трохи обох.