Альтернативы LEAD и LAG в SQLite
Мне нужно найти альтернативу LAG и LEAD для поиска предыдущей и следующей записи в моей таблице в SQLite, поскольку они не поддерживаются в используемой версии (обновление не является вариантом). Но я также не могу использовать значение, которое я заказываю, поскольку это может быть дата и, следовательно, может быть идентичным для нескольких записей. Поскольку таблица должна быть отсортирована по дате, использование идентификатора тоже не вариант.
Было бы здорово, если бы кто-нибудь знал альтернативный способ решения этой проблемы, поскольку после более чем часа поиска и попыток у меня закончились идеи.
Редактировать:
Важные столбцы для моего варианта использования:
_id booking_date
1 2017:11-21
3 2017:11-21
4 2017:11-21
5 2017:11-21
2 2017:11-22
6 2017:11-22
7 2017:11-22
...
_id - это первичный ключ. Заказы необходимо отсортировать по дате. Возможно несколько бронирований на одну и ту же дату. Бронирования с одинаковой датой сортируются по их идентификаторам (см. Идентификаторы 2, 6 и 7 в приведенном примере).
Мне нужен способ запросить запись до и после записи по ее идентификатору.
Например, для _id = 6 мне нужен запрос, который выбирает строку с _id = 2, и запрос, который выбирает строку с _id = 7.
В качестве альтернативы, единственный запрос, который выбирает оба, будет работать так же хорошо.
Мне не нужно, чтобы вы предоставляли весь запрос, а скорее подход к этой проблеме.
Я надеюсь, что предоставленная дополнительная информация и примеры будут вам полезны.
. . . Таблицы SQL представляют собой наборы неупорядоченный. Вы даже не используете _id для заказа, поэтому на ваш вопрос нельзя ответить с использованием предоставленных вами данных.
В реальной таблице _id, конечно же, предназначен для заказа. Но в таблице представлены бронирования. Каждое бронирование имеет идентификатор, дату, представляющую время выполнения для этого бронирования [НЕ время создания] и все значения, связанные с бронированием, которые не важны для этой задачи. при отображении списка бронирований имеет смысл упорядочивать бронирования по дате, а не по идентификатору. Но чтобы запросить только предыдущее бронирование, нельзя просто использовать дату, поскольку на одну дату может быть несколько бронирований. Но на самом деле есть решение, о котором вы, видимо, не подумали.
Ответы 2
Попробуйте что-то подобное, это извлекает предыдущий и следующий идентификаторы данной записи с использованием вашего порядка сортировки (по дате + идентификатору) - предполагая, что id является первичным ключом, вы можете получить другие столбцы для предыдущих и следующих записей, используя эти идентификаторы:
SELECT *,
(SELECT id FROM t t1
WHERE t1.booking_date < t.booking_date
OR t1.booking_date = t.booking_date AND t1.id < t.id
ORDER BY booking_date DESC, ID DESC LIMIT 1 ) prev_id,
(SELECT id FROM t t1
WHERE t1.booking_date > t.booking_date
OR t1.booking_date = t.booking_date AND t1.id > t.id
ORDER BY booking_date , ID LIMIT 1 ) next_id
FROM t
order by booking_date, id
Демо: http://www.sqlfiddle.com/#!5/17631/2
| id | booking_date | prev_id | next_id |
|----|--------------|---------|---------|
| 1 | 2017-11-21 | (null) | 3 |
| 3 | 2017-11-21 | 1 | 4 |
| 4 | 2017-11-21 | 3 | 5 |
| 5 | 2017-11-21 | 4 | 2 |
| 2 | 2017-11-22 | 5 | 6 |
| 6 | 2017-11-22 | 2 | 7 |
| 7 | 2017-11-22 | 6 | (null) |
Умный ответ и способ сделать это без задержек. Спасибо!
Если бы таблица выглядела так, окончательный выбор был бы довольно тривиальным.
_id booking_date seq
1 2017:11-21 1
3 2017:11-21 2
4 2017:11-21 3
5 2017:11-21 4
2 2017:11-22 1
6 2017:11-22 2
7 2017:11-22 3
seq - количество строк в одной и той же дате бронирования с меньшим идентификатором. Вы можете создать виртуальное представление с этой структурой для управления основным выбором.
Это возможный подход. Поскольку вы не запрашивали «весь запрос», я оставляю вам решать, как реализовать эту идею.
Но поскольку это не похоже на это, этот ответ совершенно бесполезен, не так ли?
@Jujinko Ты должен мне проголосовать. Обратите внимание на последнюю строку You could create a virtual view with this structure to drive the main select. . Другими словами, создайте структуру, которая будет выглядеть так: делает. Фактически, я создал репро, но ОП хотел «подход», а не «весь запрос». Спасибо за объяснение отрицательного голоса и за возможность опровергнуть и уточнить мой ответ.
Пожалуйста, предоставьте образцы данных и желаемые результаты. Чтобы использовать
lead()/lag(), ваш стол в любом случае потребует стабильного упорядочивания. Какие ключи обеспечивают стабильное упорядочивание?