Реляционная модель в сравнении с документоориентированной моделью #
- локальность данных (вложенность хранится рядом с объектом)
- гибкость схемы и лёгкое её изменения
- быстрое выполнение джойнов
- наличие оптимизатора запросов
- гарантия структуры данных
- нельзя обратиться непосредственно к вложенному элементу
- для изменения вложенного объекта нужно достать весь объект целиком
- хуже поддержка джойнов, чем у реляционных
- более громоздкие запросы
- сложнее изменить схему, чем в Документоориентированных
Языки запросов для данных #
Языки бывают декларативные и императивные.
В декларативных языках (SQL, например) описывается шаблон необходимых данных, но не описывается то, как они должны быть получены (за это отвечает оптимизатор и движок БД).
Императивные языки (JS, например) описывают, как получить данные из источника.
Как пример декларативных языков приводится ещё CSS - просто описывает ЧТО должно получить какие-то стили, но не КАК.
Есть ещё модель запросов MapReduce (+ её расширения) - описание на JS с помощью функций map и reduce. Map описывает, как должны быть преобразованы данные для функции reduce и порождает эти данные в формате ключ-значение, а reduce уже принимает эти данные и обрабатывает. Расширения предоставляют дополнительные возможности, например, фильтрацию исходной выборки.
Графоподобные модели данных #
Граф - совокупность вершин и соединяющих их рёбер.
В графовых БД сущности представлены вершинами, а связи между ними - рёбрами.
- ID
- множество входящих рёбер
- множество исходящих рёбер
- коллекции свойств (key-value)
- ID
- начальная вершина
- конечная вершина
- коллекция свойств (key-value)
БД - Neo4j, язык Cypher.
Есть ещё хранилища тройных запросов с языком SPARQL, которые по сути похожи на модель графов свойств.
Здесь же язык Datalog
Резюме #
Документоориентированные данные подходят для приложений, в которых данные имеют простую структуру, не сложнее древовидной (связи один-ко-многим).
Реляционные и графовые БД подходят для данных со связями много-к-одному и много-ко-многим, но если связей между данными много, а вложенность связей не определена заранее (что требует в SQL рекурсивных запросов), то для таких случаев больше подойдут графовые БД.