любые дополнительные таблицы всегда уменьшают скорость работы, складываем всё-всё в одну.
Согласен. Исправлю на «любой дополнительный JOIN или запрос всегда уменьшает скорость работы.».
Я поклоняюсь Нормальной форме, как и многие тут. Но я давно понял, что есть три крайности: Производительность, Простота и Нормальная форма, между которыми приходится выбирать.
Если процессор обрабатывал задание «на будущее», то он должен его бросить и начать обрабатывать критичное. А если он занимается обработкой критичного задания, то ничего не поделаешь, будет лаг.
Моё предложение как раз и заключается в том, что бы обработать все данные заранее. А если условия будут изменяться, то заново перерасчитывать с даты изменения.
Во первых, утверждение «Всё в одну таблицу» относилось лишь
к списку недвижимости. Помещать в эту таблицу что то кроме
недвижимости не надо :)
…
Приведу ссылку с Хабра же.
«B-tree Операция поиска выполняется за время O(t logt n), где t –
минимальная степень. Важно здесь, что дисковых операций мы
совершаем всего лишь O(log t n)!»
Логарифм значит, что при при увеличении базы данных в 2 раза,
время поиска возрасает лишь на одну операцию сравнения
(или дисковую операцию, хотя это не всегда так).
Вот и получается, что бы найти нужную запись среди 1.000.000 записей
тратится 0.1 сек. А среди 2.000.000 записей (в одной таблице)
тратится 0.101 сек.
Если мы будем искать в двух таблицах по 1.000.000 записей, то соответсвенно
у нас уйдет 0.2 сек.
…
Или давайте я приведу человечесский пример. У вас есть бумажный телефонный
справочник Москвы, в котором все фамилии упорядочены. Я прошу найти вас человека
с определенной фамилией. Правда ведь это просто? ВЫ открываете по середине
справоника, смотрите букву, затем открываете на середине одной из половин…
И так, уменьшая количество страниц каждый раз в раза раза, вы доберетеь до имени.
1000, 500, 250, 125, 65, 33, 17, 8, 4, 2, 1
Итого 1000 страниц за 11 подходов.
А потом, я даю вам 20 телефонных справоников городов в 20 раз меньше и
прошу найти человека.
50, 25, 12, 6, 3, 2, 1
Итого 50 страниц за 7 подходов. А так как у нас 20 справочников, то всего
будет 140 подходов. Это более чем в 10 раз больше!
Вы хотите добавить в письмо изображение, которое бы не светилось в списке прикрепленных файлов, и которое можно с помощью тега img вставить в любое место текста?
То есть вам нужно количество объединенных (пропущеных) записей. Можно воспользоваться GROUP BY, вот так:
select min(id), action, user_id, count(*) from (
select *, @w:=@w+case when ifnull(@a<>action or @b<>user_id, 1) then 1 else 0 end as w, @a:=action, @b:=user_id from (
select *, @a:=0, @b:=0, @w:=0 from table1 order by id
) as t
) as t
group by action, user_id, w order by id
Можно ввести дополнительную переменную @n. Можно (попытаться) написать это без под запросов, но это будет менее наглядно.
P.S. Выполните еще перед этим запросом "set @a:=@b:=0" на всякий случай. Если хочется обойтись одним запросом, то можно в подзапрос завернуть: select id,action,user_id from (select *, @a:=@b:=0 from table1) as t where (@b:=user_id)+(@a:=action)+(@w:=ifnull(@a<>action or @b<>user_id, 1))+1 and @w limit 20. Способов много.
Может шутка. Может безобидная DNS-атака. Может быть интерпол таким образом прикрыл сайт, вдруг там исходники Windows 7 выложили. Ну и версия Seigmen, про защиту от DDOS-атак, тоже интересна.
Я знаю. Но таков был вопрос топикстартера: "Вообще идеальным был бы некий счет, который можно было бы пополнять максимально возможным количеством способов с привязанной к нему картой."
P.S. блин enter нажался :(