For my project, a web application, I need to store user data in a database. Obviously all users are stored together with their unique ID, but what about “items” users create within the application?
After a user is logged in they can create “items” within the application, whatever an item may be. Each item has a bunch of properties created by the user. I could create a table named “user_items” with an item ID and the user ID of the user who created it. But what if the app has 1000 users that all created 50 items with at least 10 properties? That would create 50000 records with 10 columns. So I start to wonder…
Does this ever create loading issues (slow down the processes) on the average server?
What are normal amounts of data to store in a database?
Answers:
Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.
Method 1
Very high level:
- a modern RDBMS, running on modern hardware, can handle tables with hundreds of millions of rows, and still return results quickly.
- but only if it’s well designed and can use indexes for your queries.
- some queries can’t use indexes, for instance wildcard searches on character fields (e.g.
where name like '%bob%') - the performance of your application will likely deteriorate with large numbers of concurrent users, and you need to make sure each page request doesn’t generate hundreds of database requests. If you have 1000 users all using the site at exactly the same time, and each request needs 100 database queries to render your page, your database may not have enough resources to process those queries simultaneously.
All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0