C архитектурой/выборкой с таблицы?

Так тоже делали, остановились пока что на варианте сковозного order_id для каждого пользователя.

C архитектурой/выборкой с таблицы?

Про uid интересно, спасибо. Но тогда может быть имеет смысл заводить order_id сквозной для каждого пользователя. Если когда-нибудь этот order_id понадобится пересчитать, то можно будет отсортировать по date_created все записи пользователя и выставить им order_id по порядку.

C архитектурой/выборкой с таблицы?

Условие

WHERE id > %s 

бывает срабатывает не так, как надо. Например, на таких данных:

INSERT INTO `tbl_timeline` (`id`, `data`, `date_created`)
VALUES
	(397, NULL, '2013-07-24 11:21:32'),
	(382, NULL, '2013-07-23 21:10:57'),
	(428, 51, '2013-07-23 17:59:13'),
	(425, 49, '2013-07-23 17:52:15'),
	(422, 48, '2013-07-23 17:45:14'),
	(418, 46, '2013-07-23 17:38:14'),
	(432, 45, '2013-07-23 17:26:25'),
	(375, NULL, '2013-07-23 16:15:51'),
	(368, NULL, '2013-07-22 15:16:28'),
	(412, 32, '2013-07-22 14:51:22'),
	(415, 36, '2013-07-22 14:51:22'),
	(358, NULL, '2013-07-22 00:16:25'),
	(353, NULL, '2013-07-21 15:14:16'),
	(349, NULL, '2013-07-20 14:12:49'),
	(346, NULL, '2013-07-19 12:17:28');

Проблема получается в том, что нижележащие ID могут быть как больше текущего, так и меньше.

C архитектурой/выборкой с таблицы?

Размер POST'а как такового не большой, согласен. Но трафик неслабый будет гоняться на бэкэнд, а это уже получается дорого. В идеале нужно решение, которое позволило бы по одному ID выбирать записи для следующего шага.

C архитектурой/выборкой с таблицы?

Эти отображенные записи надо где-то хранить и как-то их передавать. А таскать за собой хвост в post-запросе из кучи ID отображенных записей не очень хочется, потому что записей на странице могут быть тысячи.

C архитектурой/выборкой с таблицы?

Спасибо, попробую. Это, скорее, не недостаток, а фича.)

C архитектурой/выборкой с таблицы?

UPD:

Классические запросы вида

select * from timeline where ORDER BY date_created DESC LIMIT start, 10

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

Эту проблему можно решить, сделав ограничение сверху по первой выбранной записи в самый первый раз. Но как строить последующие запросы? Чтобы выбирать все отсортированные по date_created записи меньше начального ID?

C архитектурой/выборкой с таблицы?

Вспомнил, где была проблема — рано радовался.

Смысл в том, что сверху ограничить просто и быстро у меня не получилось — можно либо по ID, либо по date_created. Но как ограничить по ID записи, отсортированные по date_created — я не очень представляю.

C архитектурой/выборкой с таблицы?

Было и так, ничего хорошего не вышло. По причине:

Сортировку по первичному ключу тоже не получится сделать — в будущем в таблицу timeline могут писаться события за прошлые периоды и ID, выступающий в роли order_id, потеряет свою актуальность.

C архитектурой/выборкой с таблицы?

Так было с самого начала, конечно же.

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

Спасибо, натолкнули на еще одну мысль.

График курсов валют ЦБ?

На sberometer.ru в другом прикол — советы и оперативная инфа (наглядно видно, что с рублем происходит). Еще можно мониторить непосредственно на бирже (rts.micex.ru), но там черт ногу сломает.

Как назначить сразу 2 обработчика в jQuery: blur + keydown?

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

Как назначить сразу 2 обработчика в jQuery: blur + keydown?

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

Как назначить сразу 2 обработчика в jQuery: blur + keydown?

Как в onblur тогда узнать, что до него точно сработал onkeydown и надо смотреть наличие ошибки? Потому что onblur может сработать, когда я просто с инпута кликом уйду.