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.
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 3 years ago.
Improve this question
I have multiple products/environment, like Google has drive, docs etc.
One common Auth server is there which will contain users table.
But I have roles table related to each product, which contains roles for user for respective product.
Now how to manage this roles table?
I have following ways to do this, which one is better and why?
Create common table roles in main schema, and have product ID to link the records in table.
Have different table in same schema with prefix product_name. Eg. prod1_roles, prod2_roles.
Have different schema in same database, for Eg. product1 schema contains product1 roles table and so on.
Which of the above approach should I go with? Creating different database for 1 table is not feasible for me. So I want to go with any one of above or any other better approach will be appreciated.
If all your tables could have the same columns, is better to have just one, in a central schema, using an product_id. You will use the same pattern for login all your users at different products. This make your security layer easyer to control. And this is an important feature.
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 currently trying to build a football database in MySQL. It should store the fixtures from different leagues, plus their results, odds and some other information.
Is the scheme I just created correct or are there any mistakes in it? If so, what can I improve? I'm also not really sure about the link between tblMatch and tblTeams.
Afterwards I want to be able to make a Query where I can select a fixture including the points the home and away team got before the match, plus the average amount of goals of the teams. Like the new fields: 'homeTeamPoints', 'awayTeamPoints' ect.
So my question is: Where should I put these fields? In an extra table or should I put those in the table: 'tblMatch' and store the precalculated values there?
I hope you get what I tried to explain.
Best Regards
-bababow
A few notes:
You will want to replace "homeTeam" and "awayTeam" with "homeTeamID" and "awayTeamId" which will be foreign keys to the tblTeams table. This will enforce that the teams in the match both actually exist.
Remove the matchID and competitionID from the teams. I'm assuming teams can participate in many matches and competitions and therefore this structure will not support that.
What do you want to know about competitions? Is this a tournament? You may want to have a "bracket" and/or "tournament winner" column in there to store the results of the overall tournament.
Those are my main thoughts, other than that it looks OK.
In my perspective if the values of both the fields needs update regularly and table tblMatch data size is large then you should take it into separate table. if both the fields are updates whenever whole record is change then it could be in tblMatch table.
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
How to build a nice schema for activities in a database?
One activity can relate to one of 50 different entities.
For now i see only 3 solutions:
Table "activity" contains 50 columns with foreignkeys to the other entities.
This results in a very big table, which i do not like.
Each entity has its own "activity"-Table.
This solution results in nearly doubling the tables in my database, but its clearer. Still not the best solution.
Dirty one: "activity"-table contains one "entityType"-column with the entity-table-name and a other "entityId"-columns with the id to the entity.
But this solution break all foreign-keys and allows to store crap data in my activity table.
Perhaps somebody of you build a CRM and had to face with the same problem.
Does anyone have a better and clean solution?
Like i see, there is only a decission to make. First and second possibility are good because the keep the consistency of the db. In my case i decided to use 1. possibility.
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.)