Приклади складних запитів для вибірки даних в СУБД mysql, блог it-фахівця

Всього лише пару років тому, в проектах, які передбачали роботу з базами даних і побудовою статистики, основним достатком використовуваних SQL-запитів, переважало в основному безліч запитів, орієнтованих на стандартну вибірку даних і нечасто можна було побачити інші, які без жодних сумнівів можна було б віднести до "ексклюзиву". Хоча складність запиту і залежить від кількості використовуваних таблиць, але якщо ми всього лише візьмемо і виведемо дані полів трьох або більше таблиць мають стандартне об'єднання, то явна складність такого запиту не вийде за межі стандартної.

У даній статті в міру можливості будуть розглядатися ті запити, приклади яких мені знайти не вдалося і які, на мою думку, не належать до класу простих.

Порівняння даних за дві дати

Хоча дана статистика з роду завдань досить рідко зустрічаються, але все-таки необхідність в її отриманні іноді існує. І отримати таку статистику нітрохи не складніше інших.

Працювати ми будемо з двома таблицями, структура яких представлена ​​нижче:

Структура таблиці products

Структура таблиці statistics

Справа в тому, що стандарт мови SQL допускає використання вкладених запитів всюди, де дозволяється використання посилань на таблиці. Тут замість явно зазначених таблиць, завдяки використанню псевдонімів, будуть застосовуватися результуючі таблиці вкладених запитів з наявної зв'язком один - до - одному. Результатом кожної результуючої таблиці будуть дані про кількість вироблених замовлень якогось товару за певну дату, отримані шляхом виконання запиту на вибірку даних з таблиці statistics по необхідним критеріям. Іншими словами ми зв'яжемо таблицю statistics саму з собою. Приклад запиту:

У підсумку маємо такий результат:

Підстановка декількох значень з іншої таблиці

Необхідність в даному запиті не є повсякденною, але виникає не зовсім вже й рідко. Найпоширеніший приклад, це звичайна мережева гра. Де створюється сесія на два гравця. Відповідно в таблиці з даними про ігри є два поля з ідентифікаторами зареєстрованих гравців. Для того щоб вивести інформацію про наявні іграх, ми не можемо обійтися стандартним об'єднанням таблиці з даними про гравців і таблиці про наявні іграх. Так як ми маємо два поля з ідентифікаторами деяких гравців. Але ми можемо звернутися знову за допомогою до псевдонімів таблиць.

Демонстрація даного запиту буде відбуватися на іншому прикладі, а не на прикладі мережевої гри. Це щоб не створювати заново всі необхідні таблиці. Як дані візьмемо таблицю products з прикладу "порівняння даних за дві дати" і створимо ще одну відсутню таблицю replace_com. структура якої представлена ​​нижче:

Припустимо, що у нас є якийсь комп'ютерний салон і ми проводимо модифікації деяких комп'ютерних складових, а всі операції із заміни комплектуючих заносимо в базу даних. У таблиці replace_com цікавлять нас полями є: sProductID і rProductID. Де sProductID - ідентифікатор замінного модуля, а rProductID - ідентифікатор замінює модуля. Запит, який реалізує висновок даних про здійснені операції виглядає наступним чином:

Результуюча таблиця даних:

Висновок статистики з накопиченням за датою

Припустимо, що у нас є склад з якимись товарами. Товари періодично надходять, і нам би хотілося бачити в звіті залишки товарів по днях. Оскільки дані про наявність товарів необхідно накопичувати, то ми введемо призначену для користувача змінну. Але є одне невелике «але». Ми не можемо використовувати в запиті змінні користувача і угруповання даних одночасно (вірніше можемо, але в підсумку отримаємо, не те, що очікуємо), але ми можемо використовувати вкладений запит, замість Якщо не зазначено інакше таблиці. Дані в таблиці будуть попередньо згруповані за датою. І вже потім на основі цих даних ми зробимо розрахунок статистики з накопиченням.

На першому етапі потрібно встановити змінну і привласнити їй нульове значення:

У наступному запиті, ми створену раніше змінну і застосуємо:

Отримати використовувану в прикладах базу даних можна тут.

Схожі статті