FanatPHP: незнаю чем там кто там пугал, не сталкивался нисчем страшным. Все подготовленные запросы, если их принудительно не закрывать, живут в пределах соединения. Если использовать постоянное соединение, то можно добиться вечноживущих подготовленных запросов. В принципе оптимизатор postgre штука очень умная, но все же для частых запросов я предпочитаю сэкономить ресурсы.
И кроме того синтаксис php ф-ий для работы с posgre подразумевал использование имени, посему я его оставил. Удобно на самом деле, потом отслеживать чего куда кого.
vilgeforce: Действительно. Просто где то попадалась статья на тему выбора кеш функций для больших текстов, найти не смог решил вопрос задать. Но в зоде переписки подумалось, что вероятно просто обработать такой случай и забыть.
grihan: ну для начала sphinx, elasticsearch смотрели? У последнего даже в бете уже было очень много инструментов для работы и сопоставления текста.
Дело ведь не только в хранении, вам явно нужен FTS
Про виртуальные машины согласен, но вот азчем отдельные базы? Схемы внутри одной бд решают вопрос с разделением доступа, но позволят хоть крос запросы между ними делать если нужно будет.
3ton: ibm x346, покупал 8-9 лет назад: 2xXeon 3.4, 8-16 (в зависимости от сервера) GB DDR, 10-15k RPM Raid 1
Среднее время выборки не превышало 300мс, при том что на этом сервере было много чего еще интересного.
Дублирование сообщений делалось с целью возможности хранения независимых историй: отправитель трет у себя все сообщения, получатель имеет их копию, или наоборот. Немного непонял причем тут идентификаторы)
Immortal_pony: офигеть, тото у меня странное чувство последние полгода не покидает что раньше я менее строгие группировки писал. А можно узнать что но с этими полями делаем? 8) min, max, avg, group by? O_O
если есть 1с, то стоит начать так же с изучения структуры бд 1с, чтобы получать у нее карточки товара и штрихкоды, но информации по этому делу исчезающе мало. Хотя если решитесь - стучите.
