This question already has answers here:
How to implement one-to-one, one-to-many and many-to-many relationships while designing tables?
(4 answers)
Closed 5 years ago.
I want two model 2 simple tables: Account & Manager.
Account can have multiple managers and Manager can have multiple accounts to manage. so we have many-to-many relation between them.
This is how I created them in the db:
CREATE TABLE Account (
accountId int NOT NULL AUTO_INCREMENT,
name varchar(255) NOT NULL,
PRIMARY KEY (accountId)
);
CREATE TABLE Manager (
managerId int NOT NULL AUTO_INCREMENT,
name varchar(255) NOT NULL,
accountId int NOT NULL,
PRIMARY KEY (managerId),
FOREIGN KEY (accountId) REFERENCES Account (accountId)
);
the problem which is probably obvious to you is that I will have duplicated names and different id's for the same manager, like here:
How would you recommend an sql newbie to do it? :)
I think the way I model it is a one-to-many...
Create a Mapping table ( Egs Account_Manager) to Map Account and Manager and AccountID and ManagerID should be foreign Key.
Regards
Abdul
I would eliminate the accountid/foreign key from manager and introduce a new table to cross reference the two tables. Something like this:
CREATE TABLE ManagerAccount(
id int not null auto_increment,
managerId int not null,
accountId int not null,
primary key(id),
foreign key(managerid) references Manager (ManagerID),
foreign key(accountId) references Account (AccountID)
)
Maybe throw a unique index over the two foreign keys.
Implement a many-to-many relationship with a third table, with foreign keys to the two related tables.
As an example:
person
id
person_name
and
club
id
club_name
A club can have zero, one or more members; a person can be a member of zero, one or more clubs. It's a many-to-many relationship.
The simplest form of the relationship table:
membership
club_id PK, FK ref club.id
person_id PK, FK ref person.id
could be defined ...
CREATE TABLE membership
( club_id INT NOT NULL COMMENT 'PK, FK ref club.id'
, person_id INT NOT NULL COMMENT 'PK, FK ref person.id'
, PRIMARY KEY (club_id, person_id)
, KEY membership_IX1 (person_id)
, CONSTRAINT FK_membership_club FOREIGN KEY (club_id) REFERENCES club (id)
, CONSTRAINT FK_membership_person FOREIGN KEY (person_id) REFERENCES person (id)
)
We note that this relationship itself might have attributes, such as date joined and date resigned. There might also be status (provisional, active, probationary), and we might want to track offices or role within the club.
The relationship might turn out to be more than just a junction or link table. It may actually be an entity in our system. And we probably want to handle it like an entity, adding a separate id column, and also consider removing the requirement that (club_id,person_id) be unique.
Usually, the best way of going about modeling a many-to-many relationship is by creating a separate table to hold it. Using your example:
CREATE TABLE Account (
accountId int NOT NULL AUTO_INCREMENT,
name varchar(255) NOT NULL,
PRIMARY KEY (accountId)
);
CREATE TABLE Manager (
managerId int NOT NULL AUTO_INCREMENT,
name varchar(255) NOT NULL,
PRIMARY KEY (managerId),
);
CREATE TABLE Account_Manager (
id int NOT NULL AUTO_INCREMENT,
accountId int NOT NULL,
managerId int NOT NULL,
PRIMARY KEY (id),
FOREIGN KEY (accountId) REFERENCES Account(accountId)
FOREIGN KEY (managerId) REFERENCES Manager(managerId)
);
This way, any association between a Manager and an Account will be present in the Account_Manager table (e.g. (5,1) would represent patrick's association with the account with accountId = 5). However, to fully understand why this is the most common approach, I'd recommend you read about normalization.
Related
I have mechanic that provide some services and there may be several services provided by a mechanic and how is better way to make tables in this case?
What i have now is :
Mechanic table :
create table mechanic(
id_master int not null unique,
rating int DEFAULT 10,
start_time TIME not null,
end_time TIME not null,
work_or_not BOOL DEFAULT 1,
Constraint FK_masterID_userID FOREIGN KEY(id_master) REFERENCES user(id_user),
Constraint Check_STARTTIME_ENDTIME check(start_time<end_time),
Constraint CHECK_FOR_STARTTIME CHECK(start_time>'-1:0:0' AND HOUR(start_time)<23),
Constraint CHECK_FOR_ENDTIME CHECK(end_time>'-1:0:0' AND HOUR(end_time)<23));
and i need to show what services mechanic provides and what table should i create ?
Maybe services table that ref to mechanic table via foreign key but i also need to store services values, so what should i do?
If some mechanic may provide different services and some service may be provided by different mechanics then this is many-to-many (M:N) link which needs in additional adjacency table.
CREATE TABLE mechanic ( id_mechanic INT AUTO_INCREMENT PRIMARY KEY
-- , ... {another columns}
);
CREATE TABLE service ( id_service INT AUTO_INCREMENT PRIMARY KEY
-- , ... {another columns}
);
CREATE TABLE adjacency ( id_mechanic INT NOT NULL,
id_service INT NOT NULL,
PRIMARY KEY (id_mechanic, id_service),
FOREIGN KEY (id_mechanic) REFERENCES mechanic (id_mechanic),
FOREIGN KEY (id_service) REFERENCES service (id_service)
);
I have three tables: property, person, and company. One property can only belong to either a person or a company. A person or a company can have more than one property.
My current database design is to include two foreign keys - person_id and company_id in property table, always with one of them null and the other not null. I'm just wondering is there any better way to design the database in this scenario?
CREATE TABLE person(
person_id int NOT NULL PRIMARY KEY,
name varchar(255)
);
CREATE TABLE company(
company_id int NOT NULL PRIMARY KEY,
name varchar(255)
);
CREATE TABLE property(
property_id int NOT NULL PRIMARY KEY,
name varchar(255),
person_id REFERENCES person,
company_id REFERENCES company
);
Create additional table CHECK constraint:
CREATE TABLE property(
property_id int NOT NULL PRIMARY KEY,
name varchar(255),
person_id REFERENCES person,
company_id REFERENCES company,
CHECK (person_id IS NULL + company_id IS NULL = 1)
);
This will forbid wrong values (both NULL or both NOT NULL).
PS. Two references presence is legal and safe itself.
----Scheme1----
CREATE TABLE college (
id INT AUTO_INCREMENT,
name VARCHAR(250) NOT NULL,
address VARCHAR(250),
PRIMARY KEY (id)
);
CREATE TABLE student (
college INT NOT NULL,
username VARCHAR(50) NOT NULL,
name VARCHAR(100),
FOREIGN KEY (college) REFERENCES college(id),
CONSTRAINT pk PRIMARY KEY (college,username)
);
CREATE TABLE subject (
college INT NOT NULL,
id INT NOT NULL,
name VARCHAR(100),
FOREIGN KEY (college) REFERENCES college(id),
CONSTRAINT pk PRIMARY KEY (college,id)
);
CREATE TABLE marks (
college INT NOT NULL,
student VARCHAR(50) NOT NULL,
subject INT NOT NULL,
marks INT NOT NULL,
// forget about standard for this example
FOREIGN KEY (college) REFERENCES college(id),
FOREIGN KEY (student) REFERENCES student(username),
FOREIGN KEY (subject) REFERENCES subject(id),
CONSTRAINT pk PRIMARY KEY (college,subject,student)
);
----Scheme2----
CREATE TABLE college (
id INT AUTO_INCREMENT,
name VARCHAR(250) NOT NULL,
address VARCHAR(250),
PRIMARY KEY (id)
);
CREATE TABLE student (
college INT NOT NULL,
id BIGINT NOT NULL AUTO_INCREMENT,
username VARCHAR(50) NOT NULL,
name VARCHAR(100),
FOREIGN KEY (college) REFERENCES college(id),
PRIMARY KEY (id)
);
CREATE TABLE subject (
college INT NOT NULL,
id BIGINT NOT NULL AUTO_INCREMENT,
name VARCHAR(100),
FOREIGN KEY (college) REFERENCES college(id),
PRIMARY KEY (id)
);
CREATE TABLE marks (
student VARCHAR(50) NOT NULL,
subject INT NOT NULL,
id BIGINT NOT NULL AUTO_INCREMENT,
marks INT NOT NULL,
// forget about standard for this example
FOREIGN KEY (student) REFERENCES student(id),
FOREIGN KEY (subject) REFERENCES subject(id),
PRIMARY KEY (id)
);
Looking at the above database schemes it looks like Scheme1 will give better performance while searching for the result of a specific student and faster in filtering results but it feels like it is not in all normalized forms. While Scheme2, on the other hand, looks to be fully normal but might require more JOIN operations to fetch certain results or filter the data.
Please tell me if I'm wrong about my Schemes here, also tell me which one is better?
I would go for Schema 2: when it comes to reference a table, it is easier done by using a single column (auto_incremented primary key in Schema 1) than a combination of columns (coumpound primary keys in Schema 1). Also, as commented by O.Jones, Schema 2 assumes that two students in the same college cannot have the same name, which does not seem sensible.
There are other issues with Schema 1, eg the foreign key that relates the marks to students is malformed (you would need a coumpound foreign keys that include the college id instead of just the student name).
With properly defined foreign keys referencing primary keys, performance will not be a problem; joins perform good in this situation.
But one flaw should be fixed in Schema 2, that is to store a reference to the college in the marks table. You don't need this, since a student belongs to a college (there is a reference to the college in the student table).
Also, I am unsure that a subject should belong to a college: isn't it possible that the same subject would be taught in different colleges?
Finally, I would suggest giving clearer names to the foreign key columns, like student_id instead of student, and college_id instead of college.
It's difficult to assess whether a schema is normalized without first knowing the the relationships between entities. Can a student be associated with only one college? Can a student be associated multiple times over with the same subject, getting different marks?
Declaring foreign keys maintains referential integrity but slows down insertions and updates. You can get the same functionality without declaring the fks, but you may end up with some orphaned records. The fact that a particular index is used for a fk, or not, makes no difference to SELECT query performance.
JOIN operations use indexes. So do fks. So if you have the correct indexes, your JOIN operations will be efficient. But it's impossible to know which indexes are the best without knowing your JOIN queries.
Conventionally, each table's id column comes first. And many designers name each id column after the table in which it appears, for example college.college_id rather than college.id. That makes JOIN queries slightly easier to read.
You should use a surrogate primary key in the student table (student.student_id) rather than using the student's name as part of the primary key. JOINing on id values is faster than joining on VARCHAR() values. And, some students may share names. (In the real world, peoples's dates of birth accompany their names in tables: it helps tell people apart.)
I think your marks table should contain these columns:
CREATE TABLE marks (
student_id INT NOT NULL,
subject_id INT NOT NULL,
marks INT NOT NULL,
// foreign keys as needed
PRIMARY KEY (student_id, subject_id)
);
Can a student have multiple marks for the same subject? In that case use a marks_id as the pk instead of (student_id, subject_id).
Basically I need to create a new table that uses specific information from two other tables.
For example, I have a table called person with the elements person_id, first_name, last_name, gender, age, and fav_quote. I have a second table called department with the elements dept_id, dept_name, and building. I now need to create and intersection table with the person_id and dept_id elements included. And both must be the primary key (which I assume just means PRIMARY KEY (person_id, dept_id) command in my source).
CREATE TABLE person (
person_id INT(8) NOT NULL auto_increment,
first_name VARCHAR(25) NOT NULL,
last_name VARCHAR(25) NOT NULL,
gender VARCHAR(1),
age INT(8),
fav_quote TEXT,
PRIMARY KEY (person_id)
);
CREATE TABLE department (
dept_id INT(8) NOT NULL auto_increment,
dept_name VARCHAR(25) NOT NULL,
building VARCHAR(25) NOT NULL,
PRIMARY KEY (dept_id)
);
That is the code I have for the initial two tables I'm just not sure how to create an intersection and, having gone back over my notes, I can't find the instructions on how to write it.
You got the primary key part right. I'd add foreign keys to your existing table in order to prevent creating interactions with people or departments that don't exist:
CREATE TABLE person_department
person_id INT(8) NOT NULL,
dept_id INT(8) NOT NULL,
PRIMARY KEY(person_id, dept_id),
FOREIGN KEY(person_id) REFERENCES person(person_id),
FOREIGN KEY(dept_id) REFERENCES department(dept_id)
)
You need a table with 2 fields; person_id and dept_id. The table will have foreign keys to the two tables person and department primary keys’ and a composite primary key of both.
Also, this table is only necessary if there is a one to many relationship of person to department. Otherwise just add dept_id as a foreign key in person.
I have the following tables (Primary key in bold. Foreign key in Italic)
Customer table
ID---Name---Balance---Account_Name---Account_Type
Account Category table
Account_Type----Balance
Customer Detail table
Account_Name---First_Name----Last_Name---Address
Can I have two foreign keys in the Customer table and how can I implement this in MySQL?
Updated
I am developing a web based accounting system for a final project.
Account Category
Account Type--------------Balance
Assets
Liabilities
Equity
Expenses
Income
Asset
Asset_ID-----Asset Name----Balance----Account Type
Receivable
Receivable_ID-----Receivable Name-------Address--------Tel-----Asset_ID----Account Type
Receivable Account
Transaction_ID----Description----Amount---
Balance----Receivable_ID----Asset_ID---Account Type
I drew the ER(Entity relationship) diagram using a software and when I specify the relationship it automatically added the multiple foreign keys as shown above. Is the design not sound enough?
create table Table1
(
id varchar(2),
name varchar(2),
PRIMARY KEY (id)
)
Create table Table1_Addr
(
addid varchar(2),
Address varchar(2),
PRIMARY KEY (addid)
)
Create table Table1_sal
(
salid varchar(2),`enter code here`
addid varchar(2),
id varchar(2),
PRIMARY KEY (salid),
index(addid),
index(id),
FOREIGN KEY (addid) REFERENCES Table1_Addr(addid),
FOREIGN KEY (id) REFERENCES Table1(id)
)
Yes, MySQL allows this. You can have multiple foreign keys on the same table.
Get more details here FOREIGN KEY Constraints
The foreign keys in your schema (on Account_Name and Account_Type) do not require any special treatment or syntax. Just declare two separate foreign keys on the Customer table. They certainly don't constitute a composite key in any meaningful sense of the word.
There are numerous other problems with this schema, but I'll just point out that it isn't generally a good idea to build a primary key out of multiple unique columns, or columns in which one is functionally dependent on another. It appears that at least one of these cases applies to the ID and Name columns in the Customer table. This allows you to create two rows with the same ID (different name), which I'm guessing you don't want to allow.
Yes, a table have one or many foreign keys and each foreign keys hava a different parent table.
CREATE TABLE User (
user_id INT NOT NULL AUTO_INCREMENT,
userName VARCHAR(100) NOT NULL,
password VARCHAR(255) NOT NULL,
email VARCHAR(255) NOT NULL,
userImage LONGBLOB NOT NULL,
Favorite VARCHAR(255) NOT NULL,
PRIMARY KEY (user_id)
);
and
CREATE TABLE Event (
EventID INT NOT NULL AUTO_INCREMENT,
PRIMARY KEY (EventID),
EventName VARCHAR(100) NOT NULL,
EventLocation VARCHAR(100) NOT NULL,
EventPriceRange VARCHAR(100) NOT NULL,
EventDate Date NOT NULL,
EventTime Time NOT NULL,
EventDescription VARCHAR(255) NOT NULL,
EventCategory VARCHAR(255) NOT NULL,
EventImage LONGBLOB NOT NULL,
index(EventID),
FOREIGN KEY (EventID) REFERENCES User(user_id)
);