Изменения
→Недостатки
== Сетевые базы данных ==
=== Сетевая модель данных ===
Предложена CODASYL в 1969.
====Представление данных====
== Реляционные базы данных ==
=== Реляционная модель данных ===
Самая популярная на данный момент модель данных. Отличается от предыдущих моделей заданием связей непосредственно в запросах, а так же наличием математической модели, позволяющей оптимизировать эти запросы. Предложена Э. Ф. Коддом в 1969.
====Структура====
* Данные хранятся в таблицах
=== Достоинства ===
* Простота представления объектов(из-за ориентированности модели данных на данную задачу)* Гибкая структура данных(так как можем хранить произвольные обьекты)
* Логичное направление ссылок (соответственно направлению в объектах)
=== Недостатки ===
* Сложность реализации(так как стандартный способ - трансляция в реляционную модель)* Сложность миграции схемы(что будет с объектами в базе, если мы захотим добавить им поле)
* Малая распространенность
=== Реализации ===
* Oracle Database Objects
== NoSQL ==
=== Документ-ориентированные ===
Мы можем быстро искать документы с произвольным содержанием.
==== Представление данных ====
* Слабоструктурированные документы
==== Пример ====
[[Файл:Intro history document.png|400px]]
=== Ключ-значение ===
Имеем маленькие значения и хотим их быстро идентифицировать по ключам. Если хотим ссылки - храним в значении массивы ключей. В данной модели мы умеем только по ключу доставать небольшое значение.
==== Представление данных ====
* Ключ
==== Пример ====
[[Файл:Intro history keyvalue.png|400px]]
=== Другие ===
==== Табличные ====
Если у нас отсутствуют сложные взаимосвязи между данными, мы можем хотеть оптимизировать использование одной большой таблицы.
* Одна большая таблица
* Хранится построчно
==== Столбчатые ====
Представим, что запись у нас содержит множество столбцов. Нужно ли нам каждый раз читать их все, как происходит в традиционном подходе? В таком случае нам выгодно хранить столбцы отдельно друг от друга.
* Одна большая таблица
* Хранится по столбцам
==== Графовые ====
Часто мы можем захотеть хранить графы объектов. Один из примеров - социальные сети.
* Граф объектов
* Данные в узлах
* Данные на ребрах
=== Достоинства ===
* Большой выбор(можем любое свойство предыдущих моделей обменивать на производительность)
* Гибкость (возникают проблемы, если появляется незапланированный сценарий использования)
* Скорость работы(но зависит от реализации)
=== Недостатки ===
* Множество вещей делается в коде(который надо будет проверять, поддерживать и обновлять)
* Нет оптимизатора
* Легко ошибиться (так как большинство вещей делается в коде)
