开发者

PHP / MYSQL - how to structure a log database for 25,000 users

开发者 https://www.devze.com 2023-03-18 17:46 出处:网络
I\'m dealing with about 25,000 users (employees) spread over 5 divisions in a company. For all these users, there\'s an MS Excel sprea开发者_如何学运维dsheet in use at the moment. The spreadsheet cons

I'm dealing with about 25,000 users (employees) spread over 5 divisions in a company.

For all these users, there's an MS Excel sprea开发者_如何学运维dsheet in use at the moment. The spreadsheet consists of about 35 columns, logging the employees's daily activities.

Each row is 1 activity and there are on average about 3 activities per day (never ending, meaning the log just grows and grows).

MY QUESTION:

I would like to build a database (PHP/MYSQL) that holds the activity log for these users as opposed to the MS Excel files.

  1. Should I have a table per user with the 35 columns... leading to a database with 25,000 tables?

  2. Or should I store the activities to a 35-sized array, convert it to binary and store it in a blob and build such a table per year... leading to 1 table per year with 25,000 rows?


Employee
------------
employeeID
employee_name

Day
------------
dayID
day

Activity
-------------
activityID
activity_name
dayID
employeeID

This way you can see an activity for a day You can see activities for an employee Can see activity for an employee on a specific day


I would use a 35-column table, if you actually use many/most of those fields per activity.

CREATE TABLE users (
    uid    INT,
    name   VARCHAR(255),
    ...
);

CREATE TABLE activities (
    uid    INT, // references users.uid
    type   VARCHAR(32),
    date   DATE,
    ... // The 35 activity-related columns
);

And then I would partition on time. Perhaps per-year as you suggested (that would mean up to about 27.4 million rows per table), or per month (about 2.2 million rows per table) if search performance is important, and a per-year table is too big for good performance.


As a rule of thumb, you don't want to create a table for each user. You want to have 1 table, users, for that matter, where you'd store IDs, names etc that pertain only to a user model. Then have a separate table would document users' daily activities with a user_id column as a reference to the user's row in the users table.

0

精彩评论

暂无评论...
验证码 换一张
取 消