Listen IT

🎄 Ребят, поздравляю всех с Наступающим 2025ым!

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

Планы на 2025 есть, и среди них:
✅ Видео про Redis
✅ Видео про CORS
✅ Видео про все методы HTTP
✅ Видео про оркестровку и хореографию в микросервисах
✅ Видео про блокировки и дедлоки в БД
✅ Видео про менеджеров в IT
✅ Продолжим с лекциями по ML (да-да, мы про них не забыли, просто лектор был очень занят)
✅ Ряд видео про организацию процессов в IT и менеджмент в IT
...и многое другое - всё-таки уже под сотню видео в бэклоге статей и тем набралось

Что касается YouTube, то в 2024-ом с ним, конечно, были и продолжаются проблемы. Просмотры падают, многие переходят на ВК. Я пока переходить никуда не планирую - скорее, планирую больше развивать Телегу, но от YT никуда не уходить. Рекламы в YT станет меньше (тут для зрителей это только плюс), но это ничего страшного особо. Если кто-то хочет поддержать канал, то всегда есть юмани, бусти и звёздочки-реакции в ТГ ⭐️. Вижу, что некоторые зрители иногда поддерживают и скидывают немного доната - спасибо вам за это огромное!

С Новым Годом вас, ребят!

Виды нереляционных БД. Какие бывают NoSQL базы данных

Ранее мы писали о реляционных БД, сравнивали их с нереляционными. Познакомимся с NoSQL подробнее. Все ссылки кликабельны, нажмите на название СУБД и откроется статья из Хабра.

Нереляционные базы данных хранят данные без четких связей друг с другом и четкой структуры. Вместо структурированных таблиц внутри базы находится множество разнородных документов, в том числе изображения, видео и даже публикации в социальных сетях. Такие базы данных ещё называют NoSQL, так как они не поддерживают запросы SQL.

1️⃣ Ключ-значение (Key-value)
Предназначены для быстрых, почти мгновенных запросов для таких задач как кэш, отображение баланса и т.д.. Высокая скорость осуществляется за счет хранения данных по принципу ключ-значение, и в большинстве случаев благодаря работе в оперативной памяти. Записи хранятся и извлекаются с использованием ключа, который однозначно идентифицирует запись и используется для быстрого поиска данных.
👉 Примеры СУБД: Redis, Memcached, Tarantool.

2️⃣ Документо-ориентированные БД
Могут быть полезны, если нужно хранить много файлов/документов и вы не хотите задумываться о структуре хранения, иерархии, связях. Такие БД имеют структуру дерева: начинаются с корневого узла и может содержать несколько внутренних и листовых узлов.

Листовые узлы содержат данные, которые при добавлении документа заносятся в индексы, это дает возможность даже при достаточно сложной структуре находить путь к искомых данных. В отличие от хранилищ типа ключ-значение, выборка по запросу к документному хранилищу может содержать части большого количества документов без полной загрузки этих документов в оперативную память.
👉 Примеры СУБД: MongoDB.

3️⃣ БД временных рядов (TSDB)
Подходят, если есть упорядоченные по времени данные с временными метками, такие как метрики от инфраструктуры или данные датчиков. Часто используются для осуществления мониторинга различных метрик (будь то загрузка CPU, или показатели работы какого-либо датчика).
👉 Примеры СУБД: Prometheus, InfluxDB, Graphite.

4️⃣ Графовые БД
Применяются, когда нужно анализировать отношения данных, их связи или просто упростить запросы с километровыми Join, имеет смысл использовать графовые базы данных. Данные и их связи представляются как вершины и ребра графа соответственно. Таким способом можно легко представить денежные переводы (для определения различных мошеннических схем), связи в социальной сети и граф общения между операторами сотовой сети.
👉 Примеры СУБД: Neo4J.

5️⃣ Поисковые БД (Search Engines)
Подходит, если вам необходимо осуществлять поиск по большим объемам данных, особенно неструктурированным, как пример поиск по нескольким терабайтами логов.

Поиск по текстам работает на основе индексирования. Каждому слову/лемме/n-грамме присваивается индекс. Затем формируется структура вроде таблицы, где строки являются документом, а столбцы индексами. Поиск по индексу существенно быстрее, чем по совпадению по словам в документах.
👉 Примеры СУБД: Elasticsearch.

6️⃣ Объектно-ориентированные БД
Здесь информация представлена в виде объектов, прямо как в ООП. Объектно-ориентированные базы данных появились как способ нативной коммуникации кода написанного с использованием объектно-ориентированных языков с базой данных.
👉 Примеры СУБД: Db4o.

7️⃣ Колоночные БД (column family store)
Колоночные NoSQL-базы хранят данные по столбцам, а не по строкам, как в реляционных БД. Это упрощает добавление и удаление свойств, а также позволяет работать с данными без жесткой схемы. Колоночные БД быстро и экономно обрабатывают большие объемы информации для анализа, так как выгружают только нужные значения из столбцов.
👉 Примеры СУБД: Cassandra, Clickhouse.

📎 Ещё полезные материалы
1. Виды баз данных. Большой обзор типов СУБД
2. Базы данных: большой обзор типов и подходов. Доклад Яндекса
3. Модели данных в NoSQL
4. Использование memcached и Redis в высоконагруженных проектах
5. Как базы данных «ключ-значение» обеспечивают производительность и масштабируемость без границ
6. SQL и NoSQL. Правда ли одно лучше другого?

#бд

📣 Новое видео про оператор WITH в SQL!

Оно уже выходило пару дней назад, но решил перезалить, т. к. были опечатки в некоторых селектах.
Узнаем, какой синтаксис у WITH и что такое CTE и обобщённое табличное выражение. И в кратком формате (а то зачастил я что-то с роликами по 15 минут).

Аудио-версия, как всегда, постом выше.

📣 КЭШ!

В новом видео обсудим, что это, зачем это, а также пройдёмся по основным паттернам проектирования эффективного кэширования, разберём на примере.
Аудио-версия, как всегда, постом выше.

Домашнее задание всем посмотревшим/послушавшим - узнать, какие типы кэширования применяются у вас в компании. У нас кэш в браузере и прокси-кэш. Распределённого не припомню, но у нас и не сильно нагруженная система.

🗂 Во всю работаю над новым видео про кэш и подходы к проектированию кэширования (статья очень хорошая, кстати, интересная). А пока вот вам картиночку в рабочие чаты на разогрев.
Как у вас проходит оценка в команде?

🎙И аудио-версия вдогонку

📣 Не успели опомниться от HTMX, а я уже закидываю новое видео!

Автор написал статью, в которой выписал ответы на вопросы SQL, которые ему задавали на собеседованиях на Python-разработчика.
Так что в этом выпуске, но сжато по каждому пункту:
❓Преимущества NoSQL
❓ACID
❓Что такое нормализация
❓Что такое транзакция
❓Какие есть уровни изоляции
❓Блокировки БД
❓Масштабирование БД
❓Планировщик запросов

Про многое из этого я уже выпускал отдельные видео, но здесь сжато и в одном месте + есть кое-что, чего нет в полноценных видео.

🎙Чуть не забыл! Аудио-версия вчерашнего выпуска про HTMX.

📣 Новое видео про HTMX уже на канале!

В нём узнаем:
❓Что такое HTMX
❓Чем он лучше MPA и SPA
❓Какие у него недостатки
❓Можно ли не учить React и переходить на HTMX

P. S. обещал выложить на прошлой неделе, но задержался - зато на этой неделе будет сразу второе видео со шпаргалкой по вопросам SQL. Интересно?

🎙Продолжаю выкладывать аудио-версии старых выпусков с улучшенным качеством.
И сегодня на очереди коротенькое, но информативное видео про различия между REST и SOAP.

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

P. S. жду в комментариях того самого человека, кто будет кричать, что REST - это не обязательно HTTP) 🧠

🎓Уже в работе новое видео про HTMX, а также по секрету скажу, что после него будет ещё видео со шпаргалкой по частым вопросам по SQL. Ну а пока закину интересное для обучения проектированию веб-сервисов:

«Я в режиме реального времени поясняла структуру запросов / ответов в Postman и разбирала документацию в Swagger», — пишет аналитик, который прошел этот курс, а потом два технических собеседования в международные компании.

Если в 2024 году вы хотите:
— научиться выбирать стиль интеграции под вашу задачу;
— начать проектировать с нуля и описывать интеграции в современных стилях (API: REST, SOAP, gRPC и других, + брокеры сообщений);
— узнать как правильно собирать требования и моделировать в UML;
— подготовиться к собеседованию, решив более 100 заданий;
— запустить свой API на Python.

Значит этот курс для вас!

🚀 Начните с открытых бесплатных
уроков — переходите в бот курса и жмите «Старт»
👇
@studyit_help_bot

🚀 Скидка на курс
от канала — 1 000₽ на Stepik по промокоду LISTENIT3 до конца ноября.

🔎 Следующее видео уже в монтаже - оно будет про HTMX.
Ну а пока работа движется, закину перевод интересной шпаргалки из поста на LinkedIn от Alex Xu - какой стек технологий обычно используется в микросервисной архитектуре.

На картинке можете посмотреть диаграмму, которая показывает технологический стек для MSA на стадии разработки (pre-production) и уже на продакшн-среде.

▶️ 𝐏𝐫𝐞-𝐏𝐫𝐨𝐝𝐮𝐜𝐭𝐢𝐨𝐧
🔹 Определение API - устанавливает контракт между фронтендом и бэкендом. Для этого можем использовать Postman или OpenAPI.

🔹 Разработка - Node.js или React - это популярные фреймворки для разработки фронта, а Java/Python/Go для разработки бэка. Также нам нужно конфигурировать API gateway согласно нашему API-контракту.

🔹 СI/CD (Continuous Integration / Continuous Development) - JUnit и Jenkins используются для автоматического тестирования. Код упаковывается в Docker-образы и разворачивается (деплоится) в виде микросервисов.

▶️ 𝐏𝐫𝐨𝐝𝐮𝐜𝐭𝐢𝐨𝐧
🔹NGninx - классический выбор среди балансировщиков нагрузки. Cloudflare предоставляет CDN (Content Delivery Network - географически распределённую сетевую инфраструктуру).

🔹 API Gateway - мы можем использовать Spring Boot для гейтвея (сетевого шлюза), и использовать Eureka/Zookeeper для Service Discovery (служба, которая помогает сервисам динамически находить друг друга в сети).

🔹 Микросервисы разворачиваются в облаке. Тут у нас есть варианты: AWS, Microsoft Azure, или, например, Google GCP.

🔹 Кэш и полнотекстовый поиск - Redis тут будет стандартным выбором для кэширования пар ключ-значение. ElasticSearch используется для полнотекстового поиска.

🔹 Коммуникация между сервисами - для того, чтобы сервисы могли общаться друг с другом, мы можем использовать мессенджинговую инфраструктуру, например, с применением Kafka, либо использовать RPC.

🔹 Персистентность - мы можем использовать MySQL или PostgreSQL для реляционных БД, и Amazon S3 для хранилища объектов. Также можем использовать Cassandra для колоночного хранения данных, если нужно.

🔹 Управление и мониторинг - чтобы управлять таким большим количеством микросервисов, используются такие стандартные инструменты как Prometheus, Elastic Stack и Kubernetes.

Мне понравилась сводка, достаточно сжато технологии расписаны, есть что поизучать. Может, про что-то из этого видео записать, чего ещё нет на канале?

🤫 А вот и новый ролик про уровни изоляции транзакций!

Пока что только вам в ТГ по ссылке даю прямой доступ, потому что видео в пятницу выпускать, говорят, не очень хорошо. Так что на всех выпущу в понедельник, а пока что спешл для узкого круга, раз я обещал вам на этой неделе 🖥

В ролике узнаем:
❓Что это за уровни изоляции такие и зачем они нужны
❓Какие есть уровни изоляции
❓Что такое "аномалии" и какие они бывают
❓Чем крут MVCC и зачем он нам
И, конечно, всё на примерах.

Статья полностью моя, ссылочку на Habr прикладываю, если кому хочется посмотреть.
Аудио-версия, как всегда, постом выше.

https://youtu.be/yVlCjzJAOOo

Про блокировки и дедлоки будем делать видео?

🪫 Понимаю, что давненько не было никаких новостей, но, на самом деле, работа кипит: я написал отдельную статью по уровням изоляции транзакций в БД, потом переписал и дописал несколько блоков, чтобы там все было максимально понятно, записал аудио, перезаписал аудио, и вот половина видео уже закончена - на этой неделе очень постараюсь выложить. Работа, конечно, не щадит в последние недели, но что поделать. Пока посылаю только мем, но скоро будет неплохое видео - обещаю.

🎙Продолжаю выкладывать аудио-версии старенького с улучшенным звуком.

На очереди одно из первых видео на канале - HATEOAS.
Это, кстати, высший уровень зрелости RESTful, как завещал отец РЕСТа Рой Филдинг.

В выпуске говорится, что это пятая статья из цикла про REST, поэтому оставляю здесь ссылки на остальные четыре видео:

1️⃣ Введение в REST API за 7 минут
2️⃣ Различия REST и SOAP за 4 минуты
3️⃣ Что такое Contract First подход за 4 минуты
4️⃣ Что такое Code First подход за 4 минуты
5️⃣ Что такое HATEOAS за 4 минуты

Типы связей в БД. Нормализация

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

Сущности (таблицы) в БД не существуют изолированно друг от друга: между ними устанавливаются связи. Для организации связи используются внешние ключи. Например, таблица Заказы может быть связана с таблицей Книги через поле book_id в таблице Заказы, значения которого берутся из поля id таблицы Книги.

Связи между таблицами бывают следующих типов:

1️⃣ Один-к-одному (one-to-one) – одной записи в родительской таблице соответствует одна запись в дочерней. Например, человек может иметь только один паспорт и паспорт может принадлежать только одному человеку. Этот вид связи используют, если не хотят, чтобы таблица БД "распухала" от второстепенной информации, однако для чтения связанной информации в нескольких таблицах приходится производить ряд операций чтения вместо одной, когда данные хранятся в одной таблице.

2️⃣ Один-ко-многим (one-to-many) – одной записи родительской таблицы может соответствовать несколько записей дочерней. Например, преподаватель может вести несколько курсов, но каждый курс может вести только один преподаватель. Это самая классическая связь для реляционных БД.

3️⃣ Многие-ко-многим (many-to-many) – каждый экземпляр одной сущности может быть связан с несколькими экземплярами другой сущности и наоборот. Всякую связь "многие–ко–многим" в реляционной базе данных необходимо заменить на связь "один–ко–многим" (одну или более) с помощью введения дополнительных таблиц. Например, студент может записаться на несколько курсов и каждый курс может иметь несколько студентов. Следует добавить новую таблицу Расписание, которое будет связывать таблицы Студенты и Курсы.


Нормализация данных

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

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

Нормализация базы данных выполняется с помощью набора правил. Они называются нормальными формами. Выделяют около 8-ми нормальных форм, но на практике используются первые три. Каждая следующая НФ дополняет предыдущую.

Три нормальные формы:

1️⃣ Информация в каждом поле таблицы является неделимой и не может быть разбита на подгруппы: нет повторяющихся строк и все атрибуты атомарны (простые типы данных)

2️⃣ У таблицы есть первичный ключ, а все остальные поля зависят от всего первичного ключа, но не от его части (если первичный ключ составной)

3️⃣ Все неключевые атрибуты зависят только от первичного ключа и не зависят друг от друга


📎 Материалы

📑 Статьи
1. Разбираем базы данных и язык SQL. (Часть 5 — связи и джоины) — статья на JavaRush про связи в БД с примерами
2. Связи между таблицами SQL — обзор Максима Гритчина про виды джойнов и связей в БД
3. Простыми словами про нормализацию + аудио- видео- ряд
4. Что такое нормализация базы данных — от merion academy
5. Как привести данные в форму — блог Практикума

⏯ Видео
1. Моделирование данных за 9 минут — про типы связей
2. Базы данных. 1,2,3 нормальные формы (10 минут)
3. Нормальные формы базы данных. Три нормальных формы, нормализация и денормализация БД

#бд

📣 Наконец, видео про Web 3.0!

Обсудим:
❓Что такое Web 3.0
❓Какие ещё "версии" Интернета есть, и в чём они выражаются
❓Когда будет Web 3.0
❓Web 3.0 - это о крипте и NFT?
➕ бонусом интервью с обсуждением Web 3.0 и перспективы перехода к нему

Аудио-версия выпуска, как всегда для ТГ-подписчиков, постом выше.

🎙Пока я монтирую видео про Web 3.0, продолжу выкладывать аудио-версии старых выпусков, чтобы вы могли слушать их здесь с выключенным экраном в дороге.

А раз уж про VPN мы недавно вспоминали, то предлагаю теперь вспомнить выпуск про прокси-сервер. Там, кстати, обсуждаем, в чём же разница между ним и VPN. Аудио, конечно, с улучшенным звуком по сравнению с качеством в старом видео.

А у вас прокси или VPN?

🛠 Продолжаю выкладывать переводы постов-шпаргалок из LinkedIn от Alex Xu.

Сегодня обсудим 8 кратких советов по проектированию эффективного API:

🔹 Доменный подход (Domain Model Driven)
При проектировании структуры URL для RESTful API можно опираться на доменную модель.

🔹 Выбираем подходящие HTTP-методы
Определение нескольких базовых HTTP-методов может упростить разработку API. Например, использование PATCH может часто оказаться проблемой для команд (интересный момент кстати, мы обычно PATCH используем, но понимаю, что при реализации, например, могут возникнуть трудности с конфликтами и конечным использованием - нужно нормально его документировать. Да и остальные методы, не такие классические, тоже иногда могут понадобиться, так что тут не вполне соглашусь. В общем, можно похоливарить в комментариях).

🔹 Правильная реализация идемпотентности
Проработка идемпотентности при проектировании заранее может повысить надёжность API. Например, метод GET всегда идемпотентный, но POST часто нужно проектировать с учётом того, чтобы он стал идемпотентным.

🔹 Выбираем подходящие HTTP-коды
Лучше выделать ограниченный набор HTTP-кодов, чтобы упростить разработку приложения.

🔹 Версионирование
Использование версий API при проектировании может упростить процесс обновлений.

🔹 Семантика в URL
Использование семантических URL позволяет проще понимать API, чтобы пользователи могли найти нужный метод в API-документации. Например, используем имя ресурса вместо глагола и множественные числа существительных (где это возможно).

🔹 Пакетная обработка
Используем слова "batch" / "bulk" в конце строки URL для обозначения массовых действий.

🔹 Query-параметры
Использование набора устоявшихся параметров в URL делает API более гибким. Например, пагинация, сортировка, фильтрация и др.

📆 Так, что у нас по планам?

Уже записал аудио для выпуска про Web 3.0, но, как назло, не могу его пока смонтировать - программа для монтажа взбунтовалась и отказалась напрочь запускаться. Вот пытаюсь решать проблему, либо уже буду монтировать на другом компе.

Плюс, видел, что под последним видео про транзакции в БД вы оставили много комментариев с желанием послушать также про уровни изоляции транзакций и про блокировки в БД, поэтому и про одни, и про другие будут отдельные видео.
По уровням изоляции уже написал статью, выложу её скоро на Habr, и после Web 3.0 буду монтировать.

Ну а пока ловите мем про Редис. Может, про Редис тоже будет интересно выпуск послушать?

🚫 Итак, YouTube чувствует себя не очень хорошо.
Так что давайте не теряться:

👉 Телеграм - главный источник инфы и новостей по каналу. Плюс, здесь есть аудио-версии статей, которые ни от какого Ютуба не зависят;
👉 Я.Дзен - альтернативный канал, где есть все видео.

Никаких других альтернативных каналов с видео открывать не планирую - выпуски будут выкладываться на YouTube вне зависимости от блокировок до последнего. Так что вспоминаем про то, что на канале есть неплохая статья про VPN, и используем её так, как считаете нужным.

📣 Транзакции в SQL!

Обсудим самую базу: что это, зачем это нужно (с примером), как открыть/закрыть транзакцию, и парочку других моментов.

Аудио, как всегда, постом выше.

Есть желание послушать более углублённо про уровни изоляции, блокировки и прочее?

🗂 Новое видео про базовое понимание транзакций в SQL уже в работе! Ждём на следующей неделе.

А пока вот вам мем. А ты тот разработчик, который терпеть не может встречи, или тот зануда, который кидает звонки по любому поводу (лично я - второй😳)?

⚙️ А вот и новое видео - будем разбираться, как выбрать способ интеграции микросервисов.

Микросервисы мы с вами уже много где обсуждали, а ещё недавно у нас было видео про разные методы интеграции, так что самое время соединить эти вопросы, пока в голове ещё осталась информация про протоколы взаимодействия: как же лучше организовать общение микросервисов между собой?
Обсудим плюсы и минусы разных подходов и паттернов.

Аудио-версия, как всегда, постом выше.

https://youtu.be/5iou64wQfj4

Ещё не надоело слушать про эти микросервисы?

📚 А вот и первая лекция по AI!

Напомню, что мы начинаем цикл лекций от Никиты Кудряшова (Head of Data Science и специалист в области машинного обучения и нейронных сетей), где будем подробно разбирать тему искусственного интеллекта.

А в первой лекции мы начнём, конечно, с базы:

❓Что такое ИИ
❓Почему искусственный интеллект не совсем "интеллект"
❓История развития ИИ
❓Неужели ИИ придумали так давно, и тогда почему ChatGPT появился только сейчас

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

Очень хочется увидеть вашу реакцию и отзывы на лекцию.
Понравилось? Хотелось бы ещё таких лекций?

https://www.youtube.com/watch?v=5L7eLnAY7aA

🫙 Основные понятия баз данных. Главное

Понимание принципов работы и основ проектирования БД – это основа всех hard skills для системного аналитика, а также и для бизнес-аналитика: BABOK упоминает технику моделирования данных как одно из наиболее востребованных умений бизнес-аналитика.

Следует различать БД и СУБД:

➖ База данных (БД) – структурированный набор данных, который хранится на сервере.
➖ Система управления базами данных (СУБД) – это ПО, которая позволяет управлять данными в БД: читать и изменять.

БД могут быть реляционными и нереляционными (подробнее см. пост).

🔹 Реляционные БД хранят информацию в виде таблиц. Между таблицами определяются связи (relations) – создаётся схема данных. Для манипулирования данными применяется специальный язык запросов – SQL. Реляционные БД применяются повсеместно, лучше всего подходят для поддержки транзакций или когда нужно поддерживать строгую структуру данных и соблюдать требования ACID (о них ниже). Примеры реляционных СУБД: MySQL, PostgreSQL, Oracle.

🔸 Нереляционные БД (NoSQL) – это все остальные виды БД, например, ключ-значение, графовые, временных рядов и другие. Все виды нереляционных БД объединяет одно – данные хранятся любым другим способом, кроме таблиц. Из альтернативного названия (NoSQL) Часто применяется там, где нужна высокая скорость (например, для кэширования), требуется работать с большими объёмами данных и обеспечивать лёгкость масштабирования. Примеры нереляционных СУБД: MongoDB, Redis, Cassandra.

Основные понятия реляционных БД

📌 Сущность (entity) – это объект, который имеет смысл в предметной области и может быть представлен в БД. Например, студент, книга, заказ и т.д. Сущности обычно соответствуют таблицам в реляционных БД.

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

📌 Первичный ключ (primary key) – это атрибут или набор атрибутов, который однозначно идентифицирует каждую сущность в БД. Например, username в телеграме, id страницы ВК и т.д. Первичный ключ не может быть пустым или повторяться в рамках одной таблицы.

📌 Внешний ключ (foreign key) – это атрибут или набор атрибутов, который ссылается на первичный ключ другой сущности. Например, book_id в таблице Заказы ссылается на номер книги id в таблице Книги. Внешний ключ позволяет установить связь между сущностями и гарантировать соблюдение целостности данных. В данном примере с таблицей Заказы мы не можем поместить в столбец такой номер книги book_id, которого нет в таблице Книги – СУБД нам не позволит.

Транзакционность – важнейшее свойство реляционных БД

Транзакция — это комплекс последовательных операций с применением операторов SQL, имеющих определенную цель. Например, перевод денег между счетами. Ошибка в транзакции может привести к неконсистентности данных: деньги спишутся, но не поступят.

Все транзакции должны отвечать требованиям ACID:
1️⃣ Атомарность (atomicity) — транзакция является неделимым блоком и выполняется или полностью, или никак.
2️⃣ Согласованность (consistency) — завершенная транзакция сохраняет согласованность базы данных.
3️⃣ Изолированность (isolation) — параллельные транзакции не могут влиять друг на друга.
4️⃣ Устойчивость (durability) — никакой сбой в системе не может влиять на результат завершенной транзакции.

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

Про типы связей и нормализацию данных расскажем в следующих постах. Если вы хотите увидеть эти материалы поскорее, ставьте ⚡️

Ссылки на полезные материалы по основам БД в следующем посте👇

#бд

🎓 Так, давненько не было никаких новостей!
Всё нормально, я просто был в отпуске, поэтому активно возвращаюсь и сразу с анонсом:

Тема всяких AI, машинных обучений, нейронных сетей и дата-саенсов сейчас просто везде. Да даже если этим вообще не интересоваться, то всё равно тебя это заденет - все новые модели телефонов/ОС/приложений сейчас щеголяют какой-то новой AI-фичей. Но мы-то как раз обычно всем интересуемся и хотим во всём разобраться!

Поэтому возникло желание рассказать вам о том, что такое AI, историю его появления и развития, как это вообще работает, ну и дальше уже глубже в нюансы.
Но рассказать чуть с большим погружением, чем обычно, и в новом формате - в формате цикла лекций от реального специалиста в области ML и DS, который занимает должность Head of Data Science, преподавал машинное обучение и нейронные сети в Политехе и работает с этим на практике каждый день.

Пока планируем цикл из трёх лекций, первая из которых будет про самые основы: что такое AI, какие есть заблуждения, когда мы расшифровываем эту аббревиатуру, и как он развивался до современного состояния какого-нибудь ChatGPT. Эта лекция у меня уже в монтаже.

Интересно было бы послушать такое?