tanglirLumixво-первых смущает ваша приписочка особо не вчитывался))) возникает вопрос, а тогда понимаете ли вы о чем спрашиваете?А вы не смущайтесь. Я не вчитывался в то, берёте вы в данном конкретном отрывке предыдущий или следующий (соответственно какую сортировку ставить - аск или деск). И я не спрашиваю, а, напротив, советую. В вопросительной форме, да :)
Lumixно мне почему-то кажется, что запрос основанный на равенстве идентификаторов выполняется мгновенно, потому что дам индекс на бинарном дереве, а ваш запрос со сравнением и последующей сортировкой это слишком жирный алгоритм хрен знает какой протяженностикакой ещё "жирный алгоритм"? индекс на поле "пейджид" и вперёд - скорость, может, на пару процентов и будет ниже, зато он читабельней во много раз.
Lumixа решение Алекса (опять же как это понял его я) придется прогонять в цикле для каждой записи (на это как мне кажется, указывает харкодное 19 в его примере)Перечитал решение Алекса... скорее всего, вы правы.
А вообще в идеале должно было бы работать что-то наподобие
1.
2.
3.
update pages p
set prev=(select max(id) from pages q where q.id<p.id and q.hide=0)
,next=(select min(id) from pages q where q.id>p.id and q.hide=0)
, но увы, такое сервер не пропускает, а обходные пути сопоставимы по затратам с вашим вариантом...
извиняйте, не доглядел...я думал для конкретной записи обновление надо делать...
а раз для всех, то таки да - решение на подобе выше.
Но , собственно почему я думал что для одной...зачем постоянно перещитывать все?
а главное зачем ваще эти пред, некст, ну да ладно.
надо на инсерт делете апдейт ставить тригер
1)делете - самый лёгкий - удаляя запись с айди 10, пред 6 некст 15, значит 15 записи пред надо 6 поставить, а 6 некст 15
2) вставка - код тригера мой пример для обновления конкретной
3)апдейт - если делаем хайд, сравни удалению, аля 1), иначе аля 2)
ЗЫ
а если в таблице будет 10млн записей, это знаете ли память потребляет, и не факт что столько воткнёться в таблицу в мемори.
