Выборка записи с одновременным получением id следующей и предыдущей записи записи

[Magiys]

Выборка записи с одновременным получением id следующей и предыдущей записи записи

Такая проблема:
1. Есть две таблицы одна пусть называется _screens, другая - _products.
2. _screens - подчиненная таблица, _products - главная, связь одни ко многим.

Пример содержимого _screens
screenID | screenProductID | screenField1 | screenSort
1 | 1 | data1 | 0
2 | 1 | data2 | 3
3 | 1 | data3 | 5
4 | 2 | data4 | 0
5 | 2 | data5 | 2
6 | 2 | data6 | 7

3. На сайте есть некий элемент, который отображает скриншот и у него есть две ссылки: следующий, предыдущий.
4. В результате запроса необходимо получить:

Входных параметров может быть два: это screenProductID и screenID, но по идее screenID - этого достаточно.

Входной параметр, допустим, screenID = 2
screenID | screenProductID | screenField1 | screenSort | lastScreenID | nextScreenID | screenSum
2 | 1 | data1 | 3 | 0 | 2 | 3

Входной параметр, допустим, screenID = 4
screenID | screenProductID | screenField1 | screenSort | lastScreenID | nextScreenID | screenSum
4 | 2 | data4 | 0 | 6 | 4 | 3

Где:
lastScreenID - ID предыдущего скриншота, в зависимости от screenSort, если screenSort для указанного screenID минимальное, то необходимо взять screenID, у которого screenSort максимален.
lastScreenID - ID следующего скриншота, в зависимости от screenSort, если screenSort для указанного screenID максимально, то необходимо взять screenID, у которого screenSort минимален.

То есть должна быть циклическая прокрутка в обе стороны при нажатии на ссылки "следующий", "предыдущий".

Причем, screenSort изменяется неравномерно.

======

Пробывал так:

SELECT
	t.*,
	(
		SELECT screenID
		FROM screens
		WHERE screenShort < t.screenShort
		LIMIT 1
	) as lastScreenID,
	(
		SELECT screenID
		FROM screens
		WHERE screenShort > t.screenShort
		LIMIT 1
	) as nextScreenID
FROM
	(
		SELECT
			scr1.*,
			MIN(scr2.screenSort) as minScreenSort,
			MAX(scr2.screenSort) as maxScreenSort,
			COUNT(scr2.screenID) as sumScreens
		FROM
			screens as scr1
		WHERE
			scr1.screenID=$screenID
		LEFT JOIN
			screens as scr2 ON scr2.screenProductID=scr1.screenProductID
		GROUP BY
			scr2.screenProductID
	) as t

Тут я не могу установить зависимость между lastScreenID и maxScreenSort, nextScreenID и minScreenSort.

Как я писал, одно их этих полей в паре должно быть использовано. Так, например, если текущий screenID имеет минимально значение screenShort, то lastScreenID - будет равно NULL, в этом случае необходимо взять maxScreenSort в качестве этого значения.

Надеюсь на помощь.

P.S. Возможно, все гораздо легче...

P.S.S. Может возникнуть вопрос, почему именно необходимо реализовывать такую навигацию по скриншотам через указания ID, я хочу сделать ссылки, прямо указывающие на тот или иной скриншот, а не относительно отображаемого текущего скриншота.

 

[zerkms]

LEFT JOIN x2
но, имхо, проще сделать дополнительные запросы

 

[Magiys]

Да, похоже, что это единственное решение. Спасибо за ответ.

 

[Gas]

Magiys
По идее, если завернуть твой запрос в ещё один

SELECT *, IFNULL(lastScreenID,maxScreenSort) AS prev, IFNULL(nextScreenID,minScreenSort) AS next
FROM (

... твой запрос ...

) AS t2;

можно получить нужный результат
?

-~{}~ 24.01.08 11:43:

Или даже так:

SELECT
	t.*,
	IFNULL ( 
		(SELECT screenID
		FROM screens
		WHERE screenShort < t.screenShort
		LIMIT 1),  maxScreenSort
	) as lastScreenID,
	IFNULL ( 
		(SELECT screenID
		FROM screens
		WHERE screenShort > t.screenShort
		LIMIT 1), minScreenSort
	) as nextScreenID
FROM
	(
		SELECT
			scr1.*,
			MIN(scr2.screenSort) as minScreenSort,
			MAX(scr2.screenSort) as maxScreenSort,
			COUNT(scr2.screenID) as sumScreens
		FROM
			screens as scr1
		WHERE
			scr1.screenID=$screenID
		LEFT JOIN
			screens as scr2 ON scr2.screenProductID=scr1.screenProductID
		GROUP BY
			scr2.screenProductID
	) as t

 

[Вася Патриков]

Возможно самообъединение таблицы поможет, если одним запросом хочется...

 

[dark-demon]

/picture/123 ссылкается на:

* /picture/123/prev
* /picture/123/next ссылается на:

* * /picture/177/prev
* * /picture/177/next

и так далее

плюс - единовременно нам необходим только один айдишник
минус - засоряется кэш, если таковой вообще используется (каждая страница доступна по 3 разным ссылкам в зависимости от того как до неё дошли)
плюс - можно организовать витиеватое листание
минус - ссылки полученные при листании не являются перманентными

 

[Magiys]

Gas, я об этом не подумал, спасибо, так и сделаю.
Вася Патриков, исключено, но как вариант... спасибо.
dark-demon, такой способ, чтобы как раз этих минусов не было.

 

[dark-demon]

могу поспорить, что в данном случае этими минусами можно пренебречь.