Вот структура БД:
CREATE TABLE `irbis_indexing_index` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`link` int(11) NOT NULL DEFAULT '0',
`stem` int(11) NOT NULL DEFAULT '0',
`times` int(11) NOT NULL DEFAULT '0',
PRIMARY KEY (`id`),
KEY `idx_index_linkstem` (`link`,`stem`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
CREATE TABLE `irbis_indexing_link` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`uri` varchar(255) NOT NULL DEFAULT '',
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
CREATE TABLE `irbis_indexing_stem` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`stem` varchar(30) NOT NULL DEFAULT '',
`sound` char(4) NOT NULL DEFAULT 'A000',
PRIMARY KEY (`id`),
KEY `idx_stem_stem` (`stem`(8)),
KEY `idx_stem_sound` (`sound`(4))
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
Задача следующая. Имеется массив значений $stems (т.н. "стеммы" слов). Нужно выбрать значения поля uri (ссылки) из таблицы irbis_indexing_link, для которых есть совпадения в irbis_indexing_stem со стеммами из массива $stems и отсортировать их в порядке убывания по полю times из irbis_indexing_index (число повторения стемма для каждой ссылки).
Таблицы irbis_indexing_stem и irbis_indexing_link связаны с помощью таблицы irbis_indexing_index (irbis_indexing_index.link = irbis_indexing_link.id и irbis_indexing_index.stem = irbis_indexing_stem.id).
Надеюсь, понятно объяснил )
Делаю такой запрос:
$res = mysqlQuery(
'SELECT il.`id`, il.`uri`
FROM `' . IRB_DBPREFIX . 'indexing_link` il,
`' . IRB_DBPREFIX . 'indexing_index` ii,
`' . IRB_DBPREFIX . "indexing_stem` iw
WHERE iw.`stem` IN ('" . implode("', '", $stems) . "')
AND ii.`stem` = iw.`id`
AND il.`id` = ii.`link`
GROUP BY il.`id`
ORDER BY ii.`times` DESC
");
ошибок никаких нет, но и результата тоже. Подскажите плиз, что я не так делаю?
Спустя 1 час, 11 минут, 17 секунд (26.01.2011 - 23:28) inpost написал(а):
А почему ты начал одинарной, а закончил двойной?
Покажи, какие данный внутри, какие должны получить =)
Покажи, какие данный внутри, какие должны получить =)
Спустя 25 минут, 30 секунд (26.01.2011 - 23:53) Invis1ble написал(а):
inpost
Цитата |
А почему ты начал одинарной, а закончил двойной? |
с кавычками там все ok =)
Данных внутри много (их тысячи), могу привести пару-тройку записей для наглядности:
таблица irbis_indexing_link
id | uri
---|-----------------------------------------------
37 | http://localhost:8080/IRBIS-core/test/1.html
38 | http://localhost:8080/IRBIS-core/test/1-1.html
таблица irbis_indexing_stem
id | stem | sound
-----|-------------|------
6795 | domashn | D525
6796 | stranic | S365
6889 | programmist | P626
таблица irbis_indexing_index
id | link | stem | times
-----|----|------|------
3535 | 37 | 6795 | 1
3536 | 37 | 6796 | 1
3537 | 37 | 6889 | 1
3629 | 38 | 6889 | 4
Примерно такие данные....
В $stem к примеру такие данные:
$stem = array('stranic', 'programmist');
На выходе (после прогона через цикл с mysql_fetch_assoc()) должен быть массив:
array('http://localhost:8080/IRBIS-core/test/1-1.html', 'http://localhost:8080/IRBIS-core/test/1.html');
Спустя 48 минут, 17 секунд (27.01.2011 - 00:41) waldicom написал(а):
Вот такой запрос работает точно
Попробуйте его в PHPMyAdmin, должно вывести 2 строки (с теми данными, которые приведены в топике).
Если не выводятся данные, значит затык в двух местах:
1. массив $stems содержит неправильные данные
2. неправильная обработка рещультатов в while
По первому пункту: просто выдать массив с помощью print_r() или вывести окончательно сформированный запрос.
По второму что-то типа:
Затем позволю себе дать пару советов:
- пишите запросы с внешними двойными кавычками, и внутренними одинарными. Т.е. типа
- не давайте таблицам такие длинные имена, если нет необходимости. Например в данном случае indexing не нужен (хотя это конечно так себе совет... на любителя)
SELECT l.`id`, l.`uri`
FROM `irbis_indexing_link` l
LEFT JOIN `irbis_indexing_index` i ON l.id = i.link
LEFT JOIN `irbis_indexing_stem` s ON i.stem = s.id
WHERE s.`stem` IN ('stranic', 'programmist')
GROUP BY l.`id`
ORDER BY i.`times` DESC
Попробуйте его в PHPMyAdmin, должно вывести 2 строки (с теми данными, которые приведены в топике).
Если не выводятся данные, значит затык в двух местах:
1. массив $stems содержит неправильные данные
2. неправильная обработка рещультатов в while
По первому пункту: просто выдать массив с помощью print_r() или вывести окончательно сформированный запрос.
По второму что-то типа:
$result = mysql_query($query);
if($result){
while($row = mysql_fetch_assoc($result)){
$resArray[] = $row['uri'];
}
}
Затем позволю себе дать пару советов:
- пишите запросы с внешними двойными кавычками, и внутренними одинарными. Т.е. типа
$query = "SELECT * from `table` where `name` = 'vasja'";
- не давайте таблицам такие длинные имена, если нет необходимости. Например в данном случае indexing не нужен (хотя это конечно так себе совет... на любителя)
Спустя 36 минут, 23 секунды (27.01.2011 - 01:18) Invis1ble написал(а):
waldicom
Цитата |
в данном случае indexing не нужен |
indexing добавлен во избежании возможного конфликта имен, т.к. не известно, какие таблицы еще будут в БД.
Запрос вроде-бы работает корректно (в смысле так как мне надо), но мне нужен более тщательный анализ, который затруднен из-за большого объема данных... Попозже отпишусь.
Спустя 21 секунда (27.01.2011 - 01:18) inpost написал(а):
waldicom
Я не думаю, что это совет на любителя =). Вот пишут, что самые быстро-обрабатываемые переменные - название до 7 символов, больше символов, то уже производительность падает на 15%, и так далее до 30%. Если это правда, хотя лично не проверял, то в мускулом должно же быть что-то схожее =) Хотя там может быть алгоритм работы другой...
Invis1ble
Предел нубства, я подписываю свои функции, классы в css, константы приставкой "inp_", не придумал ничего более умного, чтобы отделить свою часть от других.
Я не думаю, что это совет на любителя =). Вот пишут, что самые быстро-обрабатываемые переменные - название до 7 символов, больше символов, то уже производительность падает на 15%, и так далее до 30%. Если это правда, хотя лично не проверял, то в мускулом должно же быть что-то схожее =) Хотя там может быть алгоритм работы другой...
Invis1ble
Предел нубства, я подписываю свои функции, классы в css, константы приставкой "inp_", не придумал ничего более умного, чтобы отделить свою часть от других.
Спустя 19 минут, 3 секунды (27.01.2011 - 01:37) Invis1ble написал(а):
inpost
Цитата |
Предел нубства |
Чьего нубства? Не совсем понял тебя, если чесно....
Спустя 4 минуты, 34 секунды (27.01.2011 - 01:42) waldicom написал(а):
Цитата (Invis1ble @ 26.01.2011 - 23:18) |
indexing добавлен во избежании возможного конфликта имен, т.к. не известно, какие таблицы еще будут в БД. |
Тоже верно. Хотя для таких целей и служит префикс (в Вашем случае IRBPREFIX)
Цитата (Invis1ble @ 26.01.2011 - 23:18) |
но мне нужен более тщательный анализ, который затруднен из-за большого объема данных. |
Что за анализ?
Спустя 13 минут, 37 секунд (27.01.2011 - 01:55) Invis1ble написал(а):
waldicom
дело в том, что префикс irbis_ скорее всего будет дублироваться в названиях других таблиц другими разработчиками (теоретически), а вот вероятность повторения второго префикса близка к нулю.
дело в том, что префикс irbis_ скорее всего будет дублироваться в названиях других таблиц другими разработчиками (теоретически), а вот вероятность повторения второго префикса близка к нулю.
Цитата |
Что за анализ? |
Эх..... долго объяснять ) точнее я не знаю, как получше сформулировать мыслю.... Поэтому лучше отпишусь о результатах. Пока что вроде все нормально.
Спустя 8 минут, 12 секунд (27.01.2011 - 02:03) Invis1ble написал(а):
waldicom
Все класс, большое спасибо.
Осталось мне только сортировку похитрее немножко сделать... буду думать.
Все класс, большое спасибо.
Осталось мне только сортировку похитрее немножко сделать... буду думать.
_____________
Профессиональная разработка на заказ
Я на GitHub | второй профиль