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.
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 6 years ago.
Improve this question
I have two tables in my db:
Marketers:
Id, Username, Password, Email
Stores:
Marketer Id, 1 Store, 2 Store, 3 Store, 4 Store, ...., 10 store
there is the names of 10 stores for every marketer in Stores table.
So there is a one to one relationship between these two tables. right?
I'm wondering if it would be better to just combine these two tables or not.
I wan't to send a lot of query for the second table (Stores tables). so I though this would be better if I separate these two cause I rarely need the information stored in 'Marketers table'.
From a good design perspective, you should keep these tables as separate.
for your current requirements,
if you do not need data from Marketers so often, why do you need to include that in Stores. you would just end up fetching extra data each time.
say if tomorrow if some new info and the mapping changes to one to many or vice versa, your current design will work perfectly fine.
and of course from future maintainence view, it is easier to update current design.
although, i would also, suggest you to add an independent primary to Stores table also.
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'm writing a database that will match up care workers to clients. The carers visit the clients and assist them to get dressed etc. So the carer table holds there information such as what gender they are do they drive etc. If a client wants a female carer then I would check to see the gender of the relevant carer and all male carers would be excluded. I started down this route with my tables but soon discovered there was lots of combinations of questions and answers.
I don't know if this requires a many to many relationship but I'm a bit lossed off.
Any help would be gratefully received.
You should use a bridge entity to eliminate the many to many relationship between your Carer and Client tables. This Transaction table would also allow you to add additional transaction-based information to that entity such as Driver, etc... that wouldn't belong with either the Carer or Client.
Something like this:
Carer
Carer_ID PK
Name
Gender
Address
Vendor_ID FK -- Assuming your individual carers are part of a network
etc... Other Carer based details
Client
Client_ID PK
Name
Address
Gender
etc... other Client based details
Transaction
Transaction_ID PK
Client_ID FK
Carer_ID FK
DateTime
Location
Driver_ID FK -- Assuming you want to add a driver table
etc... Other transaction based details
As a follow-up... I personally disagree with those recommending the Entity-Attribute-Value design. EAV might be okay for basic look-up values in a front end application but basing your overall database design on it is a very bad idea (for integrity and maintenance reasons). It is much better to follow standard relational database normalization practices and create an entity table for each of your primary actors.
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 8 years ago.
Improve this question
I have a table that will hold 'game stats'. The name of the stats that are held are going to be changing depending on which sport the stats are for.
Is best practice to make two tables: one for the stats with columns such as 'Stat1, Stat2' etc. and another one holding the titles with the sportID as a key. Or would the best practise to have several tables for resorts for each sport. Or any other way?
Thanks,
I agree with andy. A generic-titled column like Stat1 - where the purpose is unspecified in the column name, is used polymorphically, or the column type must be made more generic - usually indicates a poor SQL/RA design.
Consider if this were encountered: create table people (field1 varchar(20), field2 varchar(20)). Yeah - not going to fly in my database. Give the columns (and tables) names that mean something in relation to purpose.
Instead, each different type of information collected should have it's own entity (read: table) or group of related entities. In this case I would imagine that each sport represents a different type of collected stats/information. (Even Win/Loss information can vary by sport.)
Trying to "label" columns based on an additional table is a half-way attempt of an Entity-Attribute-Value (EAV) model. While an EAV can be useful it comes with a lot of downsides in SQL and should not be used except after very careful consideration for a specific use-case. (I do not believe that EAV fits this scenario appropriately.)
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.