Cannot find a good answer for this online. I need to create three tables as an example below, a parent with an auto increment ID that will then link to the two child tables (Subject and Comment) with the same exact ID and cascade back if that parent ID is deleted.
Any ideas on how to solve?
I have googled and am extremely confused as to how to solve this one. I have a decent amount of experience with SQL, but not with creating tables and relationships.
CREATE TABLE Parent
(
ParentID INT NOT NULL IDENTITY PRIMARY KEY,
Email VARCHAR(50) NOT NULL,...
)
CREATE TABLE Subject
(
ParentID INT NOT NULL PRIMARY KEY,
Subject
)
CREATE TABLE Comment
(
ParentID INT NOT NULL PRIMARY KEY,
Comment VARCHAR(100)
)
Use a 1 to 1 relationship with on delete cascade:
CREATE TABLE Parent(
ParentID INT NOT NULL IDENTITY PRIMARY KEY,
Email VARCHAR(50) NOT NULL,...
)
CREATE TABLE Subject(
ParentID INT NOT NULL PRIMARY KEY,
Subject,
CONSTRAINT fk_SubjectParentId FOREIGN KEY (ParentID)
REFERENCES Parent (ParentID) ON DELETE CASCADE
)
CREATE TABLE Comment(
ParentID INT NOT NULL PRIMARY KEY,
Comment VARCHAR(100),
CONSTRAINT fk_CommentParentId FOREIGN KEY (ParentID)
REFERENCES Parent (ParentID) ON DELETE CASCADE
)
This is known as a 1 to 1 relationship, since both ends of the foreign key are unique within their table.
Though I have to agree with Mitch Wheat comment, cascading deletes is something to use with caution. by specifying cascade delete, you are telling the database engine to delete the related records whenever a parent record is deleted. Not having that cascade delete option will simply throw an error if you attempt to delete a record that is referenced by another table. This forces you, as a developer, to think about the side effects of deleting rows from the parent table and basically acts as a "Are you sure you want to delete?" guard against unwanted deletes.
Related
I have two tables,
CREATE TABLE ActivityCodes (
ActivityCodeID INT NOT NULL PRIMARY KEY,
LocationID INT NOT NULL
);
and
CREATE TABLE LocationSettings (
LocationID INT NOT NULL PRIMARY KEY,
DefaultFooActivityCodeID INT,
FOREIGN KEY (DefaultFooActivityCodeID) REFERENCES ActivityCodes(ActivityCodeID)
);
with the foreign key relationship as indicated. Activity codes are valid only for the given LocationID and DefaultFooActivityCodeID in the LocationSettings table should be an ActivityCodeID where ActivityCodes.LocationID == LocationSettings.LocationID. How can I enforce that in SQL? Can it be done with constraints or foreign keys? Is it possible at all?
Edit: Just to add some clarification, this what valid data in these table should look like:
ActivityCodes
ActivityCodeID
LocationID
1
123
2
123
3
456
4
456
LocationSettings
LocationID
DefaultFooActivityCodeID
123
1
456
4
A location can have multiple activity codes. The default activity code for a location must be an activity code for that location. #Charlieface I tried using a composite foreign key as suggested in the answer you linked but I get an error saying LocationID on ActivityCodes is neither unique nor a primary key (I'm using MS SQL Server).
The DDL you provide, do not means what you have describe.
The DDL describe this:
The ActivityCodes are independent of LocationSettings.
The LocationSettings instead depends on an ActivityCodes (one ActivityCodes has many LocationSettings)
The foreign key is well defined with this like FOREIGN KEY (DefaultFooActivityCodeID) REFERENCES ActivityCodes(ActivityCodeID). If you try to insert a LocationSettings without first insert an ActivityCodes it will fail due constraint violation.
A foreign key reference does not have to be a primary key. This allows you to have two foreign key references to the same table, even if they are redundant:
CREATE TABLE ActivityCodes (
ActivityCodeID INT NOT NULL PRIMARY KEY,
LocationID INT NOT NULL,
UNIQUE (LocationID, ActivityCodeID)
);
CREATE TABLE LocationSettings (
LocationID INT NOT NULL PRIMARY KEY,
DefaultFooActivityCodeID INT,
FOREIGN KEY (DefaultFooActivityCodeID) REFERENCES ActivityCodes(ActivityCodeID),
FOREIGN KEY (LocationID, DefaultFooActivityCodeID) REFERENCES ActivityCodes(LocationID, ActivityCodeID)
);
Although this expresses what you want, you will find that this is a bit tricky to maintain in practice. Setting the default requires the following steps:
Insert a location with a NULL default.
Insert a row into ActivityCodes with the default activity.
Update the default in LocationSettings.
I have 2 tables.Table A have columns as (aid, name,depart) where aid is primary key.
Table B has (aid1,aid2,aid3,created_by) where aid1 is the primary_key. aid1, aid2 and aid3 all are primary key of Table A
I want to delete a record in Table B i.e aid1 and simultaneously with delete cascade all three records in TABLE A should be deleted. My doubt here is where should I put the delete cascade constraint. I know that in parent child relationship we need to put delete cascade on the child table so that when parent is deleted, child entities are also deleted but in this scenario I dont understand where I should put delete cascade
Cascading a table will be on the child table. You have to set this on your child table when creating or after creating the child table.
E.g
CREATE TABLE schools (
id int auto_increment primary key not null,
schoolname varchar(191) not null
);
CREATE TABLE students(
id int auto_increment primary key not null,
studentname varchar(191) not null,
school_id int FOREIGN KEY REFERENCES students(id) ONDELETE CASCADE
);
or
You can as well alter the table by running this command.
ALTER TABLE childTable
ADD FOREIGN KEY (childTableParentTableColumn) REFERENCES parentTable(parentTableColumn);
so I have 3 tables, Applicant, Vacancy and a Link table. I am trying to have the applicant data removed when the vacancy is removed. Here is the current SQL code I have, would this remove the applicant?
CREATE TABLE Applicant(
ID INT PRIMARY KEY,
name varchar(20),
address varchar(20),
VacancyID INT,
FOREIGN KEY (VacancyID) REFERENCES Vacancy(ID) ON DELETE CASCADE);
CREATE TABLE AppVac(
ApplicantID INT PRIMARY KEY,
VacancyID INT PRIMARY KEY,
FOREIGN KEY (ApplicantID) REFERENCES Applicant(ID),
FOREIGN KEY (VacancyID) REFERENCES Vacancy(ID);
CREATE TABLE Vacancy(
ID INT PRIMARY KEY,
.....
No. The Applicant has not relationship to the Vacancy. What gets removed are all corresponding rows in AppVac.
If you want to require that applicants have at least one row in AppVac, then you'll need a delete trigger on the table. Cascading foreign keys won't do that for you. That is, cascading deletes delete from the referring table, not from the reference table.
Here's my situation: I have two tables created with
CREATE DATABASE JsPracticeDb;
/* Create tables corresponding to the problems, solutions to
problems, and ratings of problems or solutions */
CREATE TABLE Problems (
id INT PRIMARY KEY NOT NULL,
prompt_code VARCHAR(3000),
test_func_code VARCHAR(3000),
test_input_code VARCHAR(3000)
);
CREATE TABLE Solutions (
id INT PRIMARY KEY NOT NULL,
problem_id INT,
solver_name VARCHAR(50),
code VARCHAR(3000),
FOREIGN KEY (problem_id) REFERENCES Problems(id) ON DELETE CASCADE,
);
and I was thinking about creating a table for rating Solutions, which I wrote as
CREATE TABLE Ratings (
id INT PRIMARY KEY NOT NULL,
solution_id INT,
stars TINYINT,
FOREIGN KEY (solution_id) REFERENCES Solutions(id) ON DELETE CASCADE
);
but then I realized I might actually want to have Problems rated as well. The "brute force" solution, as I see it, is
CREATE TABLE SolutionRatings (
id INT PRIMARY KEY NOT NULL,
solution_id INT,
stars TINYINT,
FOREIGN KEY (solution_id) REFERENCES Solutions(id) ON DELETE CASCADE
);
CREATE TABLE ProblemRatings (
id INT PRIMARY KEY NOT NULL,
problem_id INT,
stars TINYINT,
FOREIGN KEY (problem_id) REFERENCES Problems(id) ON DELETE CASCADE
);
but my programming intuition says there's a problem with the fact that I used copy-paste to write two sections of code that are almost identical. However, I can't think of any alternative solution that uses an intersection table or something like that also allows me to do a cascade delete. For example, I know I could do
CREATE TABLE RatedTables (
id TINYINT PRIMARY KEY NOT NULL,
table_name VARCHAR(9)
);
INSERT INTO RatedTables (table_name) VALUES ('Problems','Solutions');
CREATE TABLE Ratings (
id INT PRIMARY KEY NOT NULL,
rated_table_id TINYINT NOT NULL,
stars TINYINT,
FOREIGN KEY (rated_table_id) REFERENCES RatedTables(id)
);
but then how would I make it so that if a Solution with corresponding Ratings was deleted then those ratings would be too?????
You basically have two options but this is a good opportunity to go back and review your db structure.
The first option is to do something like this:
CREATE TABLE potential_link1 (
id int primary key,
...
);
CREATE TABLE potential_link2 (
id int primary key,
....
);
CREATE TABLE ratings (
id int primary key,
potential_link1 int references potential_link1(id) on delete cascade,
potential_link2 int references potential_link2(id) on delete cascade,
....
check(potential_link1 is null or potential_link2 is null),
check(potential_link2 is not null or potential_link1 is not null)
);
This works but as you can see it is a bit complex.
The second possibility is that since there are clear cases where a is dependent on the union of b and c then you may think about whether you can refactor your db structure to reflect that so you only need one table to link against.
There is nothing wrong with two tables looking so much alike. They contain different things and you won't want to select all three-star ratings no matter whether on problems or solutions for instance - you would always work with solution ratings or problem ratings.
But to have both ratings in one table is also not wrong and can be a good idea when you want ratings to behave the same, no matter whether on problem or solution (e.g. both shall have 1 to 5 stars, both can have a comment no longer then 200 chars, ...).
This could be done by simply giving the ratings table both a problem_id and a solution_id with foreign keys on the tables and fill always one or the other. With natural keys, the same would feel even more, well, natural:
problem(problem_no, data)
solution(problem_no, solution_no, data)
rating(problem_no, solution_no, data)
with rating.solution_no nullable and foreign keys on both parent tables.
Let's say we have these tables:
CREATE TABLE A (
id SERIAL NOT NULL PRIMARY KEY
);
CREATE TABLE B (
id SERIAL NOT NULL PRIMARY KEY
);
CREATE TABLE Parent (
id SERIAL NOT NULL PRIMARY KEY,
aId INTEGER NOT NULL REFERENCES A (id),
bId INTEGER NOT NULL REFERENCES B (id),
UNIQUE(aId, bId)
);
CREATE TABLE Child (
parentId INTEGER NOT NULL REFERENCES Parent (id),
createdOn TIMESTAMP NOT NULL
);
Is it possible to create a unique constraint on Child such that for all rows in Child at most one references a Parent having some value of aId? Stated another way can I created a unique constraint so that the join of the above tables will have no duplicate aId? I'm thinking not--the grammars of every database I could find seem tied to one table per constraint--but that might be a lack of imagination on my part. (De-normalizing to include aId on Child is one solution, of course.)
You could try the following. You have to create a redundant UNIQUE constraint on (id, aId) in Parent (SQL is pretty dumb isn't it?!).
CREATE TABLE Child
(parentId INTEGER NOT NULL,
aId INTEGER NOT NULL UNIQUE,
FOREIGN KEY (parentId,aId) REFERENCES Parent (id,aId),
createdOn TIMESTAMP NOT NULL);
Possibly a much better solution would be to drop parentId from the Child table altogether, add bId instead and just reference the Parent table based on (aId, bId):
CREATE TABLE Child
(aId INTEGER NOT NULL UNIQUE,
bId INTEGER NOT NULL,
FOREIGN KEY (aId,bId) REFERENCES Parent (aId,bId),
createdOn TIMESTAMP NOT NULL);
Is there any reason why you can't do that?
The proper way to do this would be to do away with the Child table altogether and put the createdOn column in the Parent table, without the NOT NULL constraint. All you are saying is that one Parent entry can have zero or one (but not more) createdOn values. You don't need a separate table for that. The fact that it is not easy or obvious to do otherwise partially proves my point. ;-) SQL usually works out that way.