Базы Данных (Data Base) | SQL & NoSQL. PostgreSQL, MySQL и Big Data. Уроки для Backend и Data Engineer. Архитектура БД, Оптимизация и Design.

🦾 LLM умеют генерировать тексты, отвечать на вопросы и работать с документами. Но чтобы использовать их в реальных задачах, важно понимать, как модели принимают решения и почему иногда дают неожиданный результат. 🚀 На открытом уроке разберём, как устроены большие языковые модели и как применять эти знания на практике. Вы узнаете: — как модель выбирает слова и формирует ответ; — как развернуть LLM локально и проверить её работу через API; — как модели используют контекст из документов и почему это важно для RAG-систем. Урок подойдет начинающим разработчикам, аналитикам и менеджерам продукт…

Антипаттерн: Ненормализованная схема в SQL Когда нужно «быстро запилить фичу», руки тянутся сделать одну таблицу, где и заказ, и клиент, и товары — всё в куче. Пример: CREATE TABLE orders ( order_id SERIAL PRIMARY KEY, customer_name TEXT, customer_email TEXT, product_1_name TEXT, product_1_price NUMERIC, product_2_name TEXT, product_2_price NUMERIC ); 😰 Что пойдет не так: – Дублирование данных — имя клиента повторяется в каждом заказе. – Нет масштабируемости — максимум 2 продукта? А если будет 3? – Трудности с запросами — попробуй посчитать топ-5 товаров. Удачи. – Адские ап…

🎯 Мини-гайд: как НЕ спроектировать монстра вместо схемы БД Когда проект только начинается, есть соблазн «не заморачиваться» и сделать одну большую таблицу на всё. Спойлер: потом будет больно. Вот как этого избежать 👇 1. Начинай с нормализации – Смотри, какие поля повторяются. – Разделяй по сущностям: клиент ≠ заказ ≠ товар. – Нормальные формы — не академикам, а тебе на пользу. 2. Определи связи заранее – Один ко многим? Многие ко многим? – Используй FOREIGN KEY, чтобы база помогала тебе, а не мешала. 3. Не бойся JOIN-ов – Да, их становится больше. – Но это лучше, чем сотни NULL - ов и "…

🚀 Подборка полезных IT каналов в Max Системное администрирование, DevOps 📌 https://max.ru/i_odmin Все для системного администратора https://max.ru/bash_srv Bash Советы https://max.ru/sysadminof Книги для админов, полезные материалы https://max.ru/i_odmin_book Библиотека Системного Администратора https://max.ru/i_devops DevOps: Пишем о Docker, Kubernetes и др. https://max.ru/tipsysdmin Типичный Сисадмин https://max.ru/channel_win_sysadmin Системный Администратор Windows https://max.ru/channel_linux_admin Linux: Системный администратор https://max.ru/channel_linuxmod Linux https://max.ru/ch…

Антипаттерн: «Одна таблица на всё» Когда бизнес-логика усложняется, а структура БД остаётся в духе Excel — жди беды. 🔴 Что это такое? Проектировщик (часто на раннем этапе) создаёт одну большую таблицу, где: – сотни колонок на все случаи жизни, – куча NULL-ов, – смешаны данные разных сущностей (например, и клиенты, и заказы, и статусы). Так проще… пока не начнётся работа с реальными данными. 💥 Что пойдёт не так: – Производительность падает: индексы не работают эффективно. – Сложность валидации и бизнес-логики. – Трудно расширять: каждое изменение — как операция на открытом сердце. – Нельз…

❌ Антипаттерн: Хранить даты и время в VARCHAR Встречали такое? CREATE TABLE orders ( id SERIAL PRIMARY KEY, order_date VARCHAR(20) ); На первый взгляд — всё ок: дата есть, строка хранит. Но на практике — сплошные проблемы: 🔴 Нет гарантии формата '2024-12-01', '12/01/2024', '01.12.24', 'вчера' — всё ляжет, но работать с этим потом боль. 🔴 Сложность фильтрации и сортировки Сравнение строк ≠ сравнение дат. Запросы типа WHERE order_date > '2024-01-01' могут вести себя непредсказуемо. 🔴 Нельзя использовать функции времени Ни DATE_TRUNC, ни AGE(), ни агрегаты по времени не работают норм…

🔎 Мини-гайд: Индексы в PostgreSQL — быстро и по делу Индексы — главный инструмент для ускорения запросов. Но неправильное использование может только навредить. Основные типы индексов в PostgreSQL: - B-tree — по умолчанию. Идеален для поиска по равенству и диапазону (=, <, >, BETWEEN). - Hash — только для поиска по точному равенству (=). Становится актуальным реже. - GIN — для массивов, JSONB, полнотекстового поиска. - GiST — геоданные, поиск по диапазонам, сложные типы. - BRIN — для очень больших таблиц с упорядоченными данными (например, логи). Практические советы: - Не злоупотребляй инде…

SQL Important Queries Сохрани на потом, тебе пригодится👌 #db 👉 @database_info

Сегодня я хочу рассказать вам про одну часто недооцененную фишку в PostgreSQL - partial indexes (частичные индексы). Обычно мы создаём индексы на всю таблицу, но что если нам нужно ускорить только небольшую часть данных? Например, часто выбираются только активные пользователи (status = 'active'). Вместо полного индекса можно создать индекс только для нужного поднабора данных: CREATE INDEX idx_active_users ON users (last_login) WHERE status = 'active'; Что это даёт: - Индекс меньше по размеру → быстрее поиск и обновление. - Используется только тогда, когда запрос соответствует условию status…

🚀 Сегодня я покажу вам один из моих любимых хаков для PostgreSQL – генерация серий дат без циклов и хранимок. Это идеальный способ быстро собрать таймлайн для аналитики или отчётов. Сценарий: вам нужно построить список всех дат за последний месяц — например, чтобы потом сделать LEFT JOIN к таблице с событиями и увидеть, где были пропуски. Вот как это делается с помощью generate_series: SELECT generate_series( date_trunc('day', current_date) - interval '30 days', date_trunc('day', current_date), interval '1 day' ) AS day; 💡 Результат — 31 строка с датами от 30 дней назад до се…