ћерион Ќетворкс

6 минут

ѕривет, сегодн€ расскажем что такое база данных и SQL. ” современных баз данных куча нюансов - погнали разбиратьс€.

ѕредставь - собираешь ты деньги на подарок корешу, и записываешь на бумажке, кто сколько скинул.

Ѕƒ и SQL

“абличка с денежками организована, разделена по именам и сумме долга, и имеет удобную структуру - ну вот оно, это и есть база данных!

јга, теперь, перемещаемс€ в цифровое пространство и заводим целый эксель файл дл€ этого дела. —тало удобнее, можно редактировать, сортировать и даже данные удал€ть!

 руто! Ќо достаточно ли этого дл€ роста этой базы данных? Ќет. —о временем данных становитс€ так много, что админам приходитс€ св€зывать их друг с другом, а тут одним эксель файлом уже не обойтись.

ѕредставим, решили вы сделать свой аналог ютуба, как будете хранить инфу о пользовател€х? —писок юзеров, там, каналы, кто на что подписан, лайки и вот это все. —ложить это все в одну таблицу? Ѕудет неудобно и медленно работать. ќчевидно, надо разделить сущности на несколько таблиц - юзеры, каналы и видосы:

Ѕƒ и SQL

“еперь св€жем данные между собой и добавим информацию о том, кто создал канал, и на каком канале залили видео.

Ѕƒ и SQL

јга, получились св€занные таблицы. —в€занные, от слова св€зь. ј св€зь, это по-английски relation. ј в айти тусовке они так и называютс€ - рел€ционные базы данных, и это один самых распространенных типов баз данных. ≈ще есть нерел€ционные базы данных, о них подробнее можно прочитать в этой статье про NoSQL.

”ф, ну теперь с данными стало гораздо удобнее работать, и мы избежали большой таблицы с повтор€ющимис€ строчками, разбив все на несколько табличек. “акой процесс еще называетс€ нормализацией, когда мы избавл€емс€ от избыточных данных. Ќу и как раз дл€ этого мы ввели в каждой таблице специальное поле - ID, которое идентифицирует каждую запись. Ётот айди называетс€ Primary Key, он же Упервичный ключФ. ј в таблице котора€ будет на него ссылатьс€, он будет называтьс€ Foreign Key, или по-русски Увнешний ключФ.

Ѕƒ и SQL

Ќырнем в детали и поговорим про типы св€зей между таблицами. ѕервый тип называетс€ Уќдин-ко-многимФ или Умногие-к-одномуФ (One-to-Many или Many-to-One).

¬ нашем примере, у каждого видео может быть только один канал, где оно выложено, но на одном канале может быть много видео, поэтому в двух последних строках ID канала у нас повтор€етс€, верно?

ќтношени€ Ђодин-ко-многимї также можно рассматривать как отношени€ Ђмногие-к-одномуї, в зависимости от того, с какой стороны вы на это смотрите.

Ѕƒ и SQL

¬торой тип св€зей называетс€ Уодин-к-одномуФ (One-to-One) - классические табличные отношени€. ¬ообще, это редко используемый тип св€зи, обычно его делают дл€ безопасности. Ёто как если на нашем аналоге ютуба, мы разрешили бы создавать только один канал одному пользователю и в таблице с каналами ID создател€ не могло повтор€тьс€. “акое себе, согласен? ¬ таком случае вообще можно было бы обойтись и одной таблицей.

Ќу и третий тип св€зей, это Умногие ко многимФ (Many-to-many). Ёто когда у нас по€вл€етс€ промежуточна€ таблица св€зей, котора€ как бы соедин€ет два отношени€ Уодин ко многимФ, которые мы обсудили в начале разбора типов св€зей.

ƒавайте сделаем таблицу с лайками балалайками, где будем хранить ID пользователей и ID видео, к которым они поставили лайк:

ј вот так они св€зан: каждый пользователь может поставить лайк каждому видео.

Ѕƒ и SQL

“еперь вопрос - а где все это хранить? Ќе в экселе же. » тут на сцену выходит термин —”Ѕƒ, она же система управлени€ базами данных - это программа, котора€ позвол€ет создавать, редактировать и администрировать рел€ционную базу.

Ќу и дл€ управлени€ всей этой петрушкой используетс€ €зык структурированных запросов, SQL (Structured Query Language) эскюэль или сиквел, как иногда его называют за рубежом.

ќн очень простой и пон€тный, вот смотри - чтобы найти названи€ всех видео с одного канала, нам нужно выполнить следующий запрос:

SELECT name FROM videos WHERE channel_id = 201

“о есть мы буквально говорим: выбери (SELECT) имена из (FROM) таблицы видео, где (WHERE) айдишник (ID) канала равен 201.

≈сли вы хотите вз€ть данные из нескольких таблиц и объединить результат, то нужно использовать в запрос параметр JOIN (от английского соединить). ¬от така€ упрощающа€ жизнь админам аналоги€ с разговорным €зыком.

“ак, SQL конечно позвол€ет добавл€ть, удал€ть и измен€ть данные и сами таблицы. Ќо важно не забывать про схему базы данных (Database schema), котора€ служит дл€ описани€ структуры таблицы, ее полей и ограничений. ѕрикол в том, что если вам потребуетс€ добавить или убрать столбец в таблице, то это изменение коснетс€ вообще всех данных в таблице, таким образом если мы добавл€ем новый столбец, то он теперь будет присутствовать в каждой строке.

Ѕƒ и SQL

ќкей, а дл€ чего вообще нужны ограничени€? ƒл€ целостности твоих данных.

ѕомнишь мы рассказали про первичный и внешний ключ? “ак вот, благодар€ им мы можем удостоверитьс€, что в таблицу не попадет запись, котора€ ссылаетс€ на несуществующий айдишник. »ли различные ограничени€ полей, которые не дадут записать дублирующие или пустые данные в нашу базу (Not NULL и Unique).

» еще: транзакции. Ёта штука, котора€ позвол€ет как бы склеить несколько SQL запросов в один.

Ќу вот представь такую задачку: вставить данные в первую таблицу, а во второй указать ID вставленной записи. ≈сли ты делаешь это без использовани€ транзакций, а во врем€ второго этапа у теб€ отвалитс€ интернет, то перва€ запись попадет в базу, а втора€ нет. јга, по€вл€етс€ интернет, и ты с улыбкой на лице идешь снова выполнить эти запросы, только на этот раз получишь ошибку, что така€ запись уже есть, ибо перва€ то уже в базе! ј в случае использовани€ транзакций, при получении ошибки, мы откатимс€ до того момента, который был до начала транзакции.

ј еще все эти радости помогают рел€ционным Ѕƒ (базам данных) соответствовать так называемым требовани€м ACID, которые нужны дл€ сохранности данных - это очень важно в банковской отрасли, или любой другой, где целостность и сохранность данных супер важны.

ƒавай разберемс€ с аббревиатурой:

  • Atomicity Ч атомарность, или же проще говор€, непрерывность: это как раз про транзакции, которые мы обсудили только что. Ћибо операци€ выполн€етс€ целиком, либо никак.
  • Consistency Ч согласованность: данные, записываемые в таблицу должны соответствовать всем выставленным правилам и ограничени€м, помнишь, мы говорили про первичный и внешний ключи, а также про уникальность?
  • Isolation Ч изолированность: если вы гон€ете тонну транзакций одновременно, они не должны пересекатьс€ и вли€ть друг на друга. Ёто очень важно дл€ высоконагруженных баз
  • Durability Ч надежность: если мы получили подтверждение, что транзакци€ выполнена, то значит наши данные в сохранности, даже если после этого произошел сбой.

Ќу и в качестве примеров таких баз данных назовем: Microsoft SQL Server, Oracle Database, MySQL, MariaDB и PostgreSQL.


—кидки 50% в Merion Academy

¬ыбрать курс