[sql] Вопросы по БД

работает но не полностью. не все айди выводит

вот запрос
"SELECT * FROM (SELECT * FROM hosts_on_site WHERE timestamp>'$nachalo_dnya' and user IS NOT NULL GROUP BY user UNION SELECT * FROM hosts_on_site where timestamp>'$nachalo_dnya' GROUP BY ip) AS hosts_on_site where timestamp>'$nachalo_dnya' GROUP BY ip ORDER BY id DESC;"


$nachalo_dnya=сегодня 00:00 таймштамп


ах да может это изза того что с разных айпи чел может зайти и пишется в базу айди один и тот же а ип разный.

 

кхым...
а без последней GROUP BY ip все айди выходят?
вместо timestamp>'$nachalo_dnya' - timestamp >= UNIX_TIMESTAMP(curdate())

 

не то надо уникальные айпи выводить а так он выводит все.

 

сделай так select distinct а потом подставь всё остальное, тогда будет сделана уникальная выборка с таблиц.

 

в это случае ему это не поможет.
Вообще ситуация не очень хорошая. Тут запрос нормально работать не будет. Тут сложная логика нужна.
Еще ситуация:
1|__2_|123.11.8.1
2|NULL|123.11.8.1
3|NULL|124.2.2.2
4|__1_|90.0.0.2
5|__1_|90.0.0.2
6|NULL|90.0.0.2
7|__3_|123.11.8.1 <- добавил
здесь ид 1 и 7 разные user'а (__2_ и __3_) но IP у них общий (сеть на работе, или провайдер выдает общий IP)
Ну и при группировке по IP мы кого-то "потеряем".
Совет др.вэбу ориентироваться не на ip пользователей. акцент сделать на userа в отдельной задаче если возможно.
user что IS NOT NULL обработать отдельно от тех что IS NULL.
будут 2 разные таблицы, 2 разных представления.
По другому нормально это не сделать, воображение подсказывает...

 

Плохо то что в Мускуле например как в Оракле нет аналитической функции, через неё можно было бы решить эту проблему, в практике было такое.

 

Ну объединить данные усилиями хранимых процедур, если дрвэб умеет, а хостинг дозволяет. Или это сделать в пхп, если данные за текущий день то видимо строк не много наберет.
Зависит от того как ему нужно отобразить эти данные? В виде таблицы данных или графиков? или еще чего

 

Сделайте EXPLAIN запроса, посмотрите какой индекс использует мускул для запроса. Если индексов несколько то можно попробовать в запросе принудительно использовать другой индекс USE INDEX () или форс. В зависимости от индекса может помочь.

 

Согласен с Art!P тоже может помочь.

Но тут уже дело в администрирование, база большая нужна разделить на partitions по датам и тогда ускорение достигается даже в случае выполнения запросов, затрагивающих все данные во всех партициях — ведь в этом случае сначала происходит первичная «обработка» таблиц по меньше, потом данные объединяются и производятся финальные вычисления. Так вот как раз «первые» этапы, в данном случае будут происходить гораздо быстрее.

 

Если честно то вопрос не понятен, как я понял тебе нужна распарсить маил, если так то лучше всего на уровне php сделать всё это, так как ну уровне базы будет очень долго работать.

 

Тут от поля email зависит, в таблице оно может быть уникальным полем. Добавления с помощью INSERT IGNORE

500млн и все с email? Подружиться чтоль с тобой

 

intertrey то что описали - думается самый лучший вариант. Ну у Вас таблица снабдится лишним полем domen (его лучше индексировать), всё окупается скоростью работы. Ограничение выборки это всегда было решением, ибо выборка из десятков..сотен миллионов или из тысяч - есть огромная разница.

 

Убрать все дубли, причем не должно быть 0-лей, NULLов.

 

Можно ещё PROCEDURE написать для этих дел.

 

Хай. Как проделать такую вещь:
Есть таблица с продуктами. И есть таблица со свойствами продуктов:

CREATE TABLE `attribute_values` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`product_id` int(11) NOT NULL,
`attribute_id` int(11) DEFAULT NULL,
`option_id` int(11) DEFAULT NULL,
`is_checked` int(11) DEFAULT NULL,
`value` text,
PRIMARY KEY (`id`),
)
Организовываю поиск по продуктам. Я делал через inner join и так для каждого аттрибута inner join писал. Потом когда я выбрал не одно свойство, а несколько, то результата запроса так и не дождался. Как это правильно организовать?

 

много как-то джоинов для 2-х таблиц-то и это не понятно.
Покажите запрос

 

Так в этом то и дело. Работает очень долго при выборе многих св-в. Получаются такие вот запросы:

Code:

SELECT `Catalog`.`id` FROM `main`.`cms_catalog` AS `Catalog`  
inner JOIN `main`.`cms_attribute_values` AS `J31` ON (`J31`.`is_checked` = 1 AND `J31`.`attribute_id` = '29' AND `J31`.`product_id` = `Catalog`.`id`) 
inner JOIN `main`.`cms_attribute_values` AS `J32` ON (`J32`.`is_checked` = 1 AND `J32`.`attribute_id` = '32' AND `J32`.`product_id` = `Catalog`.`id`) 
ORDER BY `Catalog`.`price` DESC LIMIT 30

 

Если всё правильно понял . Объединение таблиц и условия выборки (свойства продуктов вынесены в предикат)
SELECT `Catalog`.`id` FROM `main`.`cms_catalog` AS `Catalog`
inner JOIN `main`.`cms_attribute_values` AS `J31` ON `J31`.`product_id` = `Catalog`.`id`
WHERE
`J31`.`is_checked` = 1 AND (`J31`.`attribute_id` = '29' OR `J31`.`attribute_id` = '32')
ORDER BY `Catalog`.`price` DESC LIMIT 30

 

Понял правильно, но такой запрос почему-то не хочет работать. А если подойти с другой стороны. Можно ли как-то выбрать из таблицы со свойствами выбрать id продуктов, допустим у которых (is_checked=1 и attribute_id=12) и (is_checked=1 и attribute_id=13)? я вообще не могу понять как такой запрос составить

 

(is_checked=1 и attribute_id in (12,13)) и.т.д