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 4 years ago.
Improve this question
I wanna build a web app which will store a lot of data for each user, so I've got a question, which solution is better:
create a separate database for each user
create one big database and in every table add a column with user id
?another option?
Thanks!
There is no question that creating a "big" table with a column for the user id is the way to go. SQL is optimizes to handle data in tables, not to handle zillions of tables.
Here are some reasons why:
Performance. Having a separate table for each user means that you will have lots of empty space on data pages.
Combining data across all users. Having separate tables means that your queries will be really complicated.
Maintenance. Having separate tables means that adding indexes, new columns, and so on is a nightmare.
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'm building a website that contains articles, these articles won't be shown until the user is logged in, I'm planning to add two buttons, the first one is called "follow this article", the second is meant to make the article as a favourite. My question is how can I structure that in my database?
Should I just add a table that contains id_article, id_user, followed(1 or 0) and favourite (1 or 0), or is there another solution that would let me economize more memory space?
NOTE: My website will have lots of articles that will be visited by a lot of users.
Make two separate relations: articles_followed (id, id_article, id_user) and articles_favourite (id, id_article, id_user). This will give you enough flexibility in:
adding new attributes, specific for each relation,
sharding your database (at some point): it'd be easier to move one relation from another since they are not depending on each other,
concurrent update: you can use separate locks on these two, in addition, you'll have fewer issues with transaction visibility,
you don't need to keep is_followed or is_favourite flag: if there's an entry, then it means that article is followed (once unfollowed, simply remove the line)
Think about your domain classes structure -- which option would be more convenient to code? I bet, in case of two separate relations, it would be clearer.
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 need a web-service which allows admins to insert new data and viewers to see this data-tables. Therefore at first i need a database (Mysql ?). Is a mySql db on a server the right choice? Afterwards a website should be connected to this db, where users can see specific tables and admins can add new lines into this tables. Finally this tables should be able to only show the last xy-lines of the respective table.
Use-case: I have a restaurant, and when I get orders, i want to provide a simple table where the telephone-workers can add new orders (e.g. 3x pizza salami); afterwards this table is opened with view-rights on a display in the kitchen. So the chefs can create the orders.
Which database is the optimal here?
What kind of web-service is the right and how is this connected and set up?
You can use MySQL or SQL Server. And you can use Web Pages instead of web-service.
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 7 years ago.
Improve this question
I am having table with 9 columns and 400000 Records. I am using php and mysql for database. The problem I am facing is it takes quite a long time to fetch the particular data or search the records. So can anyone please suggest me should I use other database or some twicks to do in database and also sugegst me the best hosting to handle this large records in my site.
this much record is not considered as a large data. What you need to do is make sure you have proper indexing in your table columns and most important to load only those data which are required. i.e. Implement paging.
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
What is the mysql database best practices for multiple users?
When build a SAAS cloud projects are you best to have a new database for all users or put a users data in their own table or just put it all in the same database and use primary key to find a users data?
What are the pro's and con's?
I NEVER create per-used tables. If the logical meaning of the data is the same, then they should share a table. I also never allow automatic creation of tables - creation of tables is done by a DBA, by hand (sometimes by running a program or a script, but always initiated by a human being.
I also have a hard-and-fast rule to have static SQL (using bound parameters for values only). This lets me keep tight control of what is read from/written to the database, and where - very important to avoid SQL injection.