Home/ Questions/Q 7870993
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-03T01:46:45+00:00

I’m adding activity log to a busy website, which should show user the last

  • 0

I’m adding “activity log” to a busy website, which should show user the last N actions relevant to him and allow going to a dedicated page to view all the actions, search them etc.

The DB used is MySQL and I’m wondering how the log should be stored – I’ve started with a single Myisam table used for FULLTEXT searches, and to avoid extra select queries on every action: 1) an insert to that table happens 2) the APC cache for each is updated, so on the next page request mysql is not used. Cache has a log lifetime and if it’s missing, the first AJAX request from user creates it.

I’m caching 3 last events for each user, so when a new event happens, I grab the current cache, add the new event to the beginning and remove the oldest event, so there’s always 3 of those in the cache. Every page of the site has a small box displaying those.

Is this a proper setup? How would you recommend implementing this sort of feature?

The schema I have is:

CREATE DATABASE `audit`;

CREATE TABLE `event` (
`eventid` INT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY ,
`userid` INT UNSIGNED NOT NULL ,
`createdat` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ,
`message` VARCHAR( 255 ) NOT NULL ,
`comment` TEXT NOT NULL
) ENGINE = MYISAM CHARACTER SET utf8 COLLATE utf8_unicode_ci;

ALTER DATABASE `audit` DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci;

ALTER TABLE `audit`.`event` ADD FULLTEXT `search` (
    `message` ( 255 ) ,
    `comment` ( 255 )
);
Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Based on your schema, I’m guessing that (caching aside), you’ll be inserting many records per second, and running fairly infrequent queries along the lines of select * from event where user_id = ? order by created_date desc, probably with a paging strategy (thus requiring “limit x” at the end of the query to show the user their history.

    You probably also want to find all users affected by a particular type of event – though more likely in an off-line process (e.g. a nightly mail to all users who have updated their password”; that might require a query along the lines of select user_id from event where message like 'password_updated'.

    Are there likely to be many cases where you want to search the body text of the comment?

    You should definitely read the MySQL Manual on tuning for inserts; if you don’t need to search on freetext “comment”, I’d leave the index off; I’d also consider a regular index on the “message” table.

    It might also make sense to introduce the concept of “message_type” so you can introduce relational consistency (rather than relying on your code to correctly spell “password_updat3”). For instance, you might have an “event_type” table, with a foreign key relationship to your event table.

    As for caching – I’m guessing users would only visit their history page infrequently. Populating the cache when they visit the site, on the off-chance they might visit their history (if I’ve understood your design) immediately limits the scalability of your solution to how many history records you can fit into your cachce; as the history table will grow very quickly for your users, this could quickly become a significant factor.

    For data like this, which moves quickly and is rarely visited, caching may not be the right solution.

    • 0