Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I need to build a website where users can upload their photos, and vote other people photo, like Facebook like
i was thinking the best ( or only way ) to store this info:
1 - i can just use a simple counter on photo records, and check in session if people would vote more than once ( vote are just for fun ) but on a new session i can vote the same photo again
2 - the other way is create a table where i store userid and photoid, this way user can't vote more than once, but i'm not sure if database grow could became an issue since table will grow larger and larger
3 - A text field on user record where i store a list of photo id, and i can build a session array on login or just build a PHP array on page load. This could be the best way, i guess i can have issue if i need to search or count on specific situations. LONGTEXT should contain 4Gb so i think i would never reach maximum lenght
I'm assuming your question is:"What is the best way?" I would say 2 would be the best since that's the easiest to check wether a person has voted yet. The table won't get too big. People are using tables also for registering users and those can be alot as well.
yes you can move forward with the idea of text field on user record to store comma or pipe separated photo id
or text field on the photo record to store comma or pipe separated user id who liked that photo.
Its much better than creating a relational table
Here what you are trying to do is trying to create a website like Mark Zuck created earlier (Facemash). http://www.facemash.com.au/
You can download this script from http://webtify.com/internet/facemash-clone-script/802/
Regarding your logic : I think that #3 is good for this script
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
hi im thinking about user activity in laravel application ..
and i thought is it better to keep user activity in saparated log file than keep it in database ..
like create folder in storage folder for every user ..
and create log file with date like this ..
user_id_YYY-mm-dd.log
is that better thank keep logs in database
Logs on Laravel works really well to debug, but to get an history from user activity save data in database always is the best option.
You can create a log table and indexing with user_id and create reports from user activity.
querying by date, action or any other field.
Definitely store it in the database.
If you're looking to log activity, you'll end up with a large number of records and want these indexed. A few users using a piece of software for a few months can quickly generate thousands of records, depending on how detailed your tracking is.
Storing activity logs in text files will be okay in the beginning, but as soon as you want to find all actions of type X by user Y, you'll be spending hours searching through text files (or writing scripts to do it for you).
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I am making a small side project on which guests can vote on some sort of posts with either agree or disagree, then I want to save the IP that voted in the database. I was thinking of saving an array of IP's that voted in the 'posts' table, however that might be insufficient I guess. Would a separate table like the following be recommended?;
post_votes:
post_id, IP
Doesn't matter if the user voted agree or not, as long as the vote is counted they won't be able to vote again. What's the best approach for this? Thanks in advance.
Yes, the best way is to use a seperate table with identifiers (e.g. post_id) to identify the posts.
Never save more than one information per field - saving the information in an array in the same table is cruel.
However, do NOT store the IP address 'as is' in the database as this is illegal in many countries and can cause a lot of trouble!
Instead use a hashing function like hash_hmac (http://php.net/manual/de/function.hash-hmac.php), hash the IP address and save the hash instead..
Because hashes are one-way functions, this will ensure anonymity for the user but still give you the opportunity to prevent users from voting several times.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I am creating a website where users can easily calculate the calories they eat and see the repartition in term of fat, carbo, etc.
I want the users to be able to retrieve data from previous days.
I then need to store the data sent by my users everyday (basically, they input how much of each food they have eaten everyday and I am making the calculation then store the results).
The question if the following: what would be the best way to store the data? I have to store the data for each user for each day. I can't think of a simple solution (I think creating a new table for each new day would not be great, would it?).
I'm using PHP and MySQL for now.
Thanks for the help!
It seems that you are a step ahead of your self with the daily breakdown question.
First, you need to decide what you need to store, e.g. fields and normalise the way they are stored.
For example, you would have the following tables:
Users:
Id
..
EatItems:
UserId
ProductId
Calories
Fat
DateTime
Once you have these tables up and running, you can build reporting layer on top of that to breakdown consumption by user / date or anything else you might be interested in.
You could have a table that holds the input/calculated data/date which relates to a user/account.
When the user views previous day's, select the data that relates to that user.
I wouldn't create a table for each day. One table would suffice.
However, I would suggest attempting something and posting the code for specific issues you have if you run into before posting here.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I'm working on a link shortener project in php, and I would like to be able to record unique stats for every link by storing the visiter's IP. This I figure can be accomplished easily using a MYSQL database to store an ips for a single link, however over hundreds or possibliy thousands of links I will end up with a huge number of tables in my database.
Would it be more efficient or, better practice, to create a text file for each link and just store each unique hashed IP in that file?
Thanks for your time!
You can do it with 2 DB tables, as follow:
Table 'link'
- id (AUTO INC)
- link (STRING)
Table 'visit'
- id (AUTO INC)
- link_id (FK)
- ip (STRING)
- count (INT)
If a user comes back twice to the same page, you can use a ON DUPLICATE KEY UPDATE type of query to increment the count instead of setting it to 1.
If you're just logging information then writing to file will be quicker. Writing to the database still has to write but you are also running the database engine.
If you want to audit the data outside of scrolling the file, then MySQL would be a better route.
You don't need a huge number of tables. You only need 2 tables. One will store the list of links, and then another table with a foreign key from the links table and the other data you want to capture.
In the long run using a database will be much better as it organizes the data and lets you query it. Otherwise you may have the data in your logs but you won't be able to do anything with that data...
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
Wish you a peaceful and healthy new year. **
I am working on a survey database design for mysql/php/wordpress for estimated 10,000,000 users. Each user will eventually answer about 5,000 questions over a course of several years. These questions are answered mainly as scale of : AGREE, NEUTRAL, DISAGREE, DONT KNOW as multiple choice answers. There is no right or wrong answer. A user would be able to attempt the questions again in the future. Also, at each attempt his/her answer_record gets updated with new data. Would the following database design be reasonable from database performance and data normalization perspective? Thank you in advance.
TABLE_USER:
user_id
username
user_email
[other user specific fields]
TABLE_QUESTION:
question_id
question_text
question_image
question_category1 [A question may exist in more than 1 category]
question_category2
question_category3
TABLE_ANSWER:
answer_id
user_id
question_id
answer_agree
answer_neutral
answer_disagree
answer_dontknow
answered_datetime
answer_number_of_attempts
Sincerely,
Harrison.
Part of proper db design means stepping back and making sure that if you added one more thing, you wouldn't have to redesign the tables, and also that discrete types of information are separated out. If several columns are doing the same thing (but recording different answers) you should split them out into another table and have a single link table.
Also, do you really need to say Table in the table name? of course it's a table, what else would it be?
TABLE_USER is fine
for TABLE_QUESTION you should drop the category columns, instead make a new table
TABLE_CATEGORIES
with information on the different categories
and have another table
CATEGORIES_PER_QUESTION
question_id
category_id
that allows a question to have any number of categories, you can look which ones each question has by querying categories_per_question
TABLE_ANSWER should be split into two tables,
RESPONSE
response_id
user_id
question_id
answer_id
datetime_responded
and ANSWERS
answer_id
answer_name
Where answer name is AGREE, NEUTRAL, DISAGREE, DONT KNOW or any other sort of answer you might provide.
If you wanted to be fancy, you could even have another join table between ANSWERS and TABLE_QUESTION, indicating what answers will be available per question.
To know the number of attempts, and other information I dropped, you can query the DB so it doesn't need a column for itself.
I realize you want help with DB design, but even if the design is perfect, this will fail to scale reasonable if your system is not planned properly for scaling (BIG).
A proper designed API can scale endlessly.
With those numbers it will be cheaper overtime to have this external and build an API for it so you can scale properly. Building something directly into WordPress will require you to scale to quickly in all directions just for running PHP, HTTP and MySQL.
If you build an API in between WordPress and your survey database you can then scale MySQL and build any number of systems in between, Memcache, search engines, etc...
This will give you better separation between your systems allowing for more efficient scaling.
Scaling each only when it needs it.
So I would plan your system/infrastructure at this point also.