Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 7 years ago.
Improve this question
I want to develop a currency system on a custom forum I've been working on, but I don't know the best approach.
Should I add a new "gold" field to my user table and increment with sql statements?
id, user, pass, created_at, gold
Logic: user creates new forum post; update user table: gold + 1
OR
Should I add a transactions table that logs everything and do a count where user = x?
id, user_id, amount
1 3 1 (new forum post)
2 3 1 (new forum post)
3 12 -5 (item purchase)
4 3 -1 (deleted post)
5 9 1 (new forum post)
OR is there an even better approach?
It highly depends on what you want to do with it and which way to program you prefer.
To approach it with some facts though:
I expect a forum to be fast. For that you should only use simple Select. Functions like SUM() take a bit more time to perform. In a small system that will most likely not be a problem, but mysql-db usually scale very bad, so you should keep that in mind from the beginning.
You definitely want a way to track transactions. Mostly to be able to check what is actually going on. Even if you make a great system to deal with your gold you still want to be track what happened from time to time. For that it's handier to store transactions.
Redundant data and transaction synchronization can be a problem. Every transaction system has the problem to keep everything synchronized. With MySQL that's not so difficult, as tables can be locked while you perform transactions. But redundant data is way more of a pain. You have to ensure that you change data everywhere at the same time before other actions can interfere.
On a basic system I would store the data in the user-table and keep all transactions as a log in another table. But never use that for an output to the user. For any further it depends on what your system needs.
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 5 years ago.
Improve this question
I am building a browser php game.
There will be resources like metal, wood, food etc. Players will be getting the resources all the time (gaining resources speed depending on buildings/mines/farms levels).
The number of resources is saved in database resources table.
Lets say now that someone will be getting 50 000 of metal hourly.
What is the best way to save these values to database or recalculate them?
It would be crazy to add these values to the resources table every second to keep it updated. How to do it best?
If you can afford a stateful design, I have found that it is usually best to keep and maintain them in session, and aggregate the changes and write them out to the database at set intervals (of say 10 minutes), or when the session ends.
High rates of update can kill database performance: this impact is multiplied when the table you're writing to has any significant indexing. Different databases can support different transaction rates, and if you have more than a couple users, once-per-second updates will just kill performance.
An alternative is to write out these updates to a local or temporary queue table, containing only an index on the autoincrement field, and to have a sweeper process blow through it periodically to add those updates to the eventual target table at low priority. This keeps the update overhead lower, and reduces contention to the critical table, but it also means that your application logic will have to read the database value, and add the "pending" changes, before it receives a usable value.
A last alternative that is kind of the midpoint of the two above ones is to use a queue for storing pending database changes, but it would make it more difficult to calculate point-in-time values when there are unwritten changes still in the queue.
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 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.
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 am new to making games, and I am writing one for fun using php and javascript. I am using MySQL to store all of the info of the users of the game. The game is kind of like managing a sports team. You have a few variables (cash, assets, players, staff, etc...) and you take on all the roles of a sports manager. I know it exists, this is just a personal challenge.
My question is, what is the best and most efficient way to get information from the database into the game?
1. Do I have to run an sql query on every page?
2. Do I have to update my database EVERY single time something is updated?
3. Is it possible to get all of the information from the database when the user logs in, let him/her play, then only update the database with the new information when the session is killed?
Sorry for the lack of code, just looking for a starting point because it would be helpful to me to know this before I start writing a lot of the game.
Thanks
No, you don't necessarily have to run a MySQL query on every page load. You could store the results of such queries in a cache system such as memcached, or keep necessary data in $_SESSION.
No, you can use similar workarounds as before, but if the user disconnects you may end up with unsaved changes.
Well, you could load the data relevant to the user and write your own session handler for saving the data when the session is destroyed, but although I haven't ever tried it I would say there's a very real risk of losing data if, for example, your server is restarted or PHP's garbage collector callback is not called for some reason.
Overall, I think you may perceive SQL queries as much heavier than they actually are. If your database structure and indexes are set up correctly, your queries and updates shouldn't take longer than about 0.01 seconds each to complete.