Как работает статистика?

Question

[JTester]

Как работает ежедневная, ежемесячная и общая статистика? Какой столбец должен быть главным в базе? Как её реализовать?

Comments

[Дмитрий Гординский]

Что такое "Главный столбец"?

Answer 1

[DevMan]

есть просто лог.
а статистика - выборка из этого лога, агрегированая по определённым критериям.
в вашем варианте - выборка за определенный период.

Comments

[JTester]

Да, вот там же должен быть какое-то главное поле, верно ведь?)

[DevMan]

JTester, так вы сами придумываете какое.
обычно, дефолтный примари - айдишник записи.
но вам никто не мешает создать композитный ключ.

[FanatPHP]

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

[DevMan]

FanatPHP, да фигли его знает. и знать не хочется.

Answer 2

[Константин Цветков]

Главным будет COUNT(*).

Например:

-- Исполнители:
  SELECT 1 AS [Line],
         'Исполнители: '
           + CAST((SELECT COUNT(*) FROM Performer) AS VARCHAR) + ' шт., '
           + ( SELECT CAST(COUNT(*) AS VARCHAR) + ' (' 
                      + CAST(SUM(DATALENGTH(Picture) / 1024) AS varchar) + 'KiB) изображений, ' 
                 FROM Performer WHERE (NOT (Picture IS NULL)))
           + ( SELECT CAST(COUNT(*) AS VARCHAR) + ' (' 
                      + CAST(SUM(DATALENGTH([Text]) / 1024) AS varchar) + 'KiB) статей;' 
                 FROM Performer WHERE (NOT ([Text] IS NULL)))
                  AS [Text]
  -- Альбомы:
  UNION
  SELECT 2,
         'Альбомы: '
           + CAST((SELECT COUNT(*) FROM Album) AS VARCHAR) + ' шт., '
           + ( SELECT CAST(COUNT(*) AS VARCHAR) + ' (' 
                      + CAST(SUM(DATALENGTH(Picture) / 1024) AS varchar) + 'KiB) обложек, ' 
                 FROM Album WHERE (NOT (Picture IS NULL)))
           + ( SELECT CAST(COUNT(*) AS VARCHAR) + ' (' 
                      + CAST(SUM(DATALENGTH([Notes]) / 1024) AS varchar) + 'KiB) статей;' 
                 FROM Album WHERE (NOT ([Notes] IS NULL)))
  -- Произведения:
  UNION
  SELECT 3,
         'Произведения: '
           + CAST((SELECT COUNT(*) FROM Track) AS VARCHAR) + ' шт., '
           + ( SELECT CAST(COUNT(*) AS VARCHAR) + ' (' 
                      + CAST(SUM(DATALENGTH(Lyrics) / 1024) AS varchar) + 'KiB) текстов песен, '
                 FROM Track WHERE (NOT (Lyrics IS NULL)))
           + ( SELECT DISTINCT CAST(COUNT(*) AS varchar) FROM Internet
                 WHERE (Kind = 'T') AND (URL LIKE '%youtube%')) + ' шт. видео;'
  --
  ORDER BY 1

Фильтры по периодам:

-- последний день
SELECT COUNT(*) FROM EncyclPage
  WHERE CAST(PublicationLast AS DATE) = CAST(GETDATE() AS DATE)
-- последние сутки
SELECT COUNT(*) FROM EncyclPage
  WHERE PublicationLast >= DATEADD(hh, -24, GETDATE())
-- последний календарный месяц
SELECT COUNT(*) FROM EncyclPage
  WHERE PublicationLast >= DATEADD(dd, 1, EOMONTH(GETDATE(), -1)) 
-- последний месяц
SELECT COUNT(*) FROM EncyclPage
  WHERE PublicationLast >= DATEADD( mm, -1, GETDATE())

Comments

[DevMan]

чойта каунт? а вдруг сум?
прост поворчал.

[Константин Цветков]

DevMan, В примере и количество, и сумма. Просто уточнил.

Answer 3

[Николай Савельев]

Какой столбец главным должен быть в базе? Как такую стату реализовать?))

В базе нет столбцов. В базе есть таблицы, процедуры, триггеры,... Это если мы говорим про реляционные БД, а не NoSql.
Столбцы есть в таблице базы данных.
А в таблице обычно главный столбец id.
При чём здесь статистика?

Comments

[JTester]

Боже, дигрод немочный (

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

[DevMan]

JTester, совсем нелогично.

[Kirgus]

JTester, кажется, у вас голова плоховато работает

Answer 4

[Myclass]

Я понимаю, что автор вопроса новичёк в этих темах, и думаю не получится -но попробую на двух словах обьяснить. Появилась свободная минута...

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

Очень часто показатели собираются снизу, т.е. с низшей ступени. И как в вашем случае - из логов.
Вот представьте себе каждый из ваших филиалов продаёт различные продукты. Т.е. по каждому продукту и дню, когда он был продан - можно отчитаться. Теперь представьте себе, это делают не только по дням, но и например недельные показатели продаж. Но именно по филиалам. Предстаьте себе центральную квартуру этой фирмы с различными филиалами. И из каждого из них текут сведения по продажам. Например месячные сведения. Т,е. в центральном оффисе никогда никто не сможет сказать, сколько было продано во всех филиалах вчера, позавчера итд. Потому что уровень аггрегации очень груб. Это точно также, как топором часы ремонтировать. И если возникает задача, более точные статистики в центре делать, значит уровень подачи данных будет не месячный, а каждодневный. Вроде-бы хорошо. Но за счёт того, что сведения идут каждый день, увиличивается обьём данных, которые надо постоянно суммировать в центре.

Плюс затраты по суммированию для всех филиалов в одном месте, что на какое-то время может делать или ваш excel или вашу базу вцентре на какое-то время недоступной, что увиличивает риск, что не все каждодневные данные вообще будут прочитаны и обрабтаны . своего рода замкнутый круг проблем.

Т.е. идногда делают компромисс. И оговаривают, где и на каком уровне делается своя статистика, которая потом стекается со всех филиалов и какая статистика делается там.

И чем ниже уровень, где создаются данные о продажах, использовании итд. , то тем больше данных надо обработать. Но ведь только своих. А потом в сжатом виде они передаются дальше по цепочке. Но всё равно например по каждому продуку. Там-же в свою очередь информации о конкретном продукте искуственно заменяется например на класс продукта. Для этого где записывается какому классу принадлежит каждый продукт. Т.е. общая статистика по 10000-и продуктам заменяется на 10-классов и именно эта статистика используется в эшелонах выше.

Рассчёт по филиалу:
Продаётся 1000 продуктов каждый день. Те. в центр отсылается 1000 записей каждый день. Много это или мало - все образно. Если эти продукты заменяются на классы, то каждый день будут посылаться например 10 цифр из каждого филиала. Что много меньше, но тогда никто в центре не будет знать, что лучшим продавцом сегодня был Петя Васечкин. Потому что нет у них этой информации. И для глобальных решений эта информации и не нужна.

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

А если честно - в вашем вопросе не хватает конктретных информаций. Поэтому и ответы будут так себе. Подумайте и поделитесть с ними. И кто занет, может быть вам помогут.