Помогите в решении задачки: Нужно сделать выборку SELECT Есть вот такая таблица table: ID USER_ID DATE_ADD 10 938 4087333 9 456 4087222 8 123 4087123 7 938 4086999 6 456 4086967 5 938 4086952 4 456 4086845 3 123 4086623 2 938 4086512 1 456 4086456 Задача: 1) сгруппировать по USER ID. 2) отобрать только те, где разница между одним и предидущим DATE меньше 400 К примеру: В таблице id 10 и id 7 пользователь USER_ID = 938 И разница между DATE_ADD: 4087333 - 4086999 = 334 Значит он подходит под выборку, так как отбираем тех разница DATE_ADD меньше 400
@crystaltrumpet, в таблице пользователя 938 гораздо больше двух, с какого перепугу именно 10 и 7, а 5 и 2 где? Боюсь изначально архитектура БД не продумана, для нынешних хотелок.
я имею ввиду сравнивать все USER ID 10 с 7... потом последовательно 7 с 5 потом 5 с 2.. я имею ввиду сгруппировать все USER_ID и сравнить последовательно один с предыдущим
@crystaltrumpet, группировка так не работает После GROUP BY нет никаких 10, 7 и тд. Прочитай в интернете про "проблему молотка", это поможет грамотно задавать вопросы на форумах, а в последствии и грамотно ставить задачу перед собой и находить решение без обращения на форум.
я для примера привел причем тут 10 и 7.. написал условие: сгруппировать по USER_ID и сравнить каждое с предыдущим.
То есть другими словами с Вашей точки зрения и Вашими знаниями нельзя решить данную задачу средствами MySql? Я правильно понял? Если Вдруг я найду решение - обязательно опубликую его здесь или, возможно, кто-то скажет что это реально и из участников данного форума. Буду благодарен. Я конечно могу использовать php все занести в массив и уже циклом сравнить но это ресурсозатратно ( вот поэтому и ищу более изящное решение
@crystaltrumpet, я же написал вам в первом сообщении, что скорее всего неправильная архитектура БД. Для того что бы работать с данными на уровне СУРБД, необходимо сначала эти данные правильно хранить. Существуют законы нормализации и принципы построения архитектуры БД, пренебрежение этими законами и правилами как раз и приводят к ситуациям когда приходиться реализовывать хотелки на стороне РНР. Вполне возможно, что я вас недопонял и недоразобрался в текущей ситуации. Но на вашем месте я бы особо на это не рассчитывал PS Самое простое решение это добавить столбец хранящий разницу между текущим и предыдущим значением. Но повторюсь архитектура БД это 50% всей работы над проектом. Поэтому трудно давать советы не видя всей картины.
Что там может быть неправильного в архитектуре.. все работает годами и как часики. Тем более скрипт шаблонный и не я его писал там три простых значения ID USER_ID - это ID зарегистрированного пользователя DATE_ADD - это UNIX время (я в примере просто написал примерные цифры не стал писать 10-значное время)
Как написали выше, вы пытаетесь нарастить доп. функционал, не трогая структуру БД и не пересматривая алгоритм. В мускуле тоже можно использовать алг. конструкции и т.п., но это скорее всего будет еще хуже, чем если бы вы сделали это в пыхе. Если я правильно понял при беглом просмотре темы, вам нужно реализовать очередь с возможной переустановкой последней добавленной записи с учетом частотности (это примерно как события движения от мышки в очередь добавлять). Делается еще на этапе добавления при помощи INSERT... ON DUPLICATE KEY UPDATE... при условии, что не требуется фиксировать/логгировать все действия. --- Добавлено --- P.S. Ключами, по кот. фиксируются совпадения, тут могут выступать кванты времени. Ну, только будет не от последнего меньше 400, а чтобы не было двух и более сохраненных записей, попавших в один квант длительностью 400.