AVES-CLUB

Avanty:кстати, хочу заявить официальный протест! Шо за на... фигня! куда пропали мои циферки в графе кол-ва сообщений!
Должно уже давно было быть 666. Ан нет! Каким то непостижимым и магическим способом кол-во уменьшилось. Или кто то приложил свою модераторскую руку или одно из двух!

ещё пять сообщений, тебя забанят и будет навечно такая циферка :rotfl:

ну, ей богу, какая нафиг разница, сколько сообщений?? :shock:

softic:ну, ей богу, какая нафиг разница, сколько сообщений??

А зачем тогда счётчик?

Нужен более продвинутый счетчик - с прокачкой персонажа по различным уровням (технических знаний, общения, активности в пыжетусовках, флуде и пр.) ;-)

А зачем все это?! Ам... Чтобы люди видели что ты супер пупер абалдено много пишеш и супер гений общения? По моему многим и так понятно к кому и с каким вопросом обратиться.
Не вижу смысла, может кто объяснит?!

Архангел:А зачем все это?! Ам... Чтобы люди видели что ты супер пупер абалдено много пишеш и супер гений общения? По моему многим и так понятно к кому и с каким вопросом обратиться.
Не вижу смысла, может кто объяснит?!

А ты вдумчиво прочитай еще два раза, может увидишь, что дело не в цифрах.

Nord:Имеем (упрощенно)
7.000 операций + 100 * 700.000 операций в первом случае (70.007.000) и
7.000 операций * 700.000 операций + 100 * 700.000 во втором (4.970.000.000)

Если достижение такой цели (распределение всех сообщений всех юзеров по всем разделам) действительно необходимо, то один из вариантов достижения результата - это создание дополнительного уровня представления данных и выборку делать уже с него. Т.е., проще говоря, табличку пересечений разделов с юзерами, с соответствующими счетчиками. Наполнять этот уровень можно либо по шедулеру (обсчитать распределение за один день/час/неделю подъемно и возможно), либо триггерами по факту поста (просто инкрементируется соответствующий счетчик). Тогда выборки такого плана делаются "влет", ибо все данные уже посчитаны и лежат на своих местах. Главное обеспечить целостность данных, чтобы посчитаные счетчики совпадали с реальным положением дел (а возможно как раз это и не нужно, чтобы статистику сохранять, а древние невостребованные посты грохать).

Еще могу идею подкинуть, считать не только посты юзеров, но и читающие их запросы. И тоже можно составить соответствующую статистику по чтению. И это тоже для чего-то и кого-то будет полезно/интересно.

iLLer:Если достижение такой цели действительно необходимо

Совершенно не нужно. Если внимательно посмотреть, я говорил о другом сложном вычислении. Распределении постов во времени. Даже не сложности, а объемности вычислений. Такой запрос займет около 5 минут (по прикидкам). т.к. нужно обрабатывать всю базу пользователей помноженную на всю базу сообщений, чтобы выявить целевую группу уже для расчета распределения постов. А посчитать распределение это секундное дело, которое оптимизации не требует.

Но даже описанная выше проблема не существенна, ибо это чистой воды секундная развлекаловка, которую я набросал на коленке за 3 минуты... И это удивительно, что она вызвала такой резонанс :-D

Vishenk@:еще раз... внимательно:
статистика распределения сообщений за 2008 год
а активность обобщающая )))
ты логику видишь? и я нет ))))
но она там есть!

уловил лишь одну логику, я теперь понял почему ВВП второй срок был есть и буит. :rotfl:

да и Медведев туда же :rotfl:

созрела новая номинация "пыжесчет" или "матиматиг" или "пыжетолог"

лан, развлекайтесь, я пошел...... :flash:

Nord:Совершенно не нужно. Если внимательно посмотреть, я говорил о другом сложном вычислении. Распределении постов во времени. Даже не сложности, а объемности вычислений. Такой запрос займет около 5 минут (по прикидкам). т.к. нужно обрабатывать всю базу пользователей помноженную на всю базу сообщений, чтобы выявить целевую группу уже для расчета распределения постов. А посчитать распределение это секундное дело, которое оптимизации не требует.

Ну "время" тоже можно добавить как дополнительное измерение в этот срез. Хотя да, объемы не такие уж большие, общее кол-во постов меньше лимона. В любом случае, разработчику всегда виднее. Затухаю.

А как насчет номинации "читатель года"?)))

Ой,судя по табличке Куль в золотой серединке,хоть и не зависает на форуме уже второй год :rotfl:

Вот что значит заранее натрепать на год вперед. :rotfl:

iLLer:Ну "время" тоже можно добавить как дополнительное измерение в этот срез.

Это можно сделать, если меня в будущем будет интересовать только один единственный отрезок. А что делать, если я хочу делать быстрые выборки из базы за произвольный период "на лету". Если есть идея как оптимизировать такие запросы, я с удовольствием просвещусь :-D

iLLer:А как насчет номинации "читатель года"?)))

Идея хорошая. С точки зрения статистики. Я точно могу посмотреть у кого больше пропорция просмотров к постам. Другое дело, что это факт, и голосовать тут не о чем :-)

Nord:Это можно сделать, если меня в будущем будет интересовать только один единственный отрезок. А что делать, если я хочу делать быстрые выборки из базы за произвольный период "на лету". Если есть идея как оптимизировать такие запросы, я с удовольствием просвещусь

Не совсем так. Чтобы было за произвольный период, грубо говоря, нужно включить идентификатор времени в первичный ключ таблицы счетчиков. Этим идентификатором может выступать любой отрезок времени, все зависит от необходимой наименьшей дискретности будущих выборок. Например один день. Вряд ли понадобиться делать грандиозную выборку с 18-го января 14 часов 20 минут по 24 декабря 19 часов 12 минут?! Я использую в определенных случаях день, в статистическом срезе следующего уровня - месяц. Главное, добиться, чтобы объем таблицы счетчиков был достаточно небольшим для скорой выборки по нему. (у меня правда вот этот срез уже имеет порядка 700 тыщ записей, но и исходных данных у меня раз в 100 поболее). Но с нормальными индексами все просто летает.

Аттрибуты в таблице счетчиков: Юзер, Раздел, ИдентификаторВремени, значение счетчика. Первые три аттрибута - ПК. При инициализации данной таблицы, придется один раз выполнить запрос по БД с заносом результата с эту таблицу. При добавлении поста необходимо найти все идентификаторы времени в интервал которых попадает таймштамп поста, и инкрементировать значения соответствующих счетчиков. Идентификатор времени можно тупо заменить датой. Но дата - не очень хороший тип данных для хранения и индексирования, хотя, все зависит от СУБД, поэтому при гигантских объемах я его заменяю на 32-бит целое, которое имеет однозначное соответствие дате - так хранится компактнее и СУБД не "тупит" при построении планов запросов.

При такой схеме, при желании выбрать в диапазоне дат с 18-го января по 24 декабря, делается агрегация записей по индексу в этой таблице со сверткой по юзерам и разделам. Вот этот запрос и будет как раз летать по сравнению с запросом в лоб. Ну а для вывода полученного результата использовать клиентский кросс-табл. Тут уже все от инструментария зависит. Можно и в экселе повернуть.

Вот вы сейчас вапще о чём???
Зафлудили всю тему панимаиш!

Васе не понимаю зачем этот счетчик сообщений нужен :shock:

стоит же дата, когда зареген товарищч и хва -)

Ekaterinka::shock:

Это явно не для блондинок-гуманитариев

Ничего не понял, но по ходу усредненный показатель.
Андрюх я правильно понимаю?

AVES-CLUB

Информирование пользователей форума?

softic

ЗлыденЬ

MasteR

Архангел

ЗлыденЬ

iLLer

Dimik

Nord

pioner

iLLer

Куль

Nord

iLLer

ЗлыденЬ

svetik

NeSchi

Кто сейчас на конференции