Подгрузка контента и обновление UID без insert?

Question

[Сергей]

Есть скрипт PHP где выводятся данные из таблицы MySQL. Есть два столбика uid (уникальный ключ) и timepub (время публикации). Вывод идёт c ORDER сначала по timepub потом по uid (ввиду того что иногда timepub обновляется). Раньше было не критично, так как выводилось c использованием постраничной навигации, теперь требуется сделать подгрузку ajax с кнопкой "Показать еще". Тут встал вопрос, если делать подгрузку по последнему uid (select * from `table` where `uid` > Х limit 30), то не получается ввиду того, что uid идут не по порядку, а закладывать в условие timepub не очень хорошее решение, так как могут быть записи с таким же timestamp. Получается первое что пришло на ум, это при обновлении timepub обновлять и uid.
Вопрос собственно по обновлению и по собственно всей ситуации. Возможно ли как то обновить uid при помощи одного запроса в mysql, вместо удаление старой записи и добавления новой? И вообще возможно я не туда думаю, и есть какие то другие решения запроса для подгрузки контента?
Буду благодарен за любую подсказку и помощь!

Answer 1

[Борис Сёмов]

Вам нужно оба параметра limit в запросе использовать просто(смещение и количество), и увеличивать смещение каждый запрос), и не делать никаких условий по uid или timepub.
Собственно, ничего не отличается от постраничной навигации, в плане запросов, на самом-то деле. Меняется только форма вывода на фронтэнде...

Comments

[Сергей]

Нет я как раз хотел реализовать запрос без использования интервала лимита, так как mysql проходит все равно все записи и тем самым лимит 1000,1040 выполняется посредством перебора 1040 записей. В случае с условием where > uid таким образом проход записей не происходит и нагрузки при большом кол-ве записей нет.
Поэтому и решил заменить пагинацию на подгружаемую ленту :)

[Борис Сёмов]

Зачем вам limit 1000,1040? Нужен limit 1000,40. К тому же, пребор 1000 записей, это не так уж проблемно - это совсем мало данных, а сотнями тысяч и тем более милионами строк, никто не будет скролить ваш список, если вообще там есть столько. Мало того, эти запросы можно же кешировать, если у вас нагрузка велика.

[Сергей]

Борис Сёмов, извиняюсь все верно "40", ну всё таки хочется меньшей нагрузки и реализовать по нормальному без двойных лимитов. Думаю не зря этот метод с двумя лимитами не советуют на просторах сети и призывают использовать именно условия для стартовой позиции отсчета.

[Борис Сёмов]

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

[Сергей]

Борис Сёмов, просто в перспективе есть вариант больших данных и кешировать можно, но из-за against match вариаций очень много запросов. Поэтому хотелось бы заранее сделать по фэншую )))
Все таки по поводу обновления ID реально без insert или лучше двойным запросом удалять и создавать просто новую запись с такими же данными, не подскажите?

[Борис Сёмов]

А каким образом вы собираетесь назначать новый uid? Его не получится поддерживать одновременно уникальным и соответствующим порядку timepub просто отдельными запросами(даже если он будет разреженным) - придётся массово переколбашивать его у множества записей для изменения порядка же. А без соответствия эта операция просто бесполезна.

По поводу больших данных - не выводят много данных таким методом. Никто не будет просто листать бесконечную ленту. Т.е. они не бесконечны, на самом деле. И закладываться на то, что когда-нибудь надо вывести будет 100500 элементов в таком списке совершенно не разумно, а на разумных количествах ваш подход это бессмысленная оптимизация, которую и не сделать будет так просто, как вы думаете, к тому же.
Даже если у вас и будет в базе очень много записей, и какой-то пользователь будет уж очень упёрт, раньше браузер к него ляжет от размера страницы, чем mysql, тот же, от запросов с лимитом, если уж на то пошло...

Ну и если это ему действительно нужно зачем-то окажется, то это будет означать, что у вас интерфейс как-то не так спроектирован. =)

Answer 2

[Сергей]

Решение нашёл на другом ресурсе. Если кому понадобится.

Запоминаем у последней записи выведенной на экран два поля uid(далее uX) и время публикации(далее tX)

select * from `table` where timepub <= tX and concat(timepub, lpad(uid, 12, '0')) < concat(tX, lpad(uX, 12, '0')) order by timepub DESC,uid DESC limit 30