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 question about how big companies manage a database structure, let's say if i have an ecommerce app something like shopify which is the best approach you take:
a) When a new user creates an account a new database with his tables is created specifically for that user (i think if for some reason this database fail the other databases of other users remain working)?
b) When a new user creates an account Instead of create a new database, the app just create a new row in a table for his login and then all the products of all users are in the same table and only the user_id is the difference between one product of a store and another.
Thanks in advance.
Yeah, you should go for the second option (b), for alot of reasons:
1. Most of the data in your database shall be accessible for all users, so you don't want to have the same data stored in multiple places.
2. Sooner or later, you will come up with features where you want to share or link data between different users, etc.
3. Your first choice (a) would be extremely resource consuming compared to the second choice (b).
4. Well, the list can go on and on... :)
Obviously, the second choice - much more efficient and smarter.
Think about the number of the users, let's say 10k for example.
you realy don't want to handle this mass of tables!
I would go with Option B. This will reduce your work load and help in reporting needs down the road. Just make sure you use a robust database design to handle load when writing to database tables.
Related
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 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 1 year ago.
Improve this question
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?
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.
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 am still fairly new to creating rails apps from scratch and would like to know the best way to set them up for efficient queries.
Consider this scenario. You are building a social site that shares books using mysql2 for a database. You start with two models; a user and an author. Both need name attributes; first_name, middle_name, last_name etc.
Would it be more efficient to create a name model where name would be it's own individual table?
Or add name attributes to the individual user and author where the attributes remain as columns?
First, you might consider implementing this using PostgreSQL - there are many, but performance is one of the reasons.
More, you have to think the system you build should be maintainable. Having a separate table for the name can be a very bad idea. Do you plan to add names for all the models you have in that one name table? Sounds weird. What problem do you think you could solve by doing that?
Instead, I think indexes can help you out (https://tomafro.net/2009/08/using-indexes-in-rails-index-your-associations) when it comes to retrieving associations.
And I cannot give you more advices on your data model. This depends on the requirements and future intentions. Are you going to query per model and then retrieve associations? Is there going to be sort of a tagging approach to handle synonyms?
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 8 years ago.
Improve this question
I'm new to programming, and hope this question isn't too basic. I've searched the questions here but can't find anything exactly like it.
I'm making a website in which people have to complete a sign-in form and then answer a survey. The survey answers will drive how the site performs for each user (there will be different monthly reminders in email personalized to the survey responses). I have two MySQL databases, one for the sign-in and one for the survey.
How do I get the member ID in the member database to be the same as the survey ID in the survey database? Or am I thinking about this all wrong, and there's another solution?
I'm most familiar with PHP and JavaScript, so I hope that there will be a way to do this in the coding if not in the database design. Again, sorry if this is too basic and many thanks in advance for your help.
This is a terribly generic question to answer, but I hope I can help you a little along:
Now, assuming that you have a good reason for separating the user registration and the surveys in two different databases (you did not give a reason for it being so), after a successful user registration you can assume that the user is 'logged in'. This should mean that the ID of the registered user is available to you in code.
You do not have to have identical survey IDs and user IDs, it usually makes more sense to have a separate table knitting users and surveys together (with a user_id field and a survey_id field).
After setting up or saving the survey, store a record in this table, connecting the user with the survey.
If you were hoping for a more specific answer, I suggest you delve into a little more detail in your question.
Good luck!
Just some hints, they won't rock the house but probably good for a start:
Put the two tables in the same database. This is less a technical requirement, but it's easier for you. The two tables belong together, keep them in the same database.
It's okay to have two tables.
The member ID and the survey ID do not need to be the same. Instead add a memberID column to the survey table and set it to the appropriate ID of the member table.
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 have a table called enterprise in my database. If the enterprise expresses its demand to my company, the enterprise will become our prospection. And after, if the enterprise accept my company's proposal, we will sign the contract, and enterprise becomes out client.
Now, I have created 3 tables which are enterprise, prospection, client.
So, how should I design the database?
One approach would be to have a table Companies, and the three tables you already have. All three tables have field CompanyId that has a foreign key constratint linkining it to the companies table. This design has the advantage that you have to keep the company information in one place and there is no duplication.
Another way would be to have a field in the companies table, that marks them as an enterprise, prospect, or client.
Which design you should choose largely depends on information for the different classes. If you thinking along inheritance (i.e. a client is a prospect is a enterprise) than the company table suffices. However, if ther is a large amount of information and the information is different for each of the three classes than the first approach would be better.
You should, however, always try to keep the information in one place, i.e. in one field/table (= fully normalized). In some cases you can deviate from this principle for performance reasons, but keep in mind that this also means a higher maintenance overhead - you have to update n tables when a value changes.