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...
Related
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 7 years ago.
Improve this question
I'm trying to create a web chat app using AJAX, PHP and mySQL. I'm having trouble with the database structure.. Here's what I've thought :
A users table: Contains basic user's info
A Chat table: Contains basic columns like 'to', 'from' 'timestamp' etc..
The problem:
I think that this will get pretty messy very quickly since lots of users will be querying the same table. Not to mention some security issues. I want to create a separate table for each conversation. Is this a good idea? What would be your preferred structure?
Separate table for each conversation would be very messy indeed. A single table would get huge and degrade performance with sufficient volume and accumulation.
If you don't need to store each line of conversation in perpetuity in the database, you can simply purge the conversation from the chat lines table once it's over. You'd only need to keep it there if you wanted to search lines in past conversations. (Use other approaches for keeping chat statistics etc.)
You could archive a concatenated/serialized version of the conversation, ie. the whole lot in one chunk, into a file in the filesystem, or into a separate table with the relevant metadata (users, length, duration etc.). Then simply reload it, whenever an old conversation becomes active again.
If you do want to distribute your per-table load, you could e.g. track typical user connections and then generate an adequate amount of group-dedicated tables, or use any other user aggregation algorithm that works. But if you do purge the chat lines table periodically, it'll take a huge volume of usage before database performance will become an issue.
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 8 years ago.
Improve this question
I have a site where someone posts data to a mysql table , then the data is displayed to the public on a secondary page.
What I need is each time someone submits data to mysql table, I want the user to receive a unique ID, and the table row to be linked to the user specifically.
Reason why: Eventually, I intend to have users be able to delete/update their own submissions that are shown publicly. They should be able to only delete their OWN info if they have the same ID as the info in the mysql table.
Task:
Please let me know if this flow of thought is correct, and how to start assigning ID's to users, and to the table row itself.
Thanks!
The normal procedure is simple: When creating a new user, use the ID that results from your INT AUTO_INCREMENT column by checking LAST_INSERT_ID().
If you want, push this value into the $_SESSION to persist it for subsequent requests.
You can use the session_id() to create a special identificator for a user.
There are numerious ways:
IP
set cookie on client-side in order to reuse it
Tadman is right http://dev.mysql.com/doc/refman/5.0/en/mysql-insert-id.html
This is a Session Based way to get the value of an autoincremented field, after insert...
So whatever the user does as long as you insert und get insert id on the same session you are safe :-)
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 6 years ago.
Improve this question
I am new to PHP and have learnt it through online tutorials. I am am developing my own business website. I am looking for some guidance related to making dynamic web pages. It's something like, if Db contents are like Continent>North America>USA>States>Area>City and other geography. My question is, do I have to create different tables for each content or can it be in single Table? Moreover auto generate customer id/property id is that the same what we chose in table rows. I am sorry for my stupid question.
My confusion is that if someone searches for example USA, it gonna appear as many timesas in columns where I had to use it for subordinate area or cities.
Each table is a set of several peices of information. For each peice of information, you create a new row inside that table. You do not need a seperate table for each peice of information, however if you need a different layout for this information, you then create a new table.
I hope this helps :)
EDIT As requested by your comment, one thing you could do would be have a column named 'region' or something in the table, and in there you could insert information such as GB>SCO
I would create one table for customers with autoincrementing id, and another table for purchases where each new purchase gets the customers id. like purchases.customerId
Then you can create a view where you link customers.id and purchases.customerId For example.
If you want a very nice youtube tutorial series about mysql, u really should look at this http://thenewboston.org/list.php?cat=49
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