Анатолий

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

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

А лично вам что не нравится в этом решении? Вы ведь не каждую фукнцию спрашиваете. Значит конкретно здесь вас что-то напрягает.

По мне так это простейший алгоритм, так как строки ни сортированы, и никак не связаны. В сортированных/связанных масивах все по другому думаю, там уже в зависимости от структуры метод переопределен скорее всего.

function indexOf(neededChar)
{
    for( q = 0; q < string.length; q++ )
    {
        if( string[q] === neededChar )
        {
            return q;
        }
    }
    return -1;
}

ru.wikipedia.org/wiki/Callback_(программирование) Не в паттернах дело, грубо говоря при начале какого-то действия, отдавайте в него же калбак, который должен выполниться по завершению, и при выполнении калбака смотрите, нужно ли еще это действие. Так приложение будет работать асинхронно, и не будет перетирать данные других действий, если человек недождался предидущего и нажал что-то новое.

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

Есть такая вешь как кеш. Кеш бывает разных видов, это не только выборка хранящаяся в файлике под рукой. Банальный пример карма на хабре. Я точно уверен что у них в базе хранится все данные, кто кому куда сколько раз ткнул плюсик или минусик, но видим мы лишь 3 (+4- 1). Своеобразный кеш нужных данные в отдельном месте. Вынесите связи отдельно специально для это й ленты, дублируйте данные, не бойтесь, дубли иногда помогают в производительности. Допустим сделайте для начала табличку активности:
id, user_id, event_desc, event_date
И при каждой активности заносите сюда данные, эта до невозможности простая табличка может одним запросом вывести всю активность пользователя в примитивном виде. Дальше уже развивайте мысль как удобно =)

Удобней всего наверно сделать определенные промежутки, и для каждого делать отдельную функцию возвращающую следующую дату:
getNextWorkDay(date), getNextWeekDay(date), getNextFirstDayOfMonth(date) итд.
+ Простые задачи на много проще универсальных
+ Это будет быстрей универсальной задачи
+ Это легче поддерживать
— Все промежутки нужно будет описывать отдельно

1. Вставка на 1000 записей произойдет мгновенно, потому как вам надо не все данные хранить а лишь айдишники.
2. Поэксперементируйте с запросами:
  2а. выбрать айдишники всех друзей
  2б. выбрат по айди всех друзей (да да, как бы смешно не звучало)
  2в. выбрать активность ленты
Иногда такие 3 запросы работают быстрей чам один джойн
3. «они могут захотеть *неожиданно* посмотреть посты из френдленты с 1000 по 1010.» — забейте
4. Если сообщения не изменяемые, то нет смысла сортировать по дате, первичный числовой ключ надеюсь есть? он всегда больше у последних записей
Это все что сходу в голову пришло.

В каждом языке есть функция сортировки которая принимает одним параметром массив, а вторым функцию обработчик, которая должна вернуть -1/0/1 и в зависимости от этого результата сортировка происходит как хочет разработчик. Почему бы Вам не воспользоваться этим?

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

если кто не понял
abcd
cd
a=c — no
b=c — no
c=c — yes
d=d — yes
max = cd

Это тупейший поиск похожих вхождений, как найти разницу думаю не составит труда =)

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