Интеллектуальный поиск и анализ информации

Город	Год основания	Население (чел)
Площадь (кв. км)
Санкт-Петербург	1703	5 131 942	1 439
Москва	1147	12 108 257	2 511
Екатеринбург	1723	1 412 346	495
Владивосток	1860	603 244	3 3116

Структура реляционной БД

Как альтернатива базам данных SQL где-то с начала 2000-х развивается направление NoSQL. В эту категорию объединяют все подряд – от иерархических и сетевых БД (где помимо иерархии предусмотрены дополнительные связи) до упрощенных БД ключ-значение и документарных баз данных без определенных параметров значений каждого элемента. Причина эволюции этой категории баз данных заключается в следующем: если у вас примитивные и однотипные наборы данных, а запросы касаются одной таблицы – то все ОК, и можно работать с SQL. Но если нет? Если нужно обратиться к 10, 100, 1000 таблиц, чтобы обработать запрос? Тогда реляционная база данных начинает работать медленно, а для написания запроса требуется немало строчек кода.

Пожалуй, наибольшей популярностью баз данных из категории NoSQL пользуются документарные БД, в частности, MongoDB. Они позволяют хранить объекты с произвольными наборами значений, что очень удобно – скажем, у платежного поручения будут одни поля, у приказа – другие. И все это хранится в одном и том же сегменте БД, без подразделения на примитивные таблицы. Однако и у этого подхода есть ограничения, о которых я расскажу парой абзацев ниже.
Наконец, отдельным классом, хотя их по традиции относят к NoSQL, стоят графовые базы данных. Они предлагают более естественное представление информации, основанное на той же логике, с которой мы сталкиваемся в реальной жизни. Не секрет, что каждая социальная сеть — это граф, да и сетевая модель БД – это тоже фактически граф, но без дополнительных возможностей, которые открывает современная графовая модель. Поэтому графовые базы данных представляют особый интерес для разработчиков.