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?

  • How long do you have to keep these records? – JeffO Jan 13 '12 at 22:26
  • "very huge size". Define huge. How many posts? How many users read a given post? If you have 10,000 posts and each user reads 100 posts, you've only got 1,000,000 user-read-post association entries. Each entry is just two keys (at the minimum). It's not a very big table at all. – S.Lott Jan 14 '12 at 1:55

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.

|improve this answer|||||

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 https://dba.stackexchange.com/faq

|improve this answer|||||

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.