Чихают ли рыбы? Не знаем, но точно знаем, что у современных баз данных куча нюансов. Погнали разбираться. Представь, собираешься деньги на подарок корешу и записываешь на бумажке, кто сколько скинул. Табличка с денежками организована, разделена по именам и сумме долга и имеет удобную структуру.
Ну вот оно и есть база данных. Теперь перемещаемся в цифровое пространство и заводим целый Excel-файл для этого дела. Стало удобнее, можно редактировать, сортировать и даже данные удалять.
Круто, но достаточно ли этого для роста этой базы данных? Неа Со временем данных становится так много, что админам приходится связывать их друг с другом А тут одним Excel-файлом уже не обойтись Представим, решили вы сделать свой аналог YouTube Как будете хранить инфу о пользователях? Список юзеров, каналов, кто на что подписан, лайки, балалайки и вот это все Сложить это все в одну таблицу будет неудобно и медленно работать Очевидно, надо разделить сущности на несколько таблиц юзеры, каналы и видосы. Найс, теперь свяжем данные между собой и добавим информацию о том, кто создал канал и на каком канале залили видео.
Вот, получили связанные таблицы. Связанные от слова «связь», а связь по-английски relation. А в IT-тусовке они так и называются реляционные базы данных. И это один из самых распространенных типов баз данных.
Ну, теперь с данными стало гораздо удобнее работать, и мы избежали большой таблицы с повторяющимися строчками, разбив все на несколько табличек. Такой процесс еще называется нормализацией, когда мы избавляемся от избыточных данных. Ну и как раз для этого мы ввели в каждой таблице специальное поле ID, которое идентифицирует каждую запись. Этот ID называется Primary Key, он же первичный ключ, а в таблице, которая будет на него ссылаться, он будет называться Foreign Key, или по-русски внешний ключ. Нырнем в детали и поговорим про типы связи между таблицами.
Первый тип. тип называется один ко многим или многие к одному и такие полигамные связи между таблицами в нашем примере у каждого видео может быть только один канал где она выложена но на одном канале может быть много видео поэтому в двух последних строках айди канал у вас повторяется верно отношение один к многим также можно рассматривать как отношение многим к одному зависимости от того с какой стороны вы на это смотрите но это как стакан который наполнен пол на липу снова ну и второй тип связи называется один к одному классические табличное отношение вообще это редко используемый тип тип связи обычно его делают для безопасности это как если на нашем аналоги youtube а мы разрешили бы создавать только один канал одному пользователю и в таблице с каналами айди создатели не могло повторяться так себе да в таком случае вообще можно было бы обойтись и одной таблицей ну и третий тип связи это многие к многим это когда у нас появляется промежуточная таблица связи которая как бы соединяет два отношения один к многим которые мы обсудили в начале разбора типов связей сложновато сложновато нам бросить шутить в наших видео это легко сейчас разберу Разберемся. Давайте сделаем таблицу с лайками и балалайками, где будем хранить ID пользователей и ID видео, к которым они поставили лойсы.
А вот так они связаны. Каждый пользователь может поставить лайк каждому видео. Ну а ты можешь поставить лайк этому видео, подписаться на канал и показать ролик друзьям. Теперь вопрос.
А где все это хранить, пацаны? Ну не в Excel же. И тут на сцену выходит термин SUBD.
Она же система управления базами данных. Это программа, которая позволяет создавать, редактировать и администрировать реалиционную базу. Ну и для управления всей этой петрушкой используется язык структурированных запросов SQL Или сиквел, как его иногда называют за рубежом Он очень простой и понятный Вот смотри, чтобы найти название всех видео с одного канала Чтобы найти название всех видео с одного канала, нам нужно выполнить следующий запрос То есть мы буквально говорим Выбери имена из таблицы видео, где айтишник канала равен 201 А если вы хотите взять данные из нескольких таблиц и объединить результат, то нужно использовать в запросе параметр join, от английского соединить.
Вот такая упрощающая жизнь админам аналогия с разговорным языком. Кстати, вместе с Олегом Филипповым, экспертом с 18-летним опытом в индустрии, мы сделали курс по SQL, где вместе и с нуля пройдем с тобой все этапы проектирования, администрирования, резервирования и масштабирования баз данных с использованием PostgreSQL, MSSQL и MySQL, чтобы получить оплачиваемые навыки DBA. администратора баз данных.
Так, SQL, конечно, позволяет добавлять, удалять и изменять данные и сами таблицы, но важно не забывать про схему баз данных, которая служит для описания структуры таблицы, ее полей и ограничений. Прикол в том, что если вам потребуется добавить или убрать столбец в таблице, то это изменение коснется вообще всех данных в таблице. Таким образом, если мы добавляем новый столбец, то он теперь будет присутствовать в каждой строке. Окей, для чего вообще нужны ограничения?
Для целостности твоих данных, амиго. Помнишь, мы рассказывали про первичный и внешний ключ? Так вот, благодаря им мы можем удалять... удостовериться, что в таблицу не попадает запись, которая ссылается на несуществующий ID-шник, или различные ограничения полей, которые не дадут записать дублирующие или пустые данные в нашу базу. А, и еще, транзакции.
Не-не-не те, которые банковские для покупки ссылков по акции. Это штука, которая позволяет как бы склеить несколько SQL-запросов в один. Ну вот представьте такую задачку.
Вставить данные в первую таблицу, а во второй указать ID вставленной записи. Если ты делаешь это без использования транзакции, а во время второго этапа у тебя отваливается интернет, то первая запись попадает в базу, а вторая нет. Появляется интернет, и ты с улыбкой на лице идешь снова выполнять эти запросы, только на этот раз получаешь ошибку, что такая запись уже есть, ибо первая это уже в базе. Пуф.
Уверен, это вызовет жжение в области стула и расстройство, что никому не нужно. А в случае использования транзакций, при получении ошибки мы откатимся до того момента, который был до начала транзакции, и стул в целом останется, и ваше психологическое здоровье. Уин-уин, так сказать.
А еще все эти радости помогают реализационным базам данных соответствовать так называемым требованиям АСИД. Играет музыка. которые нужны для сохранности данных.
Это очень важно в банковской отрасли или любой другой, где целостность и сохранность данных супер важны. Давай разберемся с аббревиатурой и уже побежишь на переменку. Ацемесити атомарность, или же, проще говоря, непрерывность. Это как раз про транзакции, которые мы обсудили только что.
Либо операция выполняется целиком, либо никак. Не нужны нам данные, записанные на полфедора. Консистенции, согласованность, данные, записываемые в таблицу, должны соответствовать всем выставленным правилам и ограничениям. Помнишь, мы говорили про первичные и внешние ключи, а также про уникальность?
Изолейшн изолированность. Если вы гоняете тонну транзакций одновременно, они не должны пересекаться и влиять друг на друга. Это очень важно для высоконагруженных баз. Дерабилити надежность. Если мы получили подтверждение, что транзакция выполнена, то значит наши данные в сохранности, даже если после этого произошел сбой.
Ну а в качестве примеров таких баз данных назовем Microsoft SQL Server, Oracle Database, MySQL, MariaDB. и PostgreSQL. Здесь мы поговорили только о реляционных базах данных, а есть еще нереалационные базы данных, которые называются NoSQL. Скорее беги зацени наш ролик про них.
Кстати, как думаешь, что является самой большой и высоко нагруженной базой данных в мире? Ответ пиши в комментариях. Записывай в базу данных YouTube отметку о том, что поставил лайк этому видео, вноси в свою таблицу подписок наш канал, покажи этот самый канал друзьям, ну и выполни вот этот простой запросик, который видишь сейчас на экране.
Пока! Кстати, рыбы не чихают.