Действительно есть о чем задуматься в примере с предикатом "ANY". Select name, population from city where population > any( Select population from city where countrycode ='BRA' ) and countrycode = 'JPN'; Не сразу понял, почему условие читается как "Города JPN с населением больше чем минимальное население города в BRA». Поразмыслив, понял что интерпретатор, при обработке данного запроса работает по следующей логике: 1. Взять население из 1-го города JPN 2. Взять население из 1-го города BRA 3. Сравнить население 1-го города JPN с население 1-го города BRA 4. Если Истина: население 1-го города JPN > чем население 1-го города BRA то город JPN попадает в выборку 5. Если Ложь то: 6. Взять население из 2-го города BRA 7. Сравнить население 1-го города JPN с население 2-го городом BRA 8. Ели везде будет ложь так далее до города BRA с минимальным населением и потом уже «общая ложь» и город не попадает в выборку Потом Новый цикл со вторым городом JPN Нечего не перепутал в логике?
Вы отлично вникли в суть работы этого запроса! (Если кратко, то найдутся все города JPN, население которых больше города с минимальным населением из BRA)
Я вместо использование лимита в подзапросе сделал интересную вещь: использовал MAX(), MIN(), AVG() - так как он везде проставляет значения у всех пунктов (городов, например). Можно сказать, это обход ORDER BY и LIMIT.
@@HtmllabRu я не совсем точно выразился. Они могут заменить его, когда интересен случай поиска того же максимума или минимума. По сути в видео было сравнение городов, население которых было больше чем население самого малонаселённого города. И вместо того, чтобы сравнивать всё со всем - можно взять город с минимальным населением одной страны (это будет в Any с помощью MIN()) и сравнивать это с другими городами. Мне кажется, так легче уяснить суть этих конкретно сравнений. Я понимаю, что это в видео были просто примеры работы, но я вот попробовал сделать это по-своему. Всё, что я имел ввиду - это, что эти функции могут заменить ORDER BY `some_field` LIMIT 1.
Здравствуйте! Предупреждаю, что крайне слабо разбираюсь в sql. Делаю модуль с таблицами (в основном прайс-листы) на PHP, mySQL и JS. Есть TABLES, которая хранит номера строк через запятую. Есть таблица со строками TABLES_STRINGS, которая хранит ID строк и номера блоков, из которых она состоит. Одна строка может быть в разных таблицах. В таблице TABLES_BLOCKS блоки хранят свои ID, NAME и какие-то свойства, но без содержимого. У каждого блока может быть неограниченное количество вариаций содержимого - они хранятся в таблице TABLES_BLOCKS_VAR со своими ID и т.п. Есть таблица TABLES_STRINGS_BLOCKS_VAR, которая хранит информацию о том, в какой таблице какая вариация блока в строке (TABLE_ID, STRING_ID, BLOCK_ID, VAR_ID). Всё это сделано для: сколь угодно таблиц(прайсов) с разным составом строк, но где-то может отличаться тайтл или цена или другой блок. Зато, если поменять цену в одном блоке, то цена поменяется во всех таблицах, где она есть. Какая-то синхронизация. Для sql я пользуюсь библиотекой ORM RedbeanPHP, в ней можно и простые запросы делать. Вопрос: можно упростить и хранить JSON в самой первой таблице с строками, блоками и их вариантами. Далее разобрать всё в PHP, но это уже будет не один запрос к базе, а как минимум 2-3. 1) Если писать вложенные запросы или JOIN-ами делать, будет ли какой-то профит в скорости? Стоит ли оно того? 2) Проще не париться и сделать несколькими запросами? 3) Многие ко многим, один ко многим - это моя тема, как то может помочь? Никак не могу понять( Я уверен, что можно сделать лучше, но не понимаю как. Не хотелось бы месяцы тратить на изучение. Помогите, пожалуйста правильно раскидать задачу. P.S. Есть таблица excel с демо-версией таблиц и запросом с JOIN-ами: disk.yandex.ru/i/oR98-Pt62ZZeIw
Дмитрий, спасибо за развёрнутый комментарий! К сожалению у меня все меньше время остаётся на ответы в RUclips, потому лаконично: 1. join может дать прирост скорости, потому стоит попробовать 2. вложенные запросы могут поначалу лучше читаться 3. насколько я понял, это именно ваша тема.
спасибо за замечательное видео!
объяснение просто пушка!
Спасибо! 👍
Действительно есть о чем задуматься в примере с предикатом "ANY".
Select name, population
from city
where population > any(
Select population
from city
where countrycode ='BRA'
)
and countrycode = 'JPN';
Не сразу понял, почему условие читается как "Города JPN с населением больше чем минимальное население города в BRA». Поразмыслив, понял что интерпретатор, при обработке данного запроса работает по следующей логике:
1. Взять население из 1-го города JPN
2. Взять население из 1-го города BRA
3. Сравнить население 1-го города JPN с население 1-го города BRA
4. Если Истина: население 1-го города JPN > чем население 1-го города BRA то город JPN попадает в выборку
5. Если Ложь то:
6. Взять население из 2-го города BRA
7. Сравнить население 1-го города JPN с население 2-го городом BRA
8. Ели везде будет ложь так далее до города BRA с минимальным населением и потом уже «общая ложь» и город не попадает в выборку
Потом Новый цикл со вторым городом JPN
Нечего не перепутал в логике?
Вы отлично вникли в суть работы этого запроса! (Если кратко, то найдутся все города JPN, население которых больше города с минимальным населением из BRA)
Благодарю вас! Мне кажется, подзапросы лучше давать перед джойнами, так людям будут понятнее джойны.
Благодарю за продуманный видео кадр - темный фон, крупный план.
Я вместо использование лимита в подзапросе сделал интересную вещь: использовал MAX(), MIN(), AVG() - так как он везде проставляет значения у всех пунктов (городов, например). Можно сказать, это обход ORDER BY и LIMIT.
а как могут MAX()/MIN() заменить LIMIT?
@@HtmllabRu я не совсем точно выразился. Они могут заменить его, когда интересен случай поиска того же максимума или минимума. По сути в видео было сравнение городов, население которых было больше чем население самого малонаселённого города. И вместо того, чтобы сравнивать всё со всем - можно взять город с минимальным населением одной страны (это будет в Any с помощью MIN()) и сравнивать это с другими городами. Мне кажется, так легче уяснить суть этих конкретно сравнений.
Я понимаю, что это в видео были просто примеры работы, но я вот попробовал сделать это по-своему.
Всё, что я имел ввиду - это, что эти функции могут заменить ORDER BY `some_field` LIMIT 1.
@@maxzhenzhera понял, точно)
Здравствуйте! Предупреждаю, что крайне слабо разбираюсь в sql. Делаю модуль с таблицами (в основном прайс-листы) на PHP, mySQL и JS. Есть TABLES, которая хранит номера строк через запятую. Есть таблица со строками TABLES_STRINGS, которая хранит ID строк и номера блоков, из которых она состоит. Одна строка может быть в разных таблицах. В таблице TABLES_BLOCKS блоки хранят свои ID, NAME и какие-то свойства, но без содержимого. У каждого блока может быть неограниченное количество вариаций содержимого - они хранятся в таблице TABLES_BLOCKS_VAR со своими ID и т.п. Есть таблица TABLES_STRINGS_BLOCKS_VAR, которая хранит информацию о том, в какой таблице какая вариация блока в строке (TABLE_ID, STRING_ID, BLOCK_ID, VAR_ID). Всё это сделано для: сколь угодно таблиц(прайсов) с разным составом строк, но где-то может отличаться тайтл или цена или другой блок. Зато, если поменять цену в одном блоке, то цена поменяется во всех таблицах, где она есть. Какая-то синхронизация. Для sql я пользуюсь библиотекой ORM RedbeanPHP, в ней можно и простые запросы делать.
Вопрос: можно упростить и хранить JSON в самой первой таблице с строками, блоками и их вариантами. Далее разобрать всё в PHP, но это уже будет не один запрос к базе, а как минимум 2-3.
1) Если писать вложенные запросы или JOIN-ами делать, будет ли какой-то профит в скорости? Стоит ли оно того?
2) Проще не париться и сделать несколькими запросами?
3) Многие ко многим, один ко многим - это моя тема, как то может помочь? Никак не могу понять(
Я уверен, что можно сделать лучше, но не понимаю как. Не хотелось бы месяцы тратить на изучение. Помогите, пожалуйста правильно раскидать задачу.
P.S. Есть таблица excel с демо-версией таблиц и запросом с JOIN-ами: disk.yandex.ru/i/oR98-Pt62ZZeIw
Дмитрий, спасибо за развёрнутый комментарий! К сожалению у меня все меньше время остаётся на ответы в RUclips, потому лаконично:
1. join может дать прирост скорости, потому стоит попробовать
2. вложенные запросы могут поначалу лучше читаться
3. насколько я понял, это именно ваша тема.
@@HtmllabRu Благодарю, уже сделал с джойнами одним запросом)