Миграция баз данных с помощью библиотеки Liquibase

Миграция — это процесс преобразования базы данных путём изменения схемы: таблиц, индексов и других вспомогательных элементов. Однако при переходе на новую версию БД можно легко потерять уже сохранённые данные, особенно если во время миграции были внесены новые данные.

Для решения этой проблемы можно использовать Liquibase — это БД библиотека, с помощью которой можно отслеживать, управлять и применять изменения схем.

Подробное руководство о том, как настроить Liquibase и создать миграцию для новой базы данных — в статье:

https://tproger.ru/articles/migracii-baz-dannyh-s-pomoshhju-biblioteki-liquibase/

#бд #советы

Нормальные формы базы данных простыми словами

Плохая архитектура БД может привести к низкой производительности и ошибкам в запросах. Нормальная форма — это требования к структуре таблиц для устранения избыточных данных в БД. В этом видео рассматриваются три нормальных формы, а также, что такое денормализация БД и аномалии:

https://youtu.be/0kq99Y8m0gw

#бд

PostgreSQL под капотом

PostgreSQL — одна из наиболее популярных баз данных среди разработчиков. Интересно, из чего же она состоит? Данная серия статей разбирает PostgreSQL на уровне кода:

Часть 1: Введение
Часть 2: Цикл сервера
Часть 3: Подготовка бэкэнда
Часть 4: Инициализация бэкэнда
Часть 5: Цикл бэкэнда

#sql #c #бд

Хорошо ли вы знаете MongoDB? Проверяем в нашем новом квизе

MongoDB — одна из самых популярных NoSQL баз данных. Этот тест поможет вам проверить свои знания о её особенностях и основных принципах работы. Если чувствуете, что нужно освежить знания, рекомендуем ознакомиться с этой статьёй о MongoDB.

Пройти тест

#викторина #mongodb #бд

Как оптимизировать SQL-запросы для снижения нагрузки на БД

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

#sql #бд

Векторные базы данных: простым языком про устройство и принцип работы

Векторные базы данных — будущее работы с большими объёмами данных. Этот инструмент позволяет искать, анализировать и обрабатывать информацию гораздо быстрее благодаря работе с векторами.

В статье просто и понятно рассказано:

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

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

#бд

Упрощаем работу с БД

DrawDB — это редактор связей между объектами базы данных, который работает прямо в браузере. Он позволяет создавать диаграммы в несколько кликов, экспортировать сценарии SQL, настраивать редактор и многое другое.

Инструкция по установке и использованию тут: https://github.com/drawdb-io/drawdb

#инструменты #бд

Простыми словами: Как хранятся пароли в базах данных

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

Как это работает?

Когда вы придумываете пароль при регистрации, система его хеширует (превращает в код) и сохраняет этот код в базе данных.

Когда вы входите в систему и вводите пароль, система снова его хеширует и сравнивает с тем кодом, что уже есть в базе. Если они совпадают — вход разрешён.

Почему так делают?

— Безопасность. Если кто-то взломает базу данных, он увидит только хеши, а не настоящие пароли. Без исходного пароля хеши бесполезны для входа.
— Секретность. Даже люди, которые управляют системой, не могут узнать твой пароль.

По сути, пароли в базе — это не сами пароли, а их «закодированные отпечатки». Это как замок, который открывается только правильным ключом, но сам ключ нигде не записан. Даже если базу украдут, твои данные останутся защищёнными.

На картинке выше пример схемы хеширования паролей для хранения в БД.

#простымисловами #безопасность #бд

Чем отличаются реляционные БД от нереляционных

Реляционные и нереляционные базы данных — это два разных способа хранения и организации информации. Давайте разберём их отличия простыми словами.

Реляционные базы данных похожи на шкаф с ящиками, где всё упорядочено. Каждый ящик — это как таблица (представьте Excel), в которой:

— Есть чёткие столбцы, например, «Имя», «Фамилия», «Телефон».
— Каждая строка — это данные об одном объекте, например, о клиенте.
— Таблицы связаны между собой. Например, можно соединить таблицу «Клиенты» с таблицей «Заказы», чтобы узнать, кто что заказал.

В реляционных БД, например, MySQL или PostgreSQL, всё организовано и легко искать информацию даже с помощью сложных запросов вроде «покажи клиентов, купивших товар X». Но если данные часто меняются или их структура нечёткая, нужно «перестраивать шкаф», а при больших объёмах такие БД могут тормозить

Нереляционные базы, например, MongoDB или Redis — это как большая коробка, куда можно кидать вещи без строгого порядка. Здесь данные хранятся не в таблицах, а в разных форматах:

— Документы (как файлы с информацией).
— Ключ-значение (как словарь).
— Графы (для связей, например, в соцсетях).
— Колонки (для больших данных).

Такой подход даёт нам гибкость для хранения любых данных, даже если они часто меняются. А также позволяют быстро работать с большими объёмами и легко масштабируются. Взамен на эти преимущества они усложняют нам создание сложных запросов, а также поиск чего-то конкретного.

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

#простымисловами #бд

Партиционирование данных: что это такое и зачем нужно

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

У нас на сайте появилась статья, в которой вы сможете узнать больше подробностей о партиционировании, способах его реализации и отличиях от шардирования. Вы также увидите, как это работает в разных СУБД. Прочитайте, потому что это та база, которая пригодится каждому: https://tprg.ru/xHb6

#бд #datascience

DrawDB — бесплатный конструктор баз данных

Как и сказано в заголовке, DrawDB это бесплатный инструмент, который поможет вам в проектировании баз данных, а также в генерации необходимого SQL-кода.

Воспользоваться можно здесь: https://github.com/drawdb-io/drawdb

#инструменты #бд

Проектирование базы данных для самых маленьких — на примере кинотеатра

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

В статье разобрали, как шаг за шагом проектировать структуру базы данных: от выбора между ENUM и справочником до логики связи фильмов с жанрами через промежуточную таблицу. Плюс, классный момент — почему для билетов лучше использовать UUID, а не автоинкремент.

#статья #бд #начинающим #ru

💾 SQL vs NoSQL: основные отличия

База данных — сердце любого сервиса: именно она хранит заказы, профили, лайки, логи. Условно все СУБД делят на два лагеря. Реляционные (SQL) следуют строгой схеме и хранят данные в таблицах. Нереляционные (NoSQL) признают более свободный порядок: документами, ключ-значением, графами. Как понять, что подходит проекту?

Что такое SQL в реальности

SQL-база — словно бухгалтерская книга. Колонки описываются заранее, каждая запись проверяется по правилам, а изменения проходят через защищённые транзакции с гарантией «всё-или-ничего» (ACID). Поэтому:

— Целостность. Деньги списались — запись точно сохранилась.
— Связи. Можно за один запрос увидеть, какой товар купил пользователь, кто его доставит и где сейчас посылка.
— Строгость. Добавить новое поле нужно через миграцию схемы; зато хаоса не образуется.

Типичные представители: PostgreSQL, MySQL, Oracle.

Чем живёт NoSQL

NoSQL напоминает открытую мастерскую: форму деталей никто заранее не фиксирует, главное — быстро принимать и выдавать. Данные складываются целиком (JSON-документы), по ключу в памяти или узлами в графах. Отличительные черты:

— Гибкая схема. У разных пользователей могут быть разные поля — база не возражает.
— Горизонтальное масштабирование. Когда запросов становится в десять раз больше, добавляют ещё пару узлов, и поток рассасывается.
— Скорость записи. Миллионы событий (клики, телеметрия) летят почти без задержек.

Популярные решения: MongoDB (документы), Redis (ключ-значение), Cassandra (колонки), Neo4j (графы).

В зрелых проектах обе технологии живут бок о бок. SQL хранит финансы и критичные связи; NoSQL — всё, что растёт особенно быстро или не вписывается в жёсткую схему. Правило простое: если запись нельзя потерять или нужно соединить несколько таблиц одной командой — кладите её в SQL. Всё остальное, что требует гибкости и масштабируется пачками узлов, смело отдавайте NoSQL.

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

Какую базу данных вы используете чаще – реляционную или NoSQL? Делитесь опытом!

#бд #sql #nosql