Очень краткое введение
Реляционные базы данных, такие как MySQL, SQLite или PostgreSQL, хранят данные в таблицах, вот и все. Вы можете думать о них как о чем-то вроде электронной таблицы Excel на стероидах. Чтобы построить отношения между объектами в разных таблицах, они используют реляционную алгебру, что означает, что какими бы ни были ваши данные и какие бы отношения между вашими моделями, вам нужно свести эти модели и их отношения к чистым таблицам строк и столбцов.
Хотя это может быть удобно, когда мы имеем дело с хорошо структурированными, стандартизированными и предсказуемыми данными, на самом деле это становится ограничивающим, когда наши отношения данных становятся более разнородными.
Вот тут-то и появляются нереляционные базы данных. Нереляционные базы данных, такие как MongoDB, хранят данные в коллекциях документов JSON. Вы можете думать о коллекции как о контейнере элементов JSON, обычно имеющих некоторые общие черты. Одной из наиболее важных характеристик является то, что базы данных NR не содержат схемы. Это означает, что вам не нужно заранее указывать схему и придерживаться ее впоследствии. На самом деле ничто не мешает вам создать коллекцию с элементами, не имеющими общих атрибутов. Это, очевидно, не лучшая идея, но в основном это иллюстрирует, как базы данных NR позволяют вам быть гораздо более гибкими с точки зрения структуры, которую может иметь каждый элемент в коллекции.
Эта гибкость обеспечивает лучшую масштабируемость и разделение базы данных, и именно поэтому многие интернет-компании, которым приходится иметь дело с действительно большими объемами неструктурированных данных, предпочитают делать это в базах данных NR. Одним из чрезмерно упрощенных способов выразить это является то, что, учитывая тот факт, что базы данных SQL отслеживают индекс своих элементов и, что наиболее важно, автоматически обрабатывают отношения между этими элементами, если вам нужно разделить вашу базу данных, отслеживая отношения становятся проблематичными. И хотя, по-видимому, сделать это с базой данных NR тоже не просто, тем не менее, это проще.
Вероятно, лучший способ оценить преимущества баз данных NR, особенно если вы относительно новичок в программировании, — это подумать о проблемах работы с сильно вложенными данными. Один простой способ представить себе это, как объясняется в статье Википедии для NoSQL, — представить, что у вас есть блог-сайт. Для этого у вас может быть коллекция, в которой хранятся все ваши сообщения в блоге, и вместо того, чтобы иметь другую «коллекцию» для комментариев к сообщению, вы можете фактически хранить эти комментарии внутри самого элемента сообщения в блоге, что упрощает их извлечение с помощью простой запрос.
Так какие недостатки? Что ж, как следует из их названия, нереляционные базы данных не очень хорошо отслеживают отношения. Это в основном означает, что вам нужно приложить дополнительные усилия, чтобы убедиться, что ваши данные согласованы между коллекциями. И хотя может показаться, что это не имеет большого значения, это определенно может стать таковым, когда вы имеете дело со сложными моделями и отношениями.
Итак, если вы обнаружите, что думаете, какую базу данных вам следует использовать для вашего следующего приложения, начните с четкого представления о том, что представляют собой ваши модели и каковы отношения между ними. Подумайте, насколько последовательными вы ожидаете их сохранение с течением времени и с какими объемами данных вы собираетесь работать. Кроме того, проведите собственное исследование, потому что я могу просто где-то ошибаться (в этом случае обратная связь более чем приветствуется).
