...
COUNT(DISTINCT l.log_date) AS numLogins,
MAX(l.log_date) AS lastLogin,
COUNT(DISTINCT CONCAT(v.user_id, v.frame_id)) AS numViewed,
COUNT(DISTINCT c.comment_id) AS numComments
...
Да / Нет
Мне нужно сделать страничку статистики: имя пользователей, кол-во просмотренных фоток, кол-во комментариев, кол-во визитов страницы, последний визит, одобренные фотки, неодобренные фотки. Я решил сделать это все одним запросом.
SELECT
u.user_id AS userId,
u.first_name AS first ,
u.last_name AS last,
u.login,
COUNT(DISTINCT l.log_date) AS numLogins,
MAX(l.log_date) AS lastLogin,
COUNT(DISTINCT CONCAT(v.user_id, v.frame_id)) AS numViewed,
COUNT(DISTINCT c.comment_id) AS numComments
FROM USERS AS u
LEFT JOIN LOGINS AS l ON
u.user_id = l.user_id
LEFT JOIN VIEWED_FRAMES AS v ON
u.user_id = v.user_id
LEFT JOIN COMMENTS AS c ON
u.user_id = c.user_id
WHERE
u.client = "MTV"
GROUP BY u.user_id
ORDER BY u.first_name, u.last_name
И я вот думаю, может разбить этот запрос и просто объеденить результирующие массивы? Но будет много беготни по ним.
SELECT
u.user_id AS userId,
u.first_name AS first ,
u.last_name AS last,
u.login,
COUNT(DISTINCT l.log_date) AS numLogins,
MAX(l.log_date) AS lastLogin,
COUNT(DISTINCT CONCAT(v.user_id, v.frame_id)) AS numViewed,
COUNT(DISTINCT c.comment_id) AS numComments
FROM USERS AS u
LEFT JOIN LOGINS AS l ON
u.user_id = l.user_id
LEFT JOIN VIEWED_FRAMES AS v ON
u.user_id = v.user_id
LEFT JOIN COMMENTS AS c ON
u.user_id = c.user_id
WHERE
u.client = "MTV"
GROUP BY u.user_id
ORDER BY u.first_name, u.last_name
И я вот думаю, может разбить этот запрос и просто объеденить результирующие массивы? Но будет много беготни по ним.
По своему опыту программирования подобных БД могу сказать тебе одно - через некоторое время твоя БД захлебнется просто в расчетах. Подсчет количества просмотренных фоток и другая статистика будут занимать столько времени что будет просто неприлично. Каков вывод? В корне неверно спроектирована БД. Сделать надо следующее:
1) В таблице с юзерами ввести поля статистики, счетчики, которые будут накручиваться при каждом действии. Например просмотрел фотку - накрутить счетчик просмотра фоток для данного юзера. Одобрил (не очень понял что это значит ну да ладно) - накрутили счетчик одобрилок для данного юзера
Уже эта мера даст тебе двукратное уменьшение этого страшного SQL-запроса и многократный прирост производительности
2) ОБЯЗАТЕЛЬНО расставить индексы по тем полям по которым чаще всего делаются выборки. В нашем случае это ID юзера ВО ВСЕХ ТАБЛИЦАХ
3) Я бы все же делал выборку списка одобренных фоток отдельными запросами. По скорости мне кажется будет тоже самое затраты на дополнительные запросы в случае разделения запросов нивелируются с лихвой тяжелой операцией JOIN в случае с одним запросом. Мне кажется что с несколькими работать удобнее чем с одним
ЗЫ Первый пункт КРАЙНЕ важен. Поверь моему опыту работы в игровых проектах - расчет статистики "на лету" там почти невозможен.
1) В таблице с юзерами ввести поля статистики, счетчики, которые будут накручиваться при каждом действии. Например просмотрел фотку - накрутить счетчик просмотра фоток для данного юзера. Одобрил (не очень понял что это значит ну да ладно) - накрутили счетчик одобрилок для данного юзера
Уже эта мера даст тебе двукратное уменьшение этого страшного SQL-запроса и многократный прирост производительности
2) ОБЯЗАТЕЛЬНО расставить индексы по тем полям по которым чаще всего делаются выборки. В нашем случае это ID юзера ВО ВСЕХ ТАБЛИЦАХ
3) Я бы все же делал выборку списка одобренных фоток отдельными запросами. По скорости мне кажется будет тоже самое затраты на дополнительные запросы в случае разделения запросов нивелируются с лихвой тяжелой операцией JOIN в случае с одним запросом. Мне кажется что с несколькими работать удобнее чем с одним
ЗЫ Первый пункт КРАЙНЕ важен. Поверь моему опыту работы в игровых проектах - расчет статистики "на лету" там почти невозможен.
[QUOTE=RussianSpy]По своему опыту программирования подобных БД могу сказать тебе одно - через некоторое время твоя БД захлебнется просто в расчетах. Подсчет количества просмотренных фоток и другая статистика будут занимать столько времени что будет просто неприлично. Каков вывод? В корне неверно спроектирована БД. Сделать надо следующее:
1) В таблице с юзерами ввести поля статистики, счетчики, которые будут накручиваться при каждом действии. Например просмотрел фотку - накрутить счетчик просмотра фоток для данного юзера. Одобрил (не очень понял что это значит ну да ладно) - накрутили счетчик одобрилок для данного юзера
Уже эта мера даст тебе двукратное уменьшение этого страшного SQL-запроса и многократный прирост производительности
2) ОБЯЗАТЕЛЬНО расставить индексы по тем полям по которым чаще всего делаются выборки. В нашем случае это ID юзера ВО ВСЕХ ТАБЛИЦАХ
3) Я бы все же делал выборку списка одобренных фоток отдельными запросами. По скорости мне кажется будет тоже самое затраты на дополнительные запросы в случае разделения запросов нивелируются с лихвой тяжелой операцией JOIN в случае с одним запросом. Мне кажется что с несколькими работать удобнее чем с одним
ЗЫ Первый пункт КРАЙНЕ важен. Поверь моему опыту работы в игровых проектах - расчет статистики "на лету" там почти невозможен.[/QUOTE]
База данных спроектирована правильно. Индексы везде, где надо стоят.
Я не могу поставить в таблицу юзеров счетчики просмотров, потому что заказчику нужно конкретно знать, какие фотки просматривал пользователь. А также он хочет знать, когда именно заходил тот или иной пользователь, какую именно он одобрил фотку и т.д.
Я мотивировался тем, что это довольно таки грузящая для сервака статистика и для мускула выделяется больше памяти, чем скрипту. Поэтому, быстрее будет, если я повешу это на мускул, чем при каждей итерации бегать по 3-4 массивам и искать соответствующие поля.
А кстати, может можно как-то оптимизировать запрос?
1) В таблице с юзерами ввести поля статистики, счетчики, которые будут накручиваться при каждом действии. Например просмотрел фотку - накрутить счетчик просмотра фоток для данного юзера. Одобрил (не очень понял что это значит ну да ладно) - накрутили счетчик одобрилок для данного юзера
Уже эта мера даст тебе двукратное уменьшение этого страшного SQL-запроса и многократный прирост производительности
2) ОБЯЗАТЕЛЬНО расставить индексы по тем полям по которым чаще всего делаются выборки. В нашем случае это ID юзера ВО ВСЕХ ТАБЛИЦАХ
3) Я бы все же делал выборку списка одобренных фоток отдельными запросами. По скорости мне кажется будет тоже самое затраты на дополнительные запросы в случае разделения запросов нивелируются с лихвой тяжелой операцией JOIN в случае с одним запросом. Мне кажется что с несколькими работать удобнее чем с одним
ЗЫ Первый пункт КРАЙНЕ важен. Поверь моему опыту работы в игровых проектах - расчет статистики "на лету" там почти невозможен.[/QUOTE]
База данных спроектирована правильно. Индексы везде, где надо стоят.
Я не могу поставить в таблицу юзеров счетчики просмотров, потому что заказчику нужно конкретно знать, какие фотки просматривал пользователь. А также он хочет знать, когда именно заходил тот или иной пользователь, какую именно он одобрил фотку и т.д.
Я мотивировался тем, что это довольно таки грузящая для сервака статистика и для мускула выделяется больше памяти, чем скрипту. Поэтому, быстрее будет, если я повешу это на мускул, чем при каждей итерации бегать по 3-4 массивам и искать соответствующие поля.
А кстати, может можно как-то оптимизировать запрос?
[QUOTE=Новая папка]
Я не могу поставить в таблицу юзеров счетчики просмотров, потому что заказчику нужно конкретно знать, какие фотки просматривал пользователь. А также он хочет знать, когда именно заходил тот или иной пользователь, какую именно он одобрил фотку и т.д.
[/QUOTE]
А я разве сказал "убей таблицы с логами и оставь только счетчики"? Я сказал ДОБАВИТЬ поля-счетчики чтобы в запросах не надо было делать как у тебя с джойнами и каунтами вот тут:
При такой кривой проектировке тут нечего оптимизировать. Со временем все будет только больше тормозить
ЗЫ Особенно если учесть что это "недоБД" MySQL
Я не могу поставить в таблицу юзеров счетчики просмотров, потому что заказчику нужно конкретно знать, какие фотки просматривал пользователь. А также он хочет знать, когда именно заходил тот или иной пользователь, какую именно он одобрил фотку и т.д.
[/QUOTE]
А я разве сказал "убей таблицы с логами и оставь только счетчики"? Я сказал ДОБАВИТЬ поля-счетчики чтобы в запросах не надо было делать как у тебя с джойнами и каунтами вот тут:
Код:
При такой кривой проектировке тут нечего оптимизировать. Со временем все будет только больше тормозить
ЗЫ Особенно если учесть что это "недоБД" MySQL
обычная проектировка, просто статистика сложная
[QUOTE=Новая папка]обычная проектировка, просто статистика сложная[/QUOTE]
Это простая статистика, друг мой. Очень-очень простая. Когда-нибудь ты столкнешься с финансовыми системами и вот тогда поймешь что такое сложная статистика.
Короче. Мой итоговый ответ на твой изначальный вопрос таков: при такой структуре БД оптимизировать запрос нельзя. С накоплением информации в таблице БД начнет тормозить и вот тогда у тебя будут уже большие проблемы поскольку исправить ситуацию, когда в БД сидит несколько миллионов записей гораздо тяжелее, чем на этапе проектировки и написания софта. Советы по оптимизации структуры я тебе написал. Уверен, что все опытные люди которые тебе ответят со мной согласятся (их тут немного но их все знают).
Если ты не согласен со мной - дело твое. Не моя система, не мне ее писать и тем более не мне использовать. Удачи!
Это простая статистика, друг мой. Очень-очень простая. Когда-нибудь ты столкнешься с финансовыми системами и вот тогда поймешь что такое сложная статистика.
Короче. Мой итоговый ответ на твой изначальный вопрос таков: при такой структуре БД оптимизировать запрос нельзя. С накоплением информации в таблице БД начнет тормозить и вот тогда у тебя будут уже большие проблемы поскольку исправить ситуацию, когда в БД сидит несколько миллионов записей гораздо тяжелее, чем на этапе проектировки и написания софта. Советы по оптимизации структуры я тебе написал. Уверен, что все опытные люди которые тебе ответят со мной согласятся (их тут немного но их все знают).
Если ты не согласен со мной - дело твое. Не моя система, не мне ее писать и тем более не мне использовать. Удачи!
[QUOTE=RussianSpy]Это простая статистика, друг мой. Очень-очень простая. Когда-нибудь ты столкнешься с финансовыми системами и вот тогда поймешь что такое сложная статистика.
Короче. Мой итоговый ответ на твой изначальный вопрос таков: при такой структуре БД оптимизировать запрос нельзя. С накоплением информации в таблице БД начнет тормозить и вот тогда у тебя будут уже большие проблемы поскольку исправить ситуацию, когда в БД сидит несколько миллионов записей гораздо тяжелее, чем на этапе проектировки и написания софта. Советы по оптимизации структуры я тебе написал. Уверен, что все опытные люди которые тебе ответят со мной согласятся (их тут немного но их все знают).
Если ты не согласен со мной - дело твое. Не моя система, не мне ее писать и тем более не мне использовать. Удачи![/QUOTE]
Я полностью согласен с тобой. Пасиб тебе за ответы. Статистика не сложная, я неправильно выразился.
Просто фоток в бд будет не больше 2000. Поэтому база данных не захлебнеться. Вот я и думаю, стоит ли делать такую надстройку для такого мизерного количества данных.
Короче. Мой итоговый ответ на твой изначальный вопрос таков: при такой структуре БД оптимизировать запрос нельзя. С накоплением информации в таблице БД начнет тормозить и вот тогда у тебя будут уже большие проблемы поскольку исправить ситуацию, когда в БД сидит несколько миллионов записей гораздо тяжелее, чем на этапе проектировки и написания софта. Советы по оптимизации структуры я тебе написал. Уверен, что все опытные люди которые тебе ответят со мной согласятся (их тут немного но их все знают).
Если ты не согласен со мной - дело твое. Не моя система, не мне ее писать и тем более не мне использовать. Удачи![/QUOTE]
Я полностью согласен с тобой. Пасиб тебе за ответы. Статистика не сложная, я неправильно выразился.
Просто фоток в бд будет не больше 2000. Поэтому база данных не захлебнеться. Вот я и думаю, стоит ли делать такую надстройку для такого мизерного количества данных.
[QUOTE=Новая папка]Я полностью согласен с тобой. Пасиб тебе за ответы. Статистика не сложная, я неправильно выразился.
Просто фоток в бд будет не больше 2000. Поэтому база данных не захлебнеться. Вот я и думаю, стоит ли делать такую надстройку для такого мизерного количества данных.[/QUOTE]
Ну фоток-то может быть и 2000 а вот их просмотров больше миллиона. Если платят за это мало - оставь все как есть. Когда начнет тормозить - будет повод еще раз снять денег с заказчика (главное грамотно обставить все):D
Просто фоток в бд будет не больше 2000. Поэтому база данных не захлебнеться. Вот я и думаю, стоит ли делать такую надстройку для такого мизерного количества данных.[/QUOTE]
Ну фоток-то может быть и 2000 а вот их просмотров больше миллиона. Если платят за это мало - оставь все как есть. Когда начнет тормозить - будет повод еще раз снять денег с заказчика (главное грамотно обставить все):D
[QUOTE=RussianSpy]Ну фоток-то может быть и 2000 а вот их просмотров больше миллиона. Если платят за это мало - оставь все как есть. Когда начнет тормозить - будет повод еще раз снять денег с заказчика (главное грамотно обставить все):D[/QUOTE]
Уже поздно %)
Уже поздно %)