Не надо спрашивать "как". Надо заучить - "никогда".
Звезду в запросах используйте только в одном случае - в COUNT(*). Во всех остальных случаях - перечисляйте все нужные поля по одному, с указанием алиасов таблиц. Да, при этом текст запроса длиннее, и набирать его дольше - но это убережёт от кучи нелепых ошибок, которые сперва долго ищешь, а, найдя, ничего не можешь сказать кроме как "во я идиот"...
FanatPHP, я как-то слабо понимаю суть вашего спора. И мне сдаётся, что он уже слабо связан с исходным вопросом, ибо непонятно откуда, но вылезли заданные значения event_id, которые в исходном вопросе не определены. К тому же не вижу смысла обсуждать абстрактно, какой способ связывания выберет сервер, проще посмотреть план - а он, в свою очередь, критично зависит от наполнения и статистики.
Но для меня главное - то, что к каждому событию прилагается определённый пользователь. Что, в свою очередь, означает, что заявки интерактивные, а количество записей невелико. А потому - ну не похрен ли? как запрос не построй, всё одно он будет быстрым, даже если в таблице вообще индекса нет, и даже если сервер решит, что записи надо отсортирить перед связыванием.
Да, если говорить о предложенных решениях, то подзапрос на выборку имеющих заявки на не менее чем 2 разных эвента я бы построил как
SELECT user_id FROM events GROUP BY user_id HAVING MIN(event_id) < MAX(event_id)
Так он будет немного быстрее, ибо индекс (user_id, event_id) будет использоваться полностью, а не как компактная версия таблицы. Если такой индекс, конечно, есть...
Не, а в чём проблема пройти по кабелю-то? ведь с гарантией не более ста метров...
К тому же, зная все точки, куда подключен этот скрытый хаб (он же не только за два компа, но и ещё за какой-то вышестоящий свитч зацеплен), можно с достаточно больной вероятностью предположить, где он.
Что-то не помню я приборов (про мамкины тесты даже не заикаюсь), которые умеют определять длину кабеля, когда на дальней стороне висит активное оборудование.
Человек, которому покласть с пробором на то, "как работает компьютер и технологии в целом", вполне может быть успешным программистом. Большинство программистов, которых язык не повернётся назвать неуспешными - не творцы, а обычные ремесленники.
Это точно так же, как человек, которому насрать на перспективу, тени и состав красок, может быть вполне успешным маляром.
Зависит от движка изменяемой таблицы и того, что повреждено. Если нет разрушения файловой системы и транзакционный движок - недовыполненная транзакция просто откатится без каких-либо последствий.
AND genres LIKE "%{ARG_GENRES}%"
Это фигня. AND LOCATE(genres, REPLACE({ARG_GENRES}, '|', ',')
При этом сами genres не должны содержать запятых, а передаваемый параметр - паразитных пробелов между разделителем и значением.
Каждый мультипараметр разворачиваешь, потом кроссджойнишь всё это и получаешь набор критериев для натурального соединения.
Я ведь правильно понимаю, что: ARG_GENRES = 'Sci-Fi|Action' - это запрос на фильмы, которые помечены хотя бы одним из тегов списка? REGEXP = 'Terminator' - это всегда подстрока? или там реально может быть паттерн?
Ну и уж коли захотелось задавать "фильтр по количеству строк в выводимом результате" - то неплохо бы указать точную версию SQL-сервера. А для того, чтобы народ мог проверить свои предложения - создай online fiddle (или хотя бы выложи CREATE TABLE + INSERT INTO) и дай пару наборов (список критериев + требуемый результат на этих данных).
ChairfaceChippendale, версионка. Впрочем, как по мне, это единственный реально значимый плюс у машки по сравнению с мускулем, хоть и сделанный откровенно через задницу.
FanatPHP, я бы поостерёгся говорить, что у MySQL и MariaDB различия - чисто косметика. Там столько всего накопилось разного, что куда как спокойнее считать их вообще разными СУБД. И мелкие доделки, подтаскивающие второе к первому, ничего не меняют, потому что первое ко второму подтаскиваться не будет даже в теории, равно как из второго выпиливаться различия также не будут.
А вот насчёт того, что общего у них всё же овердохрена - это стопроцентно.
Не надо спрашивать "как". Надо заучить - "никогда".
Звезду в запросах используйте только в одном случае - в COUNT(*). Во всех остальных случаях - перечисляйте все нужные поля по одному, с указанием алиасов таблиц. Да, при этом текст запроса длиннее, и набирать его дольше - но это убережёт от кучи нелепых ошибок, которые сперва долго ищешь, а, найдя, ничего не можешь сказать кроме как "во я идиот"...