Кто хорошо разбирается в mysql?

#33 Как то так

SELECT inbox.id,outbox.id FROM inbox,outbox WHERE (inbox.user='$log' AND inbox.autor='$uz') OR (inbox.autor='$log' AND inbox.user='$uz') ORDER BY inbox.time,outbox.time;

Исправляюсь

SELECT inbox.id AS inbox_id,outbox.id AS outbox_id FROM inbox,outbox WHERE (inbox.user='$log' AND inbox.autor='$uz') OR (inbox.autor='$log' AND inbox.user='$uz') ORDER BY inbox.time,outbox.time;

Вот так лучше.

#36, поддерживаю. Запрос будет быстрее выполняться из одной таблицы чем из двух.

44. NEx в данном примере да быстрее, а если нужно отделить входящие от отправленных и когда сообщений очень много, тогда лучше делать в разных таблицах, например на висави в данный момент около 20мб приватных входящих сообщений только, а фактически максимальный (20кб*2500юзеров) /1024 = 48 мб, это если никто почту чистить не будет

Нужна еще помощь, как лучше сделать полноценный поиск по базе
Каким образом лучше искать, Я так понял LIKE ищет не очень быстро
Как искать например если пользователь ввел сразу три слова и надо найти не по И а по ИЛИ
я делаю сейчас примерно так

<?php
Database::$forum->sqliteCreateFunction ('utflower' , 'rus_utf_tolower');
$querysearch = Database::$forum->query("SELECT * FROM topics WHERE utflower(topics_title) LIKE '%".rus_utf_tolower($findme)."%' ORDER BY topics_last_time ASC;");
dump($querysearch->fetchAll());

Все нормально, но это ищет точное сходство, я думаю сделать что-то типа если слов несколько то разбивать их и добавлять в поиск условие ... OR LIKE %...% OR LIKE %...% ... как по производительности кто знает?

Сильно я думаю не нагрузит,норм

#45 Нет, ты не выйграешь от разделения.
Таблицы абсолютно одинаковой структуры и хранят одинаковые данные. Потому, смело можно хранить в одной таблице и потом сортировать выборкой.
К примеру, в твоем варианте:
время 1-го запроса + время 2-го запроса + время посылки 1 SQL + время посылки 2-го SQL
Время посылки, я имею ввиду комманду mysql_query() ибо она тоже съедает определенное время на обработку.
Для дной таблицы, общее время получается меньше. А если еще правильно проиндексируешь, вообще быстро будет.

#46 Насчет времени поиска - всецело зависит от размера базы и правильной индексации.
К примеру, если ищешь в поле TEXT, то если нужен быстрый поиск, надо создать полнотекстовый индекс. Да, зохавает до 30% дополнительного пространства базы, но зато при поиске, все будет максимально быстро и снизится нагрузка на базу.

C поиском что-то сложновато
при обработке своей функцией sqliteCreateFunction ('utflower' , 'rus_utf_tolower');
и выборке из 50 тыс сообщений уходит 4 сек,
если использовать встроенную функция LOWER() или UPPER() то 0.4 сек, но при этом не преобразовывает UTF8.
Все это из-за преобразования в верхний или нижний регистр
Индексация не сильно помогает, а база увеличилась более чем в 2 раза, было 12.5мб, стало 28мб
Не знаю даже что и делать

Vantuz (16 Сентября 2009 / 00:59)
вот типа такого что-то должно быть,
но может как-то проще можно
SELECT * FROM inbox WHERE inbox_user=$uz AND inbox_author=$log UNION ALL SELECT * FROM outbox WHERE outbox_user=$uz AND outbox_author=$log ORDER BY inbox_time DESC;

Решил я по твоему методу сделать, так сто раз пожалел =)
Решил сделать примерно такую структуру

CREATE TABLE `rotorcms`.`privat` (
    `privat_id` int NOT NULL AUTO_INCREMENT,
    `privat_type` enum('in', 'out') CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL,
    `privat_inbox` varchar(21) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL,
    `privat_otbox` varchar(21) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL,
    `privat_time` int NOT NULL,
    `privat_text` text CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL,
    `privat_read` bool NOT NULL,
    PRIMARY KEY (`privat_type`, `privat_inbox`, `privat_otbox`, `privat_id`),
    INDEX ( `privat_id` ) 
) 
ENGINE = InnoDB CHARACTER SET utf8 COLLATE utf8_general_ci;