Глеб Старков, да пусть перетаскивается вместесо ссылкой. просто чувствительная область для перетаскивания пусть будет не весь див-контейнер, а какая-нибудь ручка, по типу такого:
baranovstas, await ничего не передает, это сахар синтаксический.
грубо говоря вызовом then(func) ты устанавливаешь внутреннее свойство объекта промис, указываешь ему колбэк, который будет вызван в момент вызова resolve, при этом в resolve ты передаешь параметр, который будет передан в колбэк.
вот ооочень грубая реализация, без защит и поддержки цепочек: https://jsfiddle.net/m601Lu3v/
вместо кода приведен какой-то надерганный из разных мест копипаст. Скорее всего дело в том, что в набор движений записывается только одна строка - последняя после перебора ТЧ.
FanatPHP, по какому индексу? по дефолту индекс только на примари кей есть, больше информации у нас нет. если есть составной индекс на user_id, event_id, то все равно будет полный скан индекса, но таблицы будут предсортированы, да, если на event_id, user_id - то да, обе подтаблицы будут почти наверняка будут предсортированы, скорее всего будет два частичных сканирования индекса и мердж джоин (один цикл по двум таблицам одновременно). но при наличии такого индекса и вариант с подзапросом также отработает хорошо - скорее всего там будет одно частичное сканирование индекса + цикл агрегации.
При отсутствии индекса или при несоставных индексах - вариант с подзапросом будет лучше.
Все очень зависит от того, как это дело воспримет планировщик запросов СУБД. Повторюсь - при использовании подзапроса у него "пространства для маневра" просто меньше. Вот тут неплохо описаны различные способы выполнения джоинов: https://docs.microsoft.com/ru-ru/sql/relational-da...
>я, блин, такого словоблудия давно не видел
словоблудие началось с "почему не джоином?". тут-то мои навыки анализа затыков в производительности sql запросов и пригодились.
FanatPHP, мердж джоин и нестед лупс - это способы получения результирующей таблицы из двух соединяемых подтаблиц на условно "физическом" уровне. это в sql профайлере надо смотреть. не уверен, что в mysql explain это покажет, а вот в postgres и ms sql - показывает. первый требует предварительную сортировку обеих таблиц по предикату соединения, второй - это цикл в цикле. соотвтетсвенно, планировщик СУБД оценивает, сколько нужно времени на сортировку двух таблиц + цикл и на цикл в цикле и выбирает вариант соединения. при неправильной статистике по данным может быть больно. В варианте с подзапросом планировщик всегда выберет сортировку (одну!) + цикл. Это почти наверняка будет лучше (и 100% не хуже), причем более стабильно (планировщик не сможет ошибиться).
ivanivanov15122021, с точки зрения когнитивной нагрузки этот вариант более предпочтителен (относительно формулировки задачи) ИМХО. С точки зрения производительности разницы не должно быть.
Хотя судя по вопросу там не >=, а = должно быть
