It's not about security or something. There is a table to record user information, like username, password, postcode and so on, one record per person. There is also a table called post to record the posts the users posted. It's very easy to set a relation to identify the user who posted the post. But think of this situation, how to store the posts that has been read by a user? If use many-to-many relation, the table will increase to very huge size. What's more, there's a lot things to record, I just take one of them for example. I call this personal information. The problem is how should I store it properly?
- Anybody can ask a question
- Anybody can answer
- The best answers are voted up and rise to the top
to solve your read posts issue you should use a mapping table that links a post and a user, then insert a record for each post read by each user. Creating a mapping table is the basic strategy to resolve many to many relationship issues.
Databases can grow large, but if you design properly you can limit repeated data and use the smallest necessary data type to conserve disk space, also disk space is one of the cheapest parts of hosting a website so database getting large isn't a huge problem. You can also implement policies to help limit the size of your database, things like deleting a user after X months of no activity, or only storing history for the previous X months.
If you want to know how to design a table to properly store all this information you should read up on database normalization. If you are wondering how to store the information securely you should read up on encryption and hashing, and only stored hashed or encrypted values for sensitive information like a password.
The number of records will grow very large, but the amount of data per row will be very small. Each time an article is read a user_number reads an article_number at timex.
This table will allow you to know how many different people read the article, the number of reads per day, the number of articles read by the average user...
Don't store the user name, or the article title, or anything else. These names/title are not constant; so if the title is edited in the article table, there will be a mismatch with the data in the articles read table.
also checkout http://dba.stackexchange.com/faq