Горячее
Лучшее
Свежее
Подписки
Сообщества
Блоги
Эксперты
#Круги добра
Войти
Забыли пароль?
или продолжите с
Создать аккаунт
Я хочу получать рассылки с лучшими постами за неделю
или
Восстановление пароля
Восстановление пароля
Получить код в Telegram
Войти с Яндекс ID Войти через VK ID
Создавая аккаунт, я соглашаюсь с правилами Пикабу и даю согласие на обработку персональных данных.
ПромокодыРаботаКурсыРекламаИгрыПополнение Steam
Пикабу Игры +1000 бесплатных онлайн игр Испытайте захватывающие сражения Второй мировой войны: быстрые бои, огромный арсенал, настройка, танки и стратегия на разнообразных картах!

Warfare 1942 - онлайн шутер

Мультиплеер, Шутер, Мидкорные

Играть

Топ прошлой недели

  • SpongeGod SpongeGod 1 пост
  • Uncleyogurt007 Uncleyogurt007 9 постов
  • ZaTaS ZaTaS 3 поста
Посмотреть весь топ

Лучшие посты недели

Рассылка Пикабу: отправляем самые рейтинговые материалы за 7 дней 🔥

Нажимая кнопку «Подписаться на рассылку», я соглашаюсь с Правилами Пикабу и даю согласие на обработку персональных данных.

Спасибо, что подписались!
Пожалуйста, проверьте почту 😊

Помощь Кодекс Пикабу Команда Пикабу Моб. приложение
Правила соцсети О рекомендациях О компании
Промокоды Биг Гик Промокоды Lamoda Промокоды МВидео Промокоды Яндекс Директ Промокоды Отелло Промокоды Aroma Butik Промокоды Яндекс Путешествия Постила Футбол сегодня
0 просмотренных постов скрыто
VelStyling
VelStyling
9 часов назад
Серия SQL: знакомство

LIMIT и интересные кейсы с ним. Или почему LIMIT - друг аналитика⁠⁠

Обычно все знают самое базовое применение LIMIT - ограничение строк выдачи в запросе.

LIMIT 10 -> показать 10 строк

Но применение LIMIT не ограничивается только ограничением :-).
Есть интересные кейсы по использованию LIMIT в своих запросах.
Об этом чуть ниже.

А пока подписывайся на мой канал На связи: SQL Там я публикую посты про особенности и нюансы SQL. Этот канал про то, как не бояться баз данных, понимать, что такое JOIN, GROUP BY и почему NULL ≠ 0. Его я веду с нуля подписчиков. Присоединяйся!

LIMIT и интересные кейсы с ним. Или почему LIMIT - друг аналитика Эмоциональное выгорание, Аналитика, Аналитик, Анализ данных, SQL, Ms SQL, База данных, Системный анализ, Системный аналитик, Длиннопост

И так, какие же кейсы есть с применением LIMIT

  1. LIMIT + OFFSET

    Многие помнят про LIMIT, но забывают про то, что можно еще применять сдвиг.

    SELECT *
    FROM users
    ORDER BY id
    LIMIT 10 OFFSET 20;

    Этот запрос вернёт 10 строк, начиная с 21-й.

    Такой прием применяется, например, в постраничной выдаче результатов запроса.

    Но этот кейс имеет и минусы: OFFSET все равно просматривает первые 20 строк, чтобы добраться до нужных. При больших объемах OFFSET работает медленно.

  2. LIMIT в UPDATE и DELETE

    Да, да - в этих операторах тоже можно использовать LIMIT, не только в SELECT

    DELETE FROM logs ORDER BY created_at ASC LIMIT 1000;

    Так чистят таблицу порциями, чтобы не завалить базу огромным удалением.

  3. LIMIT в подзапросах

    Об этом часто помнят, т.к. подзапрос является запросом, а в запросах использование LIMIT - вполне привычное дело.


    Найдем самый дорогой заказ:

    SELECT *

    FROM orders

    WHERE id = (SELECT id FROM orders ORDER BY price DESC LIMIT 1);

    Это иногда проще, чем возиться с MAX() и джойнами.

  4. LIMIT vs FETCH … WITH TIES

    В некоторых СУБД (например, SQL Server, Oracle) есть фича:

    SELECT *

    FROM products

    ORDER BY price DESC

    FETCH FIRST 3 ROWS WITH TIES;

    Такой запрос вернёт не просто 3 строки, а все строки, у которых цена такая же, как у третьей записи.
    (например, если на третьем месте несколько товаров с одинаковой ценой).


    LIMIT показывает первые N строк после сортировки
    А вот WITH TIES говорит: «Выдай все строки, которые наравне с последней по значению сортировки».


    В других СУБД такой синтаксис можно реализовать через LIMIT + подзапрос с оконной функцией RANK()

  5. LIMIT 0

    Очень полезный трюк.

    SELECT * FROM users LIMIT 0;

    Вернёт пустую таблицу, но со всеми названиями и типами столбцов.
    Это часто используют для генерации схемы в BI-инструментах или в тестах

  6. LIMIT в CTE (PostgreSQL)

    Можно ограничивать данные прямо на уровне общего табличного выражения (CTE), чтобы уменьшить нагрузку:

    WITH top_orders AS (

    SELECT * FROM orders ORDER BY price DESC LIMIT 100

    )

    SELECT * FROM top_orders WHERE customer_id = 42;

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

В итоге LIMIT — это не просто «дай 10 строк», а инструмент для оптимизации, постраничной навигации, аккуратных обновлений и даже для защиты от перегруза.

Подписывайся на мой ТГ канал На связи: SQL, чтобы узнавать/вспоминать еще больше нюансов SQL запросов.

Показать полностью 1
[моё] Эмоциональное выгорание Аналитика Аналитик Анализ данных SQL Ms SQL База данных Системный анализ Системный аналитик Длиннопост
0
1
VelStyling
VelStyling
1 день назад
Серия SQL: знакомство

ORDER BY - это как уборка в шкафу. Вещи можно разложить по цвету, по размеру или просто свалить все в кучу⁠⁠

ORDER BY — штука вроде бы простая («отсортируй строки»), но там есть много нюансов, про которые мы просто не помним или не пользуемся.

Вообще мы даже своими смартфонами не всегда (да, что уж - никогда) не пользуемся на полную мощность.

В своем канале На связи: SQL рассказываю про некоторые забытые нюансы языка SQL, особенности и необходимую теорию, чтобы любой начинающий мог свободно познакомиться с этим языком и применить его в дальнейшем для своих задач. Канал создан недавно, с 0 подписчиков, но уже активно наполняется контентом. Подписывайся!

ORDER BY - это как уборка в шкафу. Вещи можно разложить по цвету, по размеру или просто свалить все в кучу Аналитика, Математика, Урок, Эмоциональное выгорание, SQL, Ms SQL, Аналитик, Анализ данных, База данных, Программирование, Длиннопост
  1. Блок с ORDER BY предназначен для сортировки результата выборки.
    По умолчанию сортировка ASC (по возрастанию). Можно явно писать:

ORDER BY age ASC -- от младших к старшим
ORDER BY age DESC -- от старших к младшим

2. Можно сортировать сразу по нескольким столбцам:

ORDER BY country, city

Сначала сортируются страны, внутри них — города.

3. Можно писать не имя, а номер колонки в SELECT:

SELECT name, age
FROM users
ORDER BY 2 DESC; -- сортируем по age

Но это считается «плохим тоном» — лучше явно указывать названия. Хотя мне очень нравится это использовать, особенно, когда в селекте не просто имя столбца, а вычисление.

4. NULL в ORDER BY требует особого внимание.
NULL в разных БД обрабатывается по-разному.

В PostgreSQL:

  • ASC → NULL идут в конце

  • DESC → NULL идут в начале

можно явно писать:

ORDER BY age ASC NULLS FIRST;
ORDER BY age DESC NULLS LAST;

В MySQL и SQL Server правила отличаются:

  • в MySQL NULL всегда считаются «меньше всего» (т.е. идут первыми в ASC).

  • в SQL Server можно управлять через ISNULL()/COALESCE().

В MySQL и SQL Server нельзя использовать NULLS FIRST или NULLS LAST при сортировке,

Для SQL Server используем:

ORDER BY ISNULL(age, 9999) ASC;
ORDER BY COALESCE(age, 9999) ASC;

Здесь NULL мы заменяем на большое число (9999), и оно уходит в конец сортировки по возрастанию.
А если хотим NULL в начало — ставим что-то маленькое, например -1.

Для MySQL есть поведение по умолчанию:

  • При ASC → NULL идут первые

  • При DESC → NULL идут последние

А если нужно наоборот, то делаем хитрость с IS NULL:

ORDER BY age IS NULL, age ASC;

Здесь age IS NULL вернёт 1 для NULL и 0 для обычных значений.
SQL сначала отсортирует по этому условию (0 → 1), а потом уже по age.

5. Можно сортировать не только по полям, но и по функциям.

ORDER BY LENGTH(name) DESC;
ORDER BY purchase_amount * discount;

6. Случайная сортировка - имеет место быть. Но очень "дорога" в использовании на больших объемах.

-- PostgreSQL / SQLite
ORDER BY RANDOM()

-- MySQL
ORDER BY RAND()

Часто случайная сортировка используется при тестировании на небольших объемах.
- хотим показать пользователю случайный товар в магазине
- хотим проверить, как работает приложение, не завися от конкретного порядка записей
- рекомендательные системы: в выдачу добавляем случайный товар, чтобы не зацикливать пользователя только на "популярных" товарах.
- игры или викторины: рандомная выдача вопросов.

7. Есть еще такое понятие как COLLATION (сравнение строк).

ORDER BY учитывает локаль (collation). Поэтому, например, русские буквы могут сортироваться по-разному в разных СУБД:

  • А может идти перед а, или наоборот.

  • Можно явно указать сортировку:

ORDER BY name COLLATE "C" -- по байтовому значению
ORDER BY name COLLATE "ru_RU" -- по русскому алфавиту

Представь, что у тебя есть список имён:
['Елена', 'елена', 'Жанна', 'Анна']

Когда ты пишешь в SQL:

SELECT * FROM users ORDER BY name;

база должна решить:

  • считать ли «Елена» и «елена» одинаковыми?

  • что идёт раньше: «Ж» или «А»?

  • как сравнивать буквы с диакритикой: «é» vs «e»?

Вот именно на эти вопросы отвечает collation.

То есть COLLATION — это как правило сортировки в библиотеке: от него зависит, где именно окажется твоя книга.

То есть, ORDER BY — это не просто «отсортировать», а ещё и про то:

  • куда денутся NULL

  • как сортируются строки (с учётом локали)

  • можно ли сортировать по выражениям или случайно

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

Показать полностью
[моё] Аналитика Математика Урок Эмоциональное выгорание SQL Ms SQL Аналитик Анализ данных База данных Программирование Длиннопост
0
0
VelStyling
VelStyling
14 дней назад
Серия SQL: знакомство

AND и OR в SQL: как правильно соединять условия⁠⁠

Когда мы работаем с базой данных, почти всегда хотим не просто что-то выбрать, а применить несколько условий сразу. Например: выбрать всех клиентов старше 18 лет и с активной подпиской.

И здесь на помощь приходят два основных логических оператора: AND и OR.

AND и OR в SQL: как правильно соединять условия Аналитика, Эмоциональное выгорание, Аналитик, Системный аналитик, SQL, Microsoft Excel, Таблица, Данные, База данных, IT

Что делают AND и OR

  • AND — «и». Все условия должны быть выполнены одновременно.
    Пример: выбрать из холодильника молоко и яйца, чтобы приготовить омлет:

SELECT *

FROM fridge

WHERE product = 'milk' AND product = 'eggs';

(Да, в реальности одной строки с молоком и яйцом не будет, но идея ясна: оба условия должны выполняться вместе.)

OR — «или». Достаточно, чтобы выполнено было хотя бы одно условие.
Пример: выбрать продукты, которые нужно купить или молоко, или яйца:

SELECT *

FROM shopping_list

WHERE product = 'milk' OR product = 'eggs';

Где могут использоваться

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

  • HAVING — фильтрация агрегатов после GROUP BY

  • JOIN ON — комбинирование условий соединения таблиц

Пример с HAVING:

SELECT category, COUNT(*)

FROM fridge

GROUP BY category

HAVING COUNT(*) > 5 AND AVG(expiry_date) < '2025-08-01';

Особенности и нюансы:

  • Порядок выполнения важен

    AND имеет более высокий приоритет, чем OR.

    Если смешиваете их, всегда используйте скобки для точного порядка:

    SELECT *

    FROM fridge

    WHERE (product = 'milk' OR product = 'eggs') AND expiry_date < '2025-08-01';

  • AND «сжимает» результат, OR «расширяет» результат

    AND оставляет меньше строк, OR — больше

Частые ошибки

  • Забыли скобки и получили слишком большой или слишком маленький результат

  • Использовали AND там, где нужен OR (или наоборот)

  • Смешали NULL значения: NULL AND TRUE и NULL OR TRUE могут вести себя неожиданно

Представим, что мама проверяет холодильник:

  • У неё есть список продуктов, которые могут испортиться: молоко, яйца, йогурт

  • Она хочет приготовить что-то, если и молоко, и яйца в наличии → AND

  • Она хочет перекусить, если есть молоко или йогурт → OR

В SQL это выглядит так:

-- Для приготовления омлета

SELECT *

FROM fridge

WHERE product = 'milk' AND product = 'eggs';

-- Для перекуса

SELECT *

FROM fridge

WHERE product = 'milk' OR product = 'yogurt';

AND и OR — это простые, но мощные инструменты фильтрации. Правильное использование скобок и понимание приоритета операторов помогает избежать ошибок и выбирать точно те данные, которые нужны.

А в своем канале На связи: SQL я публикую информацию с особенностями и нюансами в языке SQL, разбираю аналитические запросы и подходы работы с данными. Канал создала недавно с нулем подписчиков, но там уже есть интересная информация для работы аналитиков. Подписывайся!

Показать полностью
[моё] Аналитика Эмоциональное выгорание Аналитик Системный аналитик SQL Microsoft Excel Таблица Данные База данных IT
1
6
VelStyling
VelStyling
15 дней назад
Серия SQL: знакомство

WHERE в SQL: как домохозяйка наводит порядок в холодильнике⁠⁠

Каждый из нас ежедневно сталкивается с бытовыми вопросами. У вас огромный холодильник: продукты, напитки, соусы, остатки вчерашнего ужина. Каждый день нужно понять: что из этого пригодно к употреблению сегодня, что нужно использовать для обеда, а что отправить в мусор.

WHERE в SQL: как домохозяйка наводит порядок в холодильнике Аналитика, Эмоциональное выгорание, Услуги, SQL, Microsoft Excel, Аналитик, Данные, База данных, Запросы, IT, Смена профессии, Длиннопост

Вот тут и появляется WHERE. Это фильтр, который помогает выбрать именно нужные строки из таблицы — или продукты из холодильника.

А в своем канале На связи: SQL я публикую информацию с особенностями и нюансами в языке SQL, разбираю аналитические запросы и подходы работы с данными. Канал создала недавно с нулем подписчиков, но там уже есть интересная информация для работы аналитиков. Подписывайся!

Нам нужно выкинуть все продукты, у которых истек срок годности:

SELECT *
FROM fridge
WHERE expiry_date < CURRENT_DATE;

fridge — наша таблица с продуктами
expiry_date < CURRENT_DATE — условие: выбираем просроченные продукты
CURRENT_DATE - текущая дата

Что можно писать в WHERE

  • Сравнения: =, >, <, >=, <=

  • Логические связки: AND, OR, NOT

  • Проверки на вхождение: IN, BETWEEN, LIKE

  • Подзапросы: «проверить список покупок перед выбором»

Или, мы хотим приготовить что-то на десерт:

SELECT *
FROM fridge
WHERE category = 'dessert' AND expiry_date > CURRENT_DATE;

Условие AND expiry_date > CURRENT_DATE добавляем на случай, если мы не выкинули всю просрочку до этого.

Подзапросы

В WHERE можно использовать подзапросы. Это когда нам нужна информация из другого источника, чтобы использовать ее в своем запросе. Например, нам надо понять что из рецепта отсутствует у нас в холодильнике.

SELECT *
FROM cooking_recipe
WHERE product NOT IN (SELECT product FROM fridge);

WHERE проверяет какие продукты отсутствуют в холодильнике.

Аналогично можно использовать EXISTS или NOT EXISTS
SELECT *
FROM fridge f
WHERE EXISTS (SELECT 1 FROM cooking_recipe s WHERE s.product = f.product);

EXISTS = есть продукт в списке
NOT EXISTS = нет продукта в списке

ANY \ ALL

Эти конструкции позволяют сравнивать с набором значений.

SELECT *
FROM fridge
WHERE expiry_date <= ALL (SELECT expiry_date FROM fridge WHERE category = 'milk');

Все хорошие домохозяйки используют принцип ротации. Выбирают продукты, срок годности которых меньше всех в категории “молоко”.

  • Подзапрос (SELECT expiry_date FROM fridge WHERE category = 'milk') возвращает даты всех банок молока.

  • Условие expiry_date <= ALL (...) означает: выбрать только те банки, у которых дата годности меньше или равна каждой другой банке молока.

  • Практически это банка (или несколько, если даты совпадают), которая старше всех остальных.

То есть, результат будет одна или несколько банок с самой ранней датой годности.

SELECT *
FROM fridge
WHERE expiry_date <= ANY (SELECT expiry_date FROM fridge WHERE category = 'milk');

  • Условие expiry_date <= ANY (...) означает: выбрать все банки молока, у которых дата годности меньше или равна хотя бы одной другой банке молока.

  • Тут почти все банки проходят условие, кроме самой свежей (если она самая большая по сроку).

  • Результат может быть несколько банок, не обязательно только одна. Все, кто «моложе или равны хотя бы одной другой», будут выбраны.

CASE в WHERE

Можно использовать CASE для сложной логики

SELECT *
FROM fridge
WHERE
CASE
WHEN product = 'milk' THEN shelf = 'top'
ELSE shelf = 'middle'
END;

Если я ищу молочные продукты в холодильнике, то должна их искать на самой верхней полке, иначе - на средней.


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

Показать полностью
[моё] Аналитика Эмоциональное выгорание Услуги SQL Microsoft Excel Аналитик Данные База данных Запросы IT Смена профессии Длиннопост
5
VelStyling
VelStyling
21 день назад
Серия SQL: знакомство

Структура запроса SQL и порядок выполнения блоков⁠⁠

Многие думают, что SQL читается сверху вниз — как написано, так и выполняется. Но это не так.
SQL-запрос устроен хитро: порядок написания ≠ порядок выполнения.

Структура запроса SQL и порядок выполнения блоков Microsoft Excel, Аналитика, Эмоциональное выгорание, SQL, Аналитик, База данных, Самообразование, Профессия, Онлайн-курсы, Бесплатное обучение, Поиск работы, Курсы

Классический скелет запроса выглядит так:

SELECT — какие поля выбрать

FROM — из какой таблицы

JOIN — если нужно соединение

WHERE — фильтрация строк до агрегации

GROUP BY — группировка

HAVING — фильтрация групп (после агрегации)

ORDER BY — сортировка

LIMIT — ограничение количества строк

SELECT — это конструктор. Ты как будто сначала берёшь детали, потом отбираешь нужные, потом собираешь по группам, и только потом смотришь итог.

Мы привыкли, что текст читается слева направо, сверху вниз. Но не везде так:

  • в арабском и иврите — читают справа налево,

  • в китайском — традиционно писали сверху вниз.

Это не ошибка, не странность, а особенность языка, которая исторически так сложилась.

SQL — тоже «язык», и у него есть свои правила: мы пишем запрос сверху вниз, начиная с SELECT
А выполняется сам запрос совсем в другом порядке.

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

Где ещё встречается разница между тем, как пишут и как «читают»:

  • Музыка 🎼
    В нотах всё аккуратно записано: сверху вниз, слева направо. Но музыкант, читая ноты, должен сначала понять тональность, размер, темп, и только потом играть каждую ноту по порядку. То есть фактически исполняется не в том же порядке, как просто «прочитал глазами».

  • Рецепты в кулинарии 👩‍🍳
    В рецепте шаги написаны линейно: 1, 2, 3. Но когда готовишь, иногда сначала ставишь воду кипятиться, пока режешь овощи. Т.е. порядок написанного ≠ фактический порядок действий.

  • Юридические документы 📑
    Контракт читается сверху вниз, но при толковании юристы сначала смотрят на определения терминов, потом на условия, потом на исключения.

  • Программирование в целом 💻
    В коде написано: «вызови функцию А, потом Б». Но компилятор или интерпретатор сначала обрабатывает импорт библиотек, парсит синтаксис, оптимизирует, и только потом «доходит» до исполнения.

В SQL — такая же история: пишем запрос сверху вниз, но база данных «читает» его по-своему. Про фактический порядок выполнения я написал подробно в своём канале На связи: SQL, так что если интересно — загляните 😉

Показать полностью
[моё] Microsoft Excel Аналитика Эмоциональное выгорание SQL Аналитик База данных Самообразование Профессия Онлайн-курсы Бесплатное обучение Поиск работы Курсы
3
0
VelStyling
VelStyling
22 дня назад
Серия SQL: знакомство

Таблицы в базах данных: где чаще всего "горит"⁠⁠

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

В своем канале На связи: SQL я рассказываю об особенностях языка SQL. Разбираю аналитические запросы и подходы работы с данными. Канал создала недавно с нулем подписчиков, но там уже есть интересная информация для работы аналитиков. Подписывайся!

Таблицы в базах данных: где чаще всего "горит" Моральная поддержка, Мотивация, SQL, Аналитик, Аналитика, Анализ данных, База данных, Самообразование, Смена профессии, Смена работы, Данные, Microsoft Excel, Длиннопост

И для формирования таблиц в БД есть свои требования, нюансы и особенности.

Очень часто аналитики сталкиваются со следующими проблемами при работе с данными:

Слишком много столбцов

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

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

Грубо говоря, нормализация - это способ организации данных. Что именно хранится, где именно хранится и как все, что хранится, связано между собой.

Дублирование данных

В таблице могут храниться одни и те же данные по 100 раз (например, имя клиента в каждом заказе).

Это приводит к сложности обновления — изменил телефон в одном месте, а в другом он остался старым; объем БД растет, что требует увеличения ресурсов для работы с данными.

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

И это тоже про нормализацию данных.

Пустые ячейки (NULL)

Есть поле, но оно ничем не заполнено. И тогда аналитик задается вопросом: что это значит? Что данных просто нет (их никто не вносит), данные вносят, но они потерялись при загрузке в таблицу, либо эти данные необходимо воспринимать как равные нулю...

В этом случае необходимо сначала посмотреть требования к источнику данных, есть ли там обязательность их заполнения. Если данные обязательны к заполнению, то стоит рассмотреть ETL (Extract Transform Load - извлечение, преобразование и загрузка) процесс данных.

И от полученных результатов принимать решение как расценивать NULL данные.

Неправильный тип данных

Телефон хранят как INT, даты — как текст, деньги — как FLOAT.
Такой подход приводит к тому, что в телефоне «съедается» +7, даты не сортируются, а деньги теряют копейки.

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

В этом случае: только правильное использование типов данных.

Нет ключей и индексов

Ключи нам нужны, чтобы однозначно идентифицировать данные и связывать таблицы между собой.

Есть первичный ключ (Primary Key) и внешний ключ (Foreign Key)
Первичный ключ - это уникальный идентификатор. Например есть два Ивановых Ивана Ивановича, но у них будут разные ID. Этот ID будет однозначно идентифицировать каждого из них.
Внешний ключ - это ссылка на другую таблицу. Например есть таблица заказов и в ней есть поле client_id. Это поле будет ссылаться на ID нашего Иванова Ивана Ивановича в таблице с персональными данными.

Индексы нам нужны для ускорения поиска.

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

Но если есть алфавитный указатель (индекс) — ты сразу находишь нужное слово.

Примеры:

  • Поиск клиента по номеру телефона

  • Поиск заказов по дате

  • Поиск товаров по категории

Индексы ускоряют запросы в разы, но требуют памяти и времени на обновление (поэтому ими злоупотреблять тоже не стоит).

Слияние «всего подряд»

Если таблицу использовать как свалку — складывать туда и клиентов, и товары, и заказы — это как в одной кастрюле сварить борщ, компот и макароны.
Итог: никто не понимает, что с этим есть.

А в канале На связи: SQL уже первые посты про структуры запросов и JOIN ждут тебя.

Если тебе нужна поддержка и мотивация или просто сопутствующие слова для твоего развития, то приходи в канала Сила слов. Там каждое утро тебя ждет мотивационное и поддерживающее послание.

Показать полностью
[моё] Моральная поддержка Мотивация SQL Аналитик Аналитика Анализ данных База данных Самообразование Смена профессии Смена работы Данные Microsoft Excel Длиннопост
2
VelStyling
VelStyling
28 дней назад
Серия SQL: знакомство

Из чего состоит база данных? Простыми словами и с примерами из жизни⁠⁠

База данных — это не какой-то страшный монстр из IT-страшилок. Это, скорее, твой самый организованный шкаф, в котором всё лежит по полочкам и ты всегда знаешь, где что искать.

Вот разберёмся, из чего она состоит и почему это важно.

Особенности и нюансы, а также интересные факты, задачи и многое другое можно прочитать в моем канале На связи: SQL Я его веду с нуля, и рассказываю в публикациях информацию с самых основ. Подписывайся! Планирую разбирать там интересные аналитические задачи.

Из чего состоит база данных? Простыми словами и с примерами из жизни База данных, Microsoft Excel, Таблица, SQL, Аналитик, Аналитика, Самообразование

1. Таблицы — это как списки гостей на твоей вадьбе

Ты ведь когда-нибудь составлял(а) список гостей? Кто приглашён, как будет добираться, где остановится, откуда забрать? Вот это и есть таблица — аккуратный список, где каждая строка — отдельный гость, а каждый столбец — важная инфа про него.

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

2. Поля (столбцы) — это категории, которые помогают разложить данные по полочкам

Поле — это как коробка с надписью «Имя», «Телефон», «Принёс подарок». Без таких коробок у тебя бы всё смешалось в одну кучу — как если бы носки и трусы лежали в одной коробке и искать их было бы сплошным кошмаром.

Жизненный пример: когда мама говорит: «Твои учебники на полке, а игрушки — в коробке», она на самом деле говорит о полях — разделении информации.

3. Записи (строки) — это конкретные данные, про каждого гостя или объект

Строка — это, грубо говоря, одна полная карточка гостя: «Оля, +7 900..., принесла торт». Не нужно ничего додумывать — всё записано и понятно.

Представь: хочешь позвонить Оле? Заглядываешь в её строку — и все контакты под рукой.

А теперь маленький секрет базы данных:

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

Здесь на помощь приходят…

  • Индексы — как яркие закладки в книгах. Без них поиск был бы как искать иголку в стоге сена.

  • Связи (отношения) — это как ниточки между гостями и подарками. Они показывают, кто что принёс, кто с кем пришёл и кто кому друг.

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

  • Процедуры и триггеры — это автоматические помощники, которые, например, сразу отправят напоминание гостю, если он не подтвердил участие.


Почему это важно?

Потому что без базы данных твой «шкаф» превратится в хаос: всё смешается, запутается, и ты будешь тратить часы, чтобы найти нужную информацию.

База данных — это как суперорганайзер твоей жизни, только для данных.

Ну а в своем канале На связи: SQL я пишу об особенностях языка SQL, интересных ситуациях и все это пытаюсь объяснить простым доступных языком.

Показать полностью 1
[моё] База данных Microsoft Excel Таблица SQL Аналитик Аналитика Самообразование
7
VelStyling
VelStyling
29 дней назад
Серия SQL: знакомство

База данных: гардероб, кухня и мастерская в одном месте⁠⁠

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

База данных (БД) — это тот же шкаф, только для информации. Она хранит данные так, чтобы их можно было легко положить, достать и разложить по порядку.

Если тебе интересно узнать больше про базы данных и SQL — заглядывай в мой телеграм-канал sql_in_touch. Там я просто и понятно рассказываю, как работать с SQL, разбираю практические примеры и делюсь лайфхаками для начинающих. Буду рада видеть тебя в числе подписчиков и вместе разбираться в мире данных!

База данных: гардероб, кухня и мастерская в одном месте Аналитика, Аналитик, Microsoft Excel, База данных, Данные, Анализ данных, SQL, Отчет, Визуализация, Визуализация данных, Postgresql, Oracle, Образование, Длиннопост

В нашей жизни есть разные шкафы. Платяной шкаф, кухонный шкаф, шкаф с инструментами и т.д. Так и в мире данных есть разные БД.

Виды баз данных и зачем они нужны

1. Реляционные БД (табличные)

  • Данные хранятся в таблицах (как в Excel, только гораздо умнее).

  • Таблицы связаны между собой: в одной лежат заказы, в другой — клиенты, и они связаны по уникальному номеру клиента.

  • Примеры: MySQL, PostgreSQL, Oracle.

  • 📌 Где хороши: когда данные структурированы и связи между ними важны (интернет-магазин, банковские операции).

💡 Пример:
У меня в одном ящике лежит нижнее белье, в другом — футболки, а на плечиках висят брюки и пиджаки. Мне нужно быстро собрать наряд для собеседования. Я открываю нужные ящики и беру нужные вещи — так я собираю образ. Да, бывает, что я надену на себя вещи, которые не сочетаются между собой. Но в данном контексте это будет означать, что я не ограничила выборку условиями. А все необходимые составляющие: футболка, брюки, пиджак и т.д. будут выбраны из нужного ящика или вешалки.

Так и база данных — она состоит из разных «ящиков» (таблиц), в которых хранится разная информация. Но чтобы получить полный «наряд» (то есть ответ на запрос), система быстро соединяет данные из этих ящиков и выдает нужный результат. Это и есть работа с базой данных — быстро и удобно находить нужные сведения, даже если они лежат в разных местах.

2. Документоориентированные БД

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

  • Данные хранятся в виде документов (JSON, XML) — как целые досье.

  • Каждый документ может содержать разную структуру, без строгих таблиц.

Примеры: MongoDB, CouchDB.

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

📌 Где такие базы удобны? Когда данные часто меняются и не всегда бывают одинаковыми — например, каталоги товаров с разными характеристиками или профили пользователей с разным набором информации.

3. Ключ-значение

Представь повара на кухне, у которого на полках стоят контейнеры с приправами. На каждом контейнере — ярлычок: «Соль», «Перец», «Базилик». Повар сразу видит, где что лежит, и может быстро взять нужную специю, не тратя время на поиски.

В базах данных типа ключ-значение, например Redis или Memcached, всё устроено похожим образом: есть «ключ» — это как ярлычок на контейнере, и «значение» — содержимое внутри. Когда нужна информация, система быстро находит значение по ключу — без лишних сложностей и долгих поисков.

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

4. Графовые базы данных

Соцсети — отличный пример того, как работают графовые базы данных.

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

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

📌 Где полезны графовые БД? В соцсетях для построения друзей и рекомендаций, в картах для прокладывания маршрутов, в системах рекомендаций товаров.

💡 Пример:
Представь, что у тебя есть большая компания, и тебе нужно понять, кто с кем работает вместе, кто кому помогает и кто отвечает за какие задачи.

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

Графовая база поможет быстро найти нужных людей и понять, как информация и задачи «текут» внутри компании

Итог

База данных — это способ хранить и упорядочивать данные, как мы упорядочиваем вещи дома или в рабочем шкафу.

  • Хотите чёткий порядок и строгие связи? → Реляционные БД.

  • Нужна гибкость и разная структура? → Документоориентированные.

  • Важна молниеносная скорость для простых данных? → Ключ-значение.

  • Важны сложные связи? → Графовые.

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

Показать полностью 1
[моё] Аналитика Аналитик Microsoft Excel База данных Данные Анализ данных SQL Отчет Визуализация Визуализация данных Postgresql Oracle Образование Длиннопост
0
Посты не найдены
О нас
О Пикабу Контакты Реклама Сообщить об ошибке Сообщить о нарушении законодательства Отзывы и предложения Новости Пикабу Мобильное приложение RSS
Информация
Помощь Кодекс Пикабу Команда Пикабу Конфиденциальность Правила соцсети О рекомендациях О компании
Наши проекты
Блоги Работа Промокоды Игры Курсы
Партнёры
Промокоды Биг Гик Промокоды Lamoda Промокоды Мвидео Промокоды Яндекс Директ Промокоды Отелло Промокоды Aroma Butik Промокоды Яндекс Путешествия Постила Футбол сегодня
На информационном ресурсе Pikabu.ru применяются рекомендательные технологии