LumixpageId, pageIdPrev, pageIdPost, pageIsHide

как одним запросом перепроставить предыдущий и последующий номера, исключив при этом все скрытые, т.е. игнорируя ненулевые pageIsHide?


вообще это геморные запросы обновления.
аля

apdate table
set f = IF(id=10,'new for 10', 'new for 11')
where id IN (10,11)

в твоём случае ещо сложнее.

проще делать два обновления, можно одним обращением к субд

а найти макс номер среди предыдущих где видимо, и минимальный среди следующих где видимо включено полагаю не проблема.

если хочеться всётаки одним.

например так



писал под свою таблицу чтоб убедиться в работоспособности

полагаю понятно как мы добиваемся разного обновления для разных строк - предыдущей 19 и следующией..

или так... но суть таже.

тут как никрути
надо найти сначала эту саму предыдущую и следующую запись, и потом для обновления
искать две строки и через иф обновить их так, что в нужной обновиться нужное поле.

tanglirLumixво-первых смущает ваша приписочка особо не вчитывался))) возникает вопрос, а тогда понимаете ли вы о чем спрашиваете?А вы не смущайтесь. Я не вчитывался в то, берёте вы в данном конкретном отрывке предыдущий или следующий (соответственно какую сортировку ставить - аск или деск). И я не спрашиваю, а, напротив, советую. В вопросительной форме, да :)
Lumixно мне почему-то кажется, что запрос основанный на равенстве идентификаторов выполняется мгновенно, потому что дам индекс на бинарном дереве, а ваш запрос со сравнением и последующей сортировкой это слишком жирный алгоритм хрен знает какой протяженностикакой ещё "жирный алгоритм"? индекс на поле "пейджид" и вперёд - скорость, может, на пару процентов и будет ниже, зато он читабельней во много раз.
Lumixа решение Алекса (опять же как это понял его я) придется прогонять в цикле для каждой записи (на это как мне кажется, указывает харкодное 19 в его примере)Перечитал решение Алекса... скорее всего, вы правы.
А вообще в идеале должно было бы работать что-то наподобие
, но увы, такое сервер не пропускает, а обходные пути сопоставимы по затратам с вашим вариантом...

извиняйте, не доглядел...я думал для конкретной записи обновление надо делать...
а раз для всех, то таки да - решение на подобе выше.

Но , собственно почему я думал что для одной...зачем постоянно перещитывать все?
а главное зачем ваще эти пред, некст, ну да ладно.

надо на инсерт делете апдейт ставить тригер
1)делете - самый лёгкий - удаляя запись с айди 10, пред 6 некст 15, значит 15 записи пред надо 6 поставить, а 6 некст 15

2) вставка - код тригера мой пример для обновления конкретной

3)апдейт - если делаем хайд, сравни удалению, аля 1), иначе аля 2)

ЗЫ
а если в таблице будет 10млн записей, это знаете ли память потребляет, и не факт что столько воткнёться в таблицу в мемори.

Lumixalex564657498765453надо на инсерт делете апдейт ставить тригер
1)делете - самый лёгкий - удаляя запись с айди 10, пред 6 некст 15, значит 15 записи пред надо 6 поставить, а 6 некст 15

2) вставка - код тригера мой пример для обновления конкретной

3)апдейт - если делаем хайд, сравни удалению, аля 1), иначе аля 2)

триггера не прижились, потому что их существование неочевидно
как и любые хуки они портят читаемость кода

alex564657498765453ЗЫ
а если в таблице будет 10млн записей, это знаете ли память потребляет, и не факт что столько воткнёться в таблицу в мемори.

на крайняк можно сделать обычную таблицу
а вообще мне идею подсказали, я её обдумываю - когда pre/post корректируются в момент живой работы
например по дефолту pre/post всегда +1/-1, но если происходит запрос pageId, который скрыт, то ищем след. живой и корректируем надстоящую и подстоящую записи, т.е. типа самокорректирующееся по ходу кеширование...

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

Lumixalex564657498765453Тригеры это не хук, это прямое решение задачи,

под словом хук я имел ввиду не слово хак на подонкоффском наречии, а слово hook (дословный перевод крючок)
хуком в кодинге называется все, что откуда-то из неведомой стороны автоматически взлетает само при наступлении некоторых условий потока, который находится в фокусе
неприятность хуков в том, что они являются частью среды, их можно обнаружить только при наступлении события (условия), а если условий много, то часто они порождают всякие неприятные изменения, которые хер знает откуда взялись

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

много лет назад, когда я только учился кодить у меня были реальные случаи нескольких дней поиска подобного бага и это не пожелаешь и врагу, с тех пор я очень сильно против хуков


alex564657498765453а вот на пхп запрашивать данные, смотреть на них, и на основании полученного делать вставку - вот это хук!

не пойму вообще о чем это...

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

термин "логика организации хранения данных" взрывает мой моск!!!)))) я понятия не имею что такое логика организации хранения данных.... мне не то, что сложно представить логику организации, мне даже сложно представить что такое "организация хранения данных"... если и включать фантазию на тему что это могло бы означать, то мне кажется это какая-то сисадминская задача по настройке сервера базы данных, но никак не кодерская задача...

например, в нашей команде для базы данных используются только для create table/view, insert, update, select, delete, drop table/view, никакими констрейнтами, триггерами или хранимками не пользуемся в принципе, потому что все они взрывают моск и слишком сильно увеличивают сроки разработки для команд с высокой долей новых участников


я тебя правильно понял, а вот ты меня нет.

поясню

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

вот есть база, захожу я и вижу тригер на вставку, смотрю ,понимаю, что при вставке нового елемента обновляються значения двух других, ибо это связанная логика. это прямое действие.

а вот на пхп написаный код, это хук, ибо смотрю в базу и не понимаю, почему я туда заносил одни значения, а тут бац, и кто-то, нафигато , переиначил поля. более того, смотрю тут таблица с какогото перепуга появляеться и ищезает.

ЗЫ
я понял что ты, написав опус выше, смотрел с точки зрения я пхпешник, всё остальное это плагины для моего мега кода.

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

ЗЫЗЫ
счас модно говорить что ооп это круто, а без ооп, это куча хуков :) - изменение данных влетает не пойми откуда.
идея ооп, чтобы данные лежали вместе с логикой их взаимосвязи, изменения...

вот и подумай, где логичное место кода для

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

3 пример ещо интересен вот чем

допустим у нас
несколько процессов одновремено вставляют ещо одну.(20 пхп процессов)
это каждым собираешься всю таблицу обновлять???

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

если данные и код для поддержания логики с этими данными вместе, оно надёжно.