Форум MySQL

Искал решение своей проблемы по форуму, возможно плохо искал, есть похожее, но все же не то.

Столкнулся с задачей написания небольшого сайта знакомств и сразу уперся как мне казалось в простую проблему, а именно организация общения между пользователями, и если уж совсем честно, принцип хранения истории сообщений.
Наверняка многие знакомы с таким проектом как МАМBA (http://www.corp.mamba.ru/) и их знакомствами. Например: (lov.ru или love.rambler.ru, и многие другие). Очень хотелось бы узнать, каким образом у них организована система переписки. Хотя бы приблизительно. Или иное мудрое решение этого.
Основные условия задачи таковы:
1. История сообщений не удаляется до тех пор пока пользователь не удалит свой аккаунт, при этом копия истории остается у пользователя (-ей) который с ним общался.
2. Если пользователь решит удалить из своей контактной книги собеседника, история остается у собеседника, но стирается у пользователя. Таким образом если пользователь решит возобновить общение с собеседником, то все будет выглядеть так, как буд-то до этого со стороны пользователя, переписки с собеседником не было.
3. Пользователю должно сообщаться общее кол-во новых сообщений от всех контактов и кол-во новых по каждому пользователю.

В общем все просто, но. Все это НЕ должно убить сервер при кол-ве пользователей в несколько тыс. и кол-ве сообщений в истории свыше 1 млн. и далее.

Была мысль создать несколько таблиц с сообщениями и раскидывать по ним историю в зависимости от ID пользователя. Все бы хорошо, но запрос на выборку выглядит как-то дико.
Была мысль просто создать доп. таблицу, куда скидывались бы старые сообщения. Тоже не вариант, все равно получится 1 к 2, 2 к 3 и так далее. Основную таблицу будет уверенно раздувать.

Можно так же тексты сообщений выносить в отдельную таблицу, а в головной держать только строки вида:

id | from_id | to_id | owner_id | msg_id | read_status
1 | 100 | 10 | 100 | 123 | 0
2 | 100 | 10 | 10 | 123 | 0

id | message
123 | 'Hello world'

Но тоже как то... Хотя может, что-то можно выжать из этого. Но все равно две таблицы.... нет. не вариант.

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

ps В работе используется PHP 4.4.3, mysql 4.1. Сервер Apache 2.

ps Пожелания вида: "Иди в школу" и "Иди с этим Г в и на...", просьба не писать. Начитался уже сполна.

В общем как говорится ПЛИЗ ХЭЛП. Буду ОЧЕНЬ признателен!

А чем не подошел вариант

id | from_id | to_id | owner_id | msg_id | read_status 1 | 100 | 10 | 100 | 123 | 0 2 | 100 | 10 | 10 | 123 | 0 id | message 123 | 'Hello world'

?

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

Объясняю. Был у меня когда-то ресурс примерно с такой же структурой таблицы по сообщениям. Так вот. На, где-то 30 тыс. пользователей выходило свыше 1 млн. сообщений (хранил до 10-20 сообщений по каждой паре собеседников) в основной таблице и около 2-х млн. в таблице истории. Админ постоянно ругался, что мол обращения к этой таблице грузят мускл. Мол: "Делай, что хочешь, а снизь кол-во записей". Ну и плюс время от времени, приходлось запускать REPAIR TABLE, в силу падения таблы. Потому и терзаюсь мыслью, что делаю не так.