Question

I would like to store some analytics figures. For example, the amount of times a user performed action X or the amount of users that have logged in in the past day, etc.

Would the best practice for this be to add another table to my existing application database? Or to add a new database here? I’m thinking the second option would be a bit overkill.

Answer 1

It depends entirely on your business/security/public interest needs, use cases, and funding.

For example, if, by analytics, you mean “Working out how many anonymous people read this tiny public wiki”, then a table will probably be fine. If that wiki grows, then you might want a separate DB for performance reasons.

If, however, the analytics DB will include information about site members — especially information that does NOT need to be stored directly on the public website — then you have a legal responsibility to take all reasonable precautions to safeguard the data. That may mean storing it in a separate business-internal DB, rather than on your public-facing site DB.

At the very least, you should have separate DB connection settings, separate connections, and separate cursors for your analytics in the web app, so that it’s easy to split them off to a separate DB later. This is often done to separate reads and writes in webapps, so you should be able to find examples of it, if you’re stuck.

Past a certain small site load, you’re going to want it in a separate DB for performance, no matter what. Unless you’re using some kind of distributed, horizontally-scalable DB that’s built for performance anyway, that is.