A bit of a real rookie question, but I'm really struggling to wrap my head around the logic round this one.
What would be the best way to link tournament_ID and tournament_name without having to create another table (or should I create another table?)
Notice how there is an AI PRIMARY KEY for tournament_ID but does not match the tournament_name correctly.
EXAMPLE
table tournaments
Current setup is tournament_ID AI PRIMARY KEY. Thus How would I correctly link that to tournament_name
You should create a pivot table to store each teams participations and results.
In your current db design there is a possibility of data duplication.
My proposed db design would be
teams
tournaments
team_tournaments (id, team_id,tournament_id, dates, results)
And create a view for fetching a result through joins.
Related
Im here with a little problem with my inventory and I've been pondering with idea of this little schema here.
Is it possible or is there another way I can achieve this kind of schema below?
I can cheat my way through this problem by just having my application identify what itemID should be inserted into the tbl_stocks but I fear when the ID of either medicine or bandage is updated, that would leave an issue in my tbl_stocks.
Any suggestions on how to achieve my target?
Normally you have 2 entries in such a table that can became different shapes.
So add a reference for both tables to tbl_Stocks one column Medicine_ID VARCHAR(10) NULL and a Bandage_ID VARCHAR(10) NULL
So of curse you have a null column in this table for every entry, but later you can easy join this table.
If more and more tables come as expected you need a crosstable for each "Shape" .. One Medicine_ID x tbl_Stocks and one Bandage_ID x tbl_Stocks. This is fast and a good design, but also brings more maintenance effort.
I need tips when it comes to designing tables in a database. I am designing an employee meal system that monitors and processes meal logs of employees (like an attendance) My problem is here, I have 2 tables: The employee_table and the log_table. The employee table contains basic employee information and it has a unique key (not a primary one) which is employee_number. And then, there's another table, log_time, which contains the swipe data of the employees. Now, the two tables contain and employee_number column. How do I make relation out of them? Can I bind them together so that when I call for the employee_number column on the log_time it will get the basic information of the employee on the other table as well? Sorry because I'm having a hard time when it comes to designing a database.
SQL syntax for a relation might look something like this:
CREATE TABLE employee_table(
FOREIGN KEY (employee_number) REFERENCES employees(number),
...other stuff...
)
With another table that looks like
CREATE TABLE employees(
number INT(10) NOT NULL
)
Here's a great site on SQL foreign keys:
http://www.sitepoint.com/mysql-foreign-keys-quicker-database-development/
I am new to database designing. In my case I have to generate lot many keys per user per product. So, I have two options -
Create one table with product_id and key for all the users, or
Create a separate table for each user
In the former case I will have a single table but querying might take more time as all the entries are in the same table for all the users.
In the later case queries might return the result faster but more tables and if users cross 100 or more than it means lot of tables.
Definitely do not create a table for each user. if you create a single table for all users you can use relational database design and add specific information pertaining to each user like address or employee information and use the primary key from the users table as a foreign key. and there will not be any noticeable lag. And maintenance will be whole lot easier
if you want to build relation between your user and product then make table like below
user_product [table name]
id [Primary Key]
user_id [Reference key of user table]
product_id [Reference key of product table]
key
This is your table schema You must use.
if you generate each table then this will take more complex for database and relation management. So, just use above row base format.
if that helpful then let me know.
Thanks
Newish to mysql DBs here. I have a table of USERS and a table of TEAMS. A user can be on more then one team. What's the best way to store the relationship between a user and what teams he's on?
Lets say there are hundreds of teams, each team consists of about 20 users, and on average a user could be on about 10 teams, also note that users can change teams from time to time.
I can think of possibly adding a column to my TEAMS table which holds a list of user ids, but then i'd have to add a column to my USERS table which holds a list of team ids. Although this might be a solution it seems messy for updating membership. It seems like there might be a smarter way to handle this information... Like another table perhaps? Thoughts?
Thanks!
ps, whats the best field type for storing a list, and whats the best way to delimit?
whats the best field type for storing a list, and whats the best way to delimit?
It's usually a really bad idea to try to store multiple values in a single column. It's hell to process and you'll never get proper referential integrity.
What you're really looking for is a join table. For example:
CREATE TABLE user_teams (
user_id INT NOT NULL FOREIGN KEY REFERENCES users(id),
team_id INT NOT NULL FOREIGN KEY REFERENCES teams(id),
PRIMARY KEY (user_id, team_id)
);
so there can be any number of team_ids for one user and any number of user_ids for one team. (But the primary key ensures there aren't duplicate mappings of the same user-and-team.)
Then to select team details for a user you could say something like:
SELECT teams.*
FROM user_teams
JOIN teams ON teams.id= user_teams.team_id
WHERE user_teams.user_id= (...some id...);
I'm relatively new to PHP MySQL and have tasked myself on learning with the "hands on" approach. Luckily, I currently have a (very) large database all relating to coin data with one table to work with. It currently has the following columns (each row representing a single item [coin]):
Group
ItemNo
ListNo
TypeCode
DenomCode
PeriodCode
ActualDate
SortDate
CostPrice
SalePrice
Estimate
StockLevel
DateEntered
DateSold
Archived
ArchiveWhenSold
Highlight
KeepSold
OnLists
NotForSale
Proof
StockItem
OnWeb
Cats
Ref1
Ref2
Variety
Picture
Description
TypeName
TypeHeading
DenomName
DenomHeading
DenomValue
PeriodName
PeriodHeading
PeriodStartYear
PeriodEndYear
The groupings for new tables are relatively obvious:
Period:
PeriodCode
PeriodName
PeriodHeading
PeriodStartYear
PeriodEndYear
Denom:
DenomCode
DenomName
DenomHeading
DenomValue
Type:
TypeCode
TypeName
TypeHeading
All the rest, under a Coin table:
Group
ItemNo
ListNo
TypeCode
ActualDate
SortDate
CostPrice
SalePrice
Estimate
StockLevel
DateEntered
DateSold
Archived
ArchiveWhenSold
Highlight
KeepSold
OnLists
NotForSale
Proof
StockItem
OnWeb
Cats
Ref1
Ref2
Variety
Picture
Description
So I'm looking to normalise the table into the tables specified. I know that i'm looking at JOINs but am wondering the best way to go about it. Do I create a new table FIRST with each data group (Denom, Period, Type) and THEN insert the data using a JOIN statement? Or is there a way to create new tables "on the fly" with a JOIN statement. I've got a honking great book open here and am following along nicely the section on MySQL and also looking through this site, but haven't been able to figure out the "correct" way to do this.
The reason I ask here for some knowledgable advice is that i'm a little unsure about how to maintain the "relationships" and keys etc. i.e If I create a table called "Denom" and populate it with all the distinct items from all the current tables data and also have it create a unique primary key, how to I then insert the reference to this new primary key from the Denom table into the main Coin table (under a new item DenomID) so that they match up?
I basically need to split this table up into 4 separate tables. I've tried this using Access 2007's table analyzer wizard and it looked promising for a n00b like me, but there was so much data, it actually crashed. Repeatedly. Probably for the best, but now I need to know some best practice, and also HOW to put it into practice. Any advice/help/relevant links would be greatly appreciated.
Create the tables first, don't forget to add a foreign key field to all the child tables that contains the Primary key from the main table (also each new table must get a primary key), so that you can join the tables. If you don't have a primary key, you need to create one before doing anything else.
To put the data into the tables is a simple insert
insert tableb (field1, field2)
select field1, field2 from tablea
You will join to get the database out, so rememebr to create indexes on the new tables especially onthe foreign key field.