Как оптимальнее хранить в БД timestamp для каждого действия?

Question

[Puristaako]

Немного упрощу, чтоб понятнее было.
Есть 2 кнопки А и В

Нужно хранить (в БД) время нажатия кнопок (до секунд) и какая кнопка была нажата, как это лучше сделать?
Если хранить в epoch все в одной строке (пример: "AD549795d1BD549795d3BD549795d6")то строка потенциально может вырасти до 15Кб (даже если в hex время переводить), запрашивать ее будут часто, 100-300 (в пике) пользователей, каждый раз в 10 секунд (540-1620 Мбайт/час).
Хранить время первого нажатия в другой строке БД, а потом в строку добавлять разницу?
Хранить в отдельной таблице по отдельности с TIMESTAMP к каждому нажатию?
Разумеется цель: меньше нагрузка на сервер, меньше траффик

ДОБАВЛЕНО:

Извиняюсь за неточный вопрос.
Операторов (которые нажимают кнопки) много. Вот аналогия наиболее подходящая:
Футбольный матч и оператор который ведет статистику (кто кому пас дал, удары в створ (кнопки-события) и т.п.) Операторов много, у каждого оператора много матчей, n к n. У одного матча только один оператор. 1 к 1. Хранить надо матч, событие и время этого события в матче.

p.s. Когда этим занимаешься постоянно все логично и просто, а когда через 7 лет после университета пытаешься что-то вспомнить в голове бардак. Особенно когда задав вопрос, люди перед тем как дать ответ сперва возвышают себя/принижают собеседника, а потом отвечают на вопрос. Возникают сомнения в профессионализме данных товарищей и к их ответам всегда относишься с подозрением. Я в жизни не встречал профессионалов которые бы в таком ключе отвечали на вопросы. Надеюсь никого не обидел.

Answer 1

[Puristaako]

Ответ полученный на англоязычном сервисе через 10 минут:

I suggest you create reference tables called

match match_id, name, venue A row for each distinct match
player player_id, name A row for each distinct player
action action_id, name This is a codelist 1=Ace 2=Fault, etc.
These tables will be relatively static.

Then, I suggest you create an event table containing the following items in the following order.

match_id
ts (TIMESTAMP)
action_id
player_id
You should include all four of these columns in a composite primary key, in the order I have shown them.

Every time your scorers record an action you'll insert a new row to this table.

When you want to display the actions for a particular match, you can do this:

SELECT event.ts,
action.name AS action,
player.name AS player
FROM event
JOIN player ON event.player_id = player.player_id
JOIN action ON event.action_id = action.action_id
WHERE event.match_id = <>
ORDER BY event.match_id, event.ts
Because of the order of columns in the composite primary key on the event table, this kind of query will be very efficient even when you're inserting lots of new rows to that table.

MySQL is made for this kind of application. Still, when your site begins to receive tons of user traffic, you probably should arrange to run these queries just once every few seconds, cache the results, and use the cached results to send information to your users.

If you want to retrieve the match IDs for all the matches presently active (that is, with an event within the last ten minutes) you can do this.

SELECT DISTINCT match.id, match.name, match.venue
FROM event
JOIN match on event.match_id = match.match_id
WHERE event.ts >= NOW() - INTERVAL 10 MINUTE
If you need to do this sort of query a lot, I suggest you create an extra index on (ts, match_id).

Ollie Jones

Comments

[Puristaako]

Человек даже запросы за меня написал, хотя я этого не просил. Прокомментировал все, очень информативно.

[FanatPHP]

То, как ты там задал свой вопрос, говорит нам, что ты так ничего и не понял. И "1A2014-11-28 09:01:21" - это рассматриваемый всерьёз формат хранения. Ты безнадёжен. Пусть даже 10 олли джонсов будут писать за тебя запросы - всё равно ничего путного у тебя не получится.

Answer 2

[FanatPHP]

Нужно хранить (в БД) время нажатия кнопок (до секунд) и какая кнопка была нажата, как это лучше сделать?

Таблица
кнопка | время нажатия
- это ЕДИСТВЕННЫЙ вариант, который должен приходить в голову автоматически.
Все остальные фантазии из вас надо выбивать калёным железом.
Сон разума рождает чудовищ, а фантазия похапешника, не отягощённая даже базовыми принципами программирования, рождает монстров.

Там, где человек даже с уровнем профильного колледжа (бывш. ПТУ) не задумывается ни на минуту, над проблемой уровня "сколько будет 2х2", доблестный воин while mysql_fetch_array начинает морщить лоб, загибать пальцы, изобретать себе вселенскую проблему. А потом и монстра для ее решения.

Разумеется, оправданием всех страданий является "меньше нагрузка на сервер, меньше траффик".
Заботу о серверах я бы вообще законодательно запретил в коде, по крайней в течение первых трех лет кодинга. ещё никогда эта забота не приносила ничего полезного, но вот всякий мусор - в неисчислимых количествах.

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

Идем в мануал и смотрим, сколько занимает какой тип:

• int - 4 bytes
• timestamp (mysql) - 4 bytes
• datetime - 8 bytes - больше чем инт, но все равно меньше, чем самопальное кодирование в хекс.

Comments

[Puristaako]

Приходит в голову автоматически, но... Уточнил в вопросе.

[FanatPHP]

Все равно храни как положено - ид матча, ид события, время события. 12 байт на запись. индекс на матч-событие. Когда такой объем станет велик - тогда и занимайся оптимизацией.

[Puristaako]

Когда станет велик будет поздно. :)

[Puristaako]

300 записей на матч, одновременно матчей идет 10-100 * (1..60 в день)

[Puristaako]

ну хотя не так много получается, смущает что в таблице будет миллион строк уже в первый день

[FanatPHP]

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

[Puristaako]

SELECT id_action, timestamp WHERE id_match = 643 из 300М строк по индексу таких запросов около 1000 в минуту
меня не пугает, меня интересует

[FanatPHP]

Почему-то не дописывается комментарий

Answer 3

[neochar]

Использовать google analytics и его API.

Answer 4

[LLWE_FUL]

Хранить строку с тайм-стемпом на каждое нажатие, запросы на сервер отправлять при нажатии сразу, время брать с сервера в базе данных (default CURRENT_TIMESTAMP), а не слать с клиента, у которого неизвестно как настроены часы.

Answer 5

[xmoonlight]

Зависит от задачи.
Можно хранить: старт+смещение1+смещение2+...+смещениеX
Можно хранить: count, среднее время и время последнего нажатия.
Можно хранить: в куках на стороне пользователя и передавать пачками.
есть еще варианты...
Опишите задачу подробнее..

Comments

[FanatPHP]

Особенно здесь доставляет таглайн под ником. Вот уж где бездна мудрости-то, ага.

Answer 6

[Евгений]

Если так парит нагрузка на бд, то юзайте redis.
Но хранить как писали выше нужно в формате юзер / кнопка / timestamp (int)