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.
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
The Problem
I have an app that scrapes data and presents it to the user, directly, because of lack of disk space.
This data is very volatile, it can change within minutes. Much like the stock market.
Since the data changes so often, and it varies from user to user, it is useless to save it in a database.
The question
I need to sort the data presented to the user, compare it, link it etc. A lot of functions that a database provides. Yet I cannot save it in said database because of the above conondrums, what should I do?
What I've Thought of Doing So Far
I've tried organizing the data presented to each user using just PHP but seems troublesome, fragile and inefficient.
Should I just create some sort of virtual table system in MySQL just for data handling? Maybe use a good database engine for that purpose?
Maybe I can save all data for each user but have a cron job remove the old data in the database in a constant fashion? Seems troublesome.
The Answer
I'd like some implementation ideas from folks who have encountered a similar problem. I do not care for "try all of the above and see what is faster" type of answers.
Thanks all for your help.
If the data is of the type you would store in a db and you would benefit from being able to query it in ways that are more difficult in PHP, but you just don't want to keep it, you can still use a database. You can create temporary tables, insert raw data, and query it to get what you want. When you close the db connection, the tables disappear. Even though the script names them the same, the database will actually create a unique set per connection so each user will have unique data. This solution may not perform as well as you need so do some testing to see if it's suitable for your situation.
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
So i have a website where users create their own 'shops' and then they can put items in the shops, so would it be practical to create a table for each user's shops or should I just add user IDs to posts?
You should add user ids to shops/posts. There are numerous reasons why you do not want to have separate tables for each user:
MySQL is designed to handle tables with lots of rows, not lots of tables with the same structure.
Structuring queries that goes across tables will require combining lots of different tables.
A small change to the data structure, such as adding a new column, becomes a nightmare.
Foreign key references to the shops becomes impossible.
If the data for a user doesn't fill a single data page, you end up wasting a lot of memory.
There are some reasons why splitting data into separate tables might be necessary. Here are some possible reasons:
Access is more easily managed at the table level than at the row level.
Replication of the data for each user might have different requirements.
An external entity requires that the data be in separate tables or databases.
However, the first set of reasons seems to weigh much more heavily to single table/entity structures. These more advanced concerns do not appear to be 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
While making a website like facebook
we can follow two approach of database design so please suggest better
Concern is Data Secuirty and Backup Management
Approach 1
Design a table that will hold all the data of the personal and some other table that will hold other keys like image etc
the problem will come when there are 10 lakhs of entries in the table is it possible thereafter to take backup
some hosting company wont allow to do so.
Approach 2
While the user signup assign the separate table to the users in that way user will reach to ten thousand rows in 5 years or so just a assumption
but that means million tables in the database if million user signup and that again a problem i believe
Please suggest better way if anyone can
Sites the size of Facebook have unique challenges specific to their setups. Facebook, Twitter, Google, etc. all maintain their own forks of database engines and often even write their own, and they'll be using different databases for different purposes. Very little of what they do is going to be applicable to anything you build.
Approach #1 is by far the better. With proper indexes and a good database design, MySQL can support billions of rows. It cannot as easily support millions of tables.
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 have a system where users can 'like' content. There will likely be many hundreds of these likes going on at once. I'd like it to be AJAX driven so you get an immediate response.
At the moment I have a mysql table of likes which contains the post_id and user_id and I have a 'cached' counter on the posts table with the total number of likes - simple so far.
Would I benefit in any way, from storing any of this information in mongodb to take the load off of mysql?
At the moment, I click like, and two mysql queries run - and INSERT into likes and an UPDATE on posts. If I'm in a large-scale environment in heavy read/write situation what would be the best way to go?
Thanks in advance :)
MySQL isn't a good option for something like this, as a large number of writes will cause scaling issues. I believe MongoDB's real advantage is schemaless JSON document oriented storage, and while it should perform better than MySQL (if set up correctly), I think you should look at using Redis to store counters like this (The single INC command to increase a number value is the cream on top of the cake). It can handle writes much more efficiently than any other database, as per my experience.
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.