[Coutty]

Может быть неверно задаётся адрес директории?
Выведите переменную: echo $final_path перед выполнением этого ветвления.
Вообще, здесь надо использовать относительный путь, а не абсолютный. Например: opendir("./images/dir0001")

Вообще выражение "Пока ЛОЖЬ не РАВНО <ПЕРЕМЕННАЯ> присвоить функция (параметр) делать... " меня как-то пугает... уж больно неструктурно это выглядит (хотя на php.su приведён именно такой пример). »

Это пример из официальной документации php. От перемены мест сравниваемых, результат не меняется. Но исключается возможность присваивания вместо сравнения (иногда по ошибке можно написать if ($a = false) { ... }. А вот обратное присваивание точно выдаст ошибку: if (false = $a) { ... } ).

[ManHack]

Добавление в базу сделано.

Теперь надо написать поиск.
Поиск должен искать слова из 1 строки сразу в 3 столбцах таблицы и выдавать результаты по их релевантности.
Сколько не бился - толком ничего не вышло.
Подскажите, а?

И/или хотя бы обясните пословно, что здесь написано:

Код:

"SELECT id FROM CoreLibrary WHERE title LIKE '%". str_replace(" ", "%' OR title LIKE '%", $good). "%'"

($good - данные из строки поиска)
Знак % что даёт? и кавычки как-то странно стоят, аж жуть....

А вот здесь ещё непонятнее:

Код:

"SELECT *, MATCH row1 AGAINST ('$search')+MATCH row2 AGAINST ('$search')+MATCH row3 AGAINST //('$search') as relev FROM CoreLibrary ORDER BY relev DESC"

здесь $search = $good в пред. случае.
AGAINST? MATCH? DESC?

[Coutty]

"SELECT id FROM CoreLibrary WHERE title LIKE '%". str_replace(" ", "%' OR title LIKE '%", $good). "%'"

Выбрать столбец id из таблицы CoreLibrary, где запись в столбце title совпадает с маской поиска (LIKE). Маска поиска состоит из строки запроса ($good), где функцией php str_replace() заменяются пробелы на знаки процента, которые дополнительно добавляются в начале и в конце строки. Знак процента в SQL означает "любые символы". Как * в Windows. Также к результатам добавляются строки (OR), где идёт поиск только по заданной строке, хотя я не вижу в этом смысла - всё равно ведь % их найдёт.
Но согласен, скобки стоят странно. Было бы правильнее расставить их так:

"SELECT id FROM CoreLibrary WHERE title LIKE '%". str_replace(" ", "%", $good) . "%' OR title LIKE '". $good . "'"

Второй запрос:

"SELECT *, MATCH row1 AGAINST ('$search')+MATCH row2 AGAINST ('$search')+MATCH row3 AGAINST //('$search') as relev FROM CoreLibrary ORDER BY relev DESC"

Да, здесь посложнее.
SELECT *, ... - выбрать все строки, удовлетворяющие условию, и справа добавить столбец relev - релевантность поиска (по нему потом идёт сортировка).
MATCH колонка AGAINST ('строка поиска') - полнотекстовый поиск по столбцу. Таблицы должны иметь индекс для полнотекстового поиска. Видимо, здесь идут три подзапроса по разным столбцам, потом им задаётся общее имя (AS relev) и по этой колонке (ORDER BY relev) уже сортируется по убыванию (DESC).
Хотя странно выглядит)

Подробнее о полнотекстовом поиске можете почитать здесь, если интересно. Я не совсем разобрался =~_~=

[ManHack]

Последний запрос (с релевантностью) возвращает таблицу целиком с дополнительным столбиком "relev", в котором одни нули... Почему? $search совпадает со значениями row1 в двух строках.

И где можно получить информацию по "ERROR: "Неизвестная строка с пунктуацией @ 96"" (cобственно, интересуют описания этих самых @96, @100 и т.д.)

[ManHack]

Вопрос про нолики отпал... И правда, релевантность начинает подсчитываться, когда в базе 10 и более записей...

Теперь, как с ней манипулировать? Чтобы при точных запросах по нескольким столбцам таблицы выдавала только точные ответы (как в медиапоисковиках или поиске по электронным библиотекам,например)

[Coutty]

При точных запросах вам не нужна релевантность. Вам нужно точное совпадение:

Код:

SELECT * FROM table_name WHERE stolb1 = 'запрос' OR  stolb2 = 'запрос' OR stolb3 = 'запрос'

Но обычно полную строку никто не ищет, поэтому вместо stolb = 'запрос' пишите stolb LIKE '%запрос%'. Т.е. пробелы внутри запроса будут обрабатываться как есть, но сама подстрока будет обнаруживаться как в начале, так в середине и конце строк.
Чтобы упорядочить выдачу, добавьте в конце ORDER BY stolb_name ASC
ASC - по возрастанию (указывать не обязательно, т.к. по умолчанию), DESC - по убыванию. Можно указать несколько полей через запятую, тогда упорядочивание будет производиться сначала по первому, потом по второму и т.д.(имеется в виду, что в первом поле "автор" Пушкин будет идти после Гоголя, конечно, но у самого Пушкина произведения будут упорядочены по второму полю "название").

Прим: LIKE - странная штука. Когда я делал поиск по прайсу, она находила даже запросы длиной меньше 4 символов, но что это были за результаты... Каждый раз что-то своё. И только больше 4 символов запроса находились точно.

[ManHack]

С этим разобрались. Я решил пока что отказаться от LIKE и всё выполнил через MATCH AGAINST.
В SQL мой запрос работает отлично, а вот в написанном PHP'шнике - шиш.

Суть php-файла:

PHP код:

// забираем данные из формы в переменную $search и обрабатываем её

$good = trim(preg_replace("/\s(\S{1,1})\s/", " ", ereg_replace(" +", "  "," $search ")));

// вывод $good на экран показал, что выводится она правильно (в соответствии с запросом в $search)



// ...



$sql = "SELECT *, MATCH title AGAINST ('$good')+MATCH avtor AGAINST ('$good')+MATCH genre AGAINST ('$good') AS Relev FROM $table WHERE MATCH (avtor) AGAINST ('$good') ORDER BY Relev DESC"; // в SQL это работало!!

$result = mysql_query($sql) or die ("err_code = " . mysql_error()); //ошибки не выдаёт

echo $result; // возвращает[b] Resource id 3[/b], пробовал [b]count($result)[/b] как для массива, вернуло значение 1 (1 элемент в переменной $result) 

В чём теперь дело?
Может я обращение к результатам запроса неправильно делаю? или что ещё?

[Coutty]

Вы бы почитали руководство PHP касательно работы с MySQL. Там даже примеры есть.
mysql_query() и должно возвращать идентификатор ресурса. Теперь его надо обработать:

PHP код:

echo "<table>";

while ($line = mysql_fetch_assoc($result)) // возвращает одну строку из ресурса в виде ассоциативного массива

   {

   echo "<tr><td>$line['stolb1']</td><td>$line['stolb2']</td><td>$line['stolb3']</td></tr>";

   } 

[ManHack]

Тьфу ты, точно... Вылетело из головы >_<
Спасибо!

[ManHack]

echo "<table>"; while ($line = mysql_fetch_assoc($result)) // возвращает одну строку из ресурса в виде ассоциативного массива { echo "<tr><td>$line['stolb1']</td><td>$line['stolb2']</td><td>$line['stolb3']</td></tr>"; } »

Вот только так не прокатит на самом деле. Ассоциированные массивы не имеют индексов.
Поэтому придётся использовать конструкцию типа foreach ($array as $value) { *** последовательная обработка элементов строки*** }