Pull to refresh

Comments 21

Спасибо за статью, люблю подобный материал - не очень много, но достаточно структурировано и очень доходчиво.

Касательно реляционных баз данных - я бы сравнил их с комбайном/мультитулом - в них можно сделать все тоже, что и в других базах данных, но работать оно будет в среднем похуже - медленнее, и логика сложнее. Так как на Mysql написано очень много проектов (особенно веб-), то используется достаточно часто. Как собственно и php.

Для других типов баз данных не хватает примеров, аналогично реляционным БД, для бОльшего понимания.

Из-за того, что в реляционной базе информация находится в большом
количестве таблиц, отношения между которыми часто сложные, такая база не
подходит
для ситуаций, когда результат в ответ на запрос к данным надо
выдавать очень быстро.

Вы вводите свою аудиторию (новичков) в заблуждение. Потом эти новички на голубом глазу транслируют все эти мифы на собеседованиях или даже в своей профессиональной деятельности.
В дизайне RDB нет ничего такого, что делает их принципиально медленными. Чаще встречается просто неграмотное использование. Да, делать аналитический запрос из нормализованных таблиц с 10 джойнами - плохая идея. Но это идея человека, а не RDB.

Спасибо за коммент! Я соглашусь. Я не очень удачно сформулировала то, что хотела сказать, я имела в виду, что "реляционная база не та база, которая используется, когда нужно выдавать ответы за милисекунды. Есть более быстрые структуры". Пока удалю этот абзац, надо подумать как переформулировать)

реляционная база вполне себе способна выдавать ответы за миллисекунды

Мне это тоже резануло глаз. Я сейчас посматриваю на некоторые запросы у себя. Да, есть тяжёлые, но если всё лежит в памяти, и план простой, и данных мало, то там можно получить что-то вроде: server processing time: 0 ms 800 µs.
Понятно, что я не учитываю всякие там «сетки» и остальные «IO», а именно рассматриваю фразу "есть более быстрые структуры".
UFO just landed and posted this here

Отношения между таблицами определяются с помощью primary key и foreign key.

В общем случае это неверное утверждение. От таблицы на стороне "один" не требуется наличия именно PRIMARY KEY, требуется только ограничение UNIQUE. Да, в 99% случаев используется именно PK, ибо он и накладывает ограничение уникальности, и присутствует в таблице намного чаще, чем UNIQUE INDEX.

Формально индекс требуется только для того, чтобы процесс проверки отношения был быстрым. Чисто теоретически и требование уникальности, и вообще требование наличия индекса - они избыточны, и введены именно из заботы о скорости работы. В подавляющем большинстве СУБД - как обязательные.

Foreign key – это столбец в таблице, который содержит primary key другой таблицы.

А вот это в корне неверно. Весьма частое заблуждение. Foreign key - это вообще не какая-то структура. Это правило. Правило, которое использует подсистема контроля целостности СУБД. Вот формулировка этого правила уже включает выражение, вычисленное на основании значений полей в текущей таблице, и ссылку на аналогичное выражение в другой таблице, а действие этого правила заключается именно в том, чтобы выражение в текущей таблице либо было NULL, либо присутствовало в списке значений выражения другой таблицы.

Индекс – это определенный столбец в таблице, по которому осуществляется поиск. 

Ну вообще-то совсем не так. Индекс - это, во-первых, отдельная структура, а в случае некластерного индекса отдельная физически, во-вторых, вовсе необязательно по одному столбцу. Композитные индексы вообще обычное дело, да и индексы по выражению тоже не сказать что экзотика (если СУБД таковые поддерживает, конечно).

Вопрос на засыпку: может ли реляционная СУБД быть колоночной?

(Вполне может, потому что реляционность и детали физического хранения данных никак не связаны.)

Не просто может, а бывает. Sybase IQ. И даже Oracle умеет в колоночное хранение. Это лишь два примера, что сразу пришли в голову.

Да их море. Но почему-то эта странная категория «колоночных баз» кочует из статьи в статью.

Ну так и я об этом же. Более того, скажем Hive это какая база, колоночная или нет? Оказывается это зависит от того, в каком физически формате хранится таблица — Parquet колоночный, а Avro нет. То есть это вообще не свойство СУБД, если на то пошло.

Потому что переводчики никак не договорятся о терминах, а начинающие писатели не дают себе труда разобраться.

Есть модель данных – wide column store. Это Google BigTable, Cassandra, ScyllaDB. И это не реляционные бд, по функциональности они эквивалентны документо-ориентированным.

А есть устройство физического хранения – columnar store. Это Exasol, Greenplum, ClickHouse. Ну и конечно пионер этого движения – Vertica. И вот эти-то базы как раз реляционные.

А для русскозяычных писателей то и другое – «колоночные БД».

Отношение это и есть таблица. В РСУБД (RDBMS), "реляционный/relation" означает "таблица".

Не "связи между таблицами", а "таблица".

В текстах про реляционные БД термин "отношение" лучше использовать именно как синоним "таблица", а не "связь между таблицами".

А можете пояснить, почему так? Мне это не интуитивно: таблица - это данные (и те сущности, список которых хранится в таблице). Да, бывают таблицы, в которых не сущность, а отношения (для многие-ко-многом), но из-за них все таблицы назвать отношениями? Ведь может быть такая вырожденная БД, где только одна таблица, и нет отношений (не с кем относиться).

Относятся не сущности/таблицы друг к другу. А колонки в строке. А точнее, атрибуты в кортеже. Тут надо думать об уникальности строки, о том, что один из атрибутов полностью определяет значение других атрибутов (мы называем такой атрибут первичным ключём) и т.д.

Каждый атрибут в кортеже имеет тип, точнее домен. Например, можно определить тип (домен) "паспорт". И класть всю информацию о паспорте человека в соответствующий атрибут (колонку).

В реальности, колонки могут хранить только ограниченный набор значений (строки, числа и т.д.), поэтому все атрибуты паспорта раскладываются на соответствующие колонки (мы всё ещё говорим о колонках в таблице "человек").

В реальности, паспорт выносят в отдельную таблицу и связывают таблицы через ключи. Это процесс нормализации.

Нормализация и денормализация (т.е. вносить данные обратно в колонки) это задача оптимизации.

Вобщем, там много чего. Наверно, для того, чтобы грокнуть, надо перестать думать о сущностях и почитать Кодда или, может, Кайта. Старшие товарищи поправят, я не настоящий сварщик.

Не хотелось бы пополнять армию "хейтеров". А мой комментарий явно покажет, что я в армии задротов уже давно. Но выскажу свое мнение не претендуя на глубокую экспертность.

Невозможно ввести человека в суть баз данных без четкого понимания математической базы которая легла в основу продукта, ставшего потом коммерческим, независимо от того возможно ли физически эту теорию воплотить в жизнь.

Невозможно понять декларативную природу SQL не владея логикой предикатов и базовыми знаниями теории множеств (а это очень важно - использование декларативного стиля написания это первый шаг к оптимизации запросов). Не понимая, природу деревьев, в частности B-дерева, невозможно рассуждать о преимуществах индексных структур, хотя на B-tree тоже свет клином не сошелся.

Опять же нельзя упустить, что колончатые базы, как правило, используются для доступа к данным через OLAP-ориентированные запросы к денормализованным структурам данным (отсылка к реляционной теории и нормализации) и почему в этом случае мы получаем максимальный эффект от колончатой природы хранения данных. Причем использование одного из диалектов SQL, по прежнему остается востребованным интерфейсом взаимодействия пользователя с структурами хранения данных в колончатых СУБД.

Я ни в коем случае не утверждаю, что статья не имеет права на жизнь, но я бы больше назвал ее "Введение в базы данных для менеджера", когда нам надо на пальцах объяснить нетехническому человеку, за что он должен заплатить деньги. Увы, как введение для начинающего разработчика, она пока не дотягивает, поскольку не отвечает на вопросы "как" и "почему". Как по мне для технарей описание дорожной карты процесса обучения было бы гораздо более полезным введением (с обоснованием по каждому пункту, почему он должен приложить усилия для приобретения предложенных знаний). Но это сугубо ИМХО.

Я решила написать эту статью, потому что именно такой статьи мне очень не хватало несколько лет назад, когда я только начала карьеру в аналитике данных.

Однако же только на Хабре точно таких статей было больше одной.

Здравствуйте, а не подскажите какие-нибудь книги по введению в бд для новичков?

Также, одним из важных свойств реляционных баз данных является соответствие требованиям ACID

Мне кажется, что ACID это про "СУ", а не про "БД".

Пример про документные БД мне показался не очень отличающимся от примера про реляционные.

Sign up to leave a comment.

Articles