pageId, pageIdPrev, pageIdPost, pageIsHide

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

Ура, я нашел суперрешение для расстановки не только моего простейшего условия, а вообще ЛЮБОЙ where-выборки!!
Вот готовый код на тестовой базе:




Спасибо всем, кто отозвался и помог!

tanglirLumix
эээ... а не проще ли так
или меньше+desc, я особо не вчитывался.

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

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


tanglirНу и плюс к тому решение алекса - один запрос, у вас это целый скрипт.

у меня решение из 4 sql команд, которые выполняются ОДНИМ запросом с точки зрения программного кода самой программы, а решение Алекса (опять же как это понял его я) придется прогонять в цикле для каждой записи (на это как мне кажется, указывает харкодное 19 в его примере). Мой пример, можно скопировать и сложить в run.sql файл и скормить mysql < run.sql и он выполнится, а его пример в sql файл не сложишь, придется писать скрипт на каком-нибудь языке программирования

tanglir,

просто на stackoverflow про комплект max() + order by + limit пишут всякие штуки типа 100 times slower вот поэтому я почему-то их стараюсь избегать...

поправьте меня если я не прав
explain select мне ничего по этому поводу не проясняет
а как провести тестирование для бенчмаркинга этого комплекта я пока ума не приложу

javajdbc,

во-первых, не совсем понятно о каких картинках идет речь...)))

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

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

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

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

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

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

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

javajdbcдополнительно искать: получили страницу, и нее
СИКВЕНС_НУМБЕР 23, ну так предыдуший линк на 22
а следуюший на 24 -- что может быть проше?


вы предлагаете использовать вариант с двойной адресацией доставания объекта
по реальному pageId и по синтетическому pageIdSeq

сейчас рендер объекта obj = get(pageId)
а вы предлагаете что теперь будет obj = pageIdSeq ? getByIdSeq(pageIdSeq) : get(pageId)
вот в чем минус

javajdbcLumix,

а зачем двойной доступ? там где по ИД --
пишите по гетБуИД, там где по СЕК --
пишите гетБуСек... зачем смешивать?

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

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

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

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

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


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

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

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

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

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

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

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

http://www.willamette.edu/~fruehr/haskell/evolution.html

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

да, есть такое

alex564657498765453поясню

не помогло ((
как-то неструктурированно...


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

не особо всекаю при чем тут ооп, объекты и триггера в базе
я думал речь идет о месте размещения логики: в коде или в базе
наш подход: 1) только в одном месте, 2) и это место - код

alex564657498765453вот есть база, захожу я и вижу тригер на вставку,

у нас нет такого действия: захожу в базу и вижу
я его исключил на уровне архитектуры

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


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

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

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

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


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

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

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

я что-то давно уже расстался с концепцией центра
мне ближе концепции атомарности, общения между атомами, специализация ответственности и т.п. вещи

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

концепция ооп вообще не имеет никакого отношения к хукам
на ооп можно работать с хуками, а можно без них
ооп вообще не про это


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

1)на каждую вставку записи про то что вася перечислил нам 10 баксов, обновить баланс у юзера вася на +10


в наших системах это реализовано так:



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

интерфейсно, поскольку подобная функция очень дорогая, то она используется всего в двух местах:

1) кнопка "Пересчет" в форме пользователя для управления менеджером

2) кнопка "Нормализация" когда происходит обсчет всех пользователей (ну или выборки по фильтрам, вплоть до выборки всего одного) и перерасчет всех балансов (ну по этой кнопке ещё куча всяких разных обработок по пользователям происходит). короче суть этой кнопки в том, что если что-то не так, то нажимаешь, ждешь 20 минут и вся система отлично нормализована и все круто + список всяких расхождений, вопросов, сомнений, подозрений и т.п.

alex5646574987654532)при создании юзера, создать запись для этого юзера в таблице друзья и вписать другом модератора

у нас это реализовано так



под капотом этой функции собран огромный набор инструментов, гибко, эффективно и понятно управляемый через входящий таскер, а комбинаций вариантов работы функции там тысячи и все это очень гибко завязано на интерфейсы и разные случаи. То есть в системе может быть до 300 различных вариантов вызовов user.add() с разными параметрами. Под 300 вариантов я имею ввиду если мы нажимаем Ctrl + Shift + F и вводим в поиск user.add( , то у нас будет найдено 300 строк во всем проекте





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

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

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

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

я кстати заметил одну вещь: по-моему ты тяготеешь к созданию систем с высокой долей универсального автоматически действующего кода ну типа я бы мог заподозрить, что в твоих системах 60-75% кода носит универсальный, фреймворковый характер, а в наших системах доля такого кода составляет 20-30%, потому что нам приходится работать в условиях очень часто изменяемых требований со стороны заказчиков и создавать решения, действующие в условиях сильной внешней параметризации со стороны пользователей

у нас вместо ваших 60-75% универсального кода, выстроена специальная архитектура и набор методов и подходов построения инструментов, ну мы используем что-то типа convention over configuration

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


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

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

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

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

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

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