Я столкнулся с довольно странной проблемой. У меня есть следующие примеры данных для работы в базе данных MySQL:
|key| data| index | total | timestamp |
| # | a | 1 | 2 | 2009-01-02 01:01:32 |
| $ | b | 2 | 2 | 2009-01-02 01:03:32 |
| % | c | 1 | 3 | 2009-01-03 01:01:32 |
| ^ | d | 2 | 3 | 2009-01-03 01:04:32 |
| & | e | 3 | 3 | 2009-01-03 01:02:32 |
| * | f | 1 | 2 | 2009-01-05 01:01:32 |
Что происходит, так это то, что другой процесс (не под моим контролем) получает пакеты данных и сохраняет их непосредственно в базе данных с отметкой времени прибытия. Предполагается, что пакеты поступают в пакете ... a, b будут приближаться друг к другу и индексируются 1 и 2, причем каждый пакет содержит общее количество переданных пакетов. ключ - это обычный первичный ключ с автоинкрементом.
Что мне нужно, так это представление, в котором будет отображаться последний полученный список (допустим неполный список, если не все пакеты получены).
Для вышеприведенного запроса в идеале результат должен быть только "f", но я не вижу способа сделать это. Если мы не можем получить это по-другому, возвращение «a» и «f» будет приемлемым. Другими словами, небольшое количество дополнительных данных, отлавливаемых оператором select, не является большой проблемой. В течение периода времени, предшествующего прибытию "f", правильный возврат - c, d и e.
Мои общие мысли были такими:
SELECT * FROM table WHERE total = (
SELECT total FROM table WHERE timestamp = (
SELECT MAX(timetamp) FROM table
)
)
ORDER BY DESC timestamp
LIMIT (
SELECT total FROM table WHERE timestamp = (
SELECT MAX(timetamp) FROM table
)
Как некоторые из вас, вероятно, заметили, вы не можете выполнить подзапрос в предложении LIMIT (по крайней мере, с помощью mysql). У кого-нибудь есть другой подход к решению этой проблемы? Приведенный выше запрос можно было бы сделать намного чище, вложив JOIN в небольшой список недавних идентификаторов, но это по-прежнему оставляет проблему подзапроса LIMIT в подзапросе.
Как двухэтапный запрос, это относительно тривиально. Проблема в том, что он должен стать определяющим оператором select для VIEW.
Редактировать, чтобы исправить неправильный пример SQL