Table 1:
parent_id string_id
5001 a
8759 b
3957 c
string_id is the primary key for Table 1.
parent_id has an UNIQUE constraint on it.
Table 2:
child_id parent_id string_id
1 5001 a
2 8759 b
3 3957 c
child_id is the primary key for Table 2.
string_id is the foreign key to Table 1.
When I populate new row into Table 2, I do NOT want to insert the parent_id in my query by joining/merging Table 1.
INSERT INTO table_2 (string_id)
VALUES ('a'),
('b'),
('c')
Could anyone give me suggestion whether SQL can populate the parent_id automatically by using built in relationship (e.g. constraint, foreign keys, cascade)? If join is the only way, could you also let me know so that I can stop investigating?
Basically, I want to know what is the most elegant way of solving this problem. I could use join with INSERT, but I think that is an ugly query for such a simple functionality.
Thank you.
The purpose of storing tables with foreign key constraints is so that the data does not need to be duplicated. SQL then offers the JOIN for looking up values.
I would strongly encourage you to use JOIN to look up the parent_id when you need it. If you like, you can write the query once and use a JOIN -- and then anyone using the view would have the parent_id.
Related
I have a situation while database designing, A simple issue but needed a working suggestions
My database tables:
TableAees.
TableBees.
Aees can mapped/contain one or more records of table Bees or also can be without any Bees
Aees can also mapped with one or more records of table Aees itself
Here normal primary key and foreign key relationship/hierarchy won't solve the purpose and also worried that parent/child hierarchy may end up in forming a loop between tables and can give a duplicates records on various joins.
Need a better table mapping for above mentioned tables(a,b) which will satisfy 1 and 2 points.
So to avoid such a situation, how the table relationship/hierarchy will be a better approach?
Database used: SQL Server
Thanks for sharing your knowledge.
You seem to describe a many-to-many relationship. If so, you would create a thrid table to store that relationship, like so:
create table a (
a_id int primary key,
...
);
create table b (
b_id int primary key,
...
);
create table ab (
a_id int references a(a_id),
b_id int references b(b_id),
primary key (a_id, b_id)
)
Each a/b tuple is stored on a separate row in bridge table ab.
I'm trying to get the following scenario to work:
I have three tables, and one of them (IncidentDetail) is to hold incident information of the other two (Incident and PendIncident). I want the IncidentDetail table to reference either an incident in the Incident, or PendIncident table so it could exist in either place. How would I set up the constraints?
Table 1 - Incident:
+--------------------+
| IncidentNbr | Desc |
+--------------------+
Table 2 - PendIncident:
+------------------------+
| PendIncidentNbr | Desc |
+------------------------+
Table 3 - IncidentDetail:
+-----------------------+
| IncidentNbr | Details |
+-----------------------+
The IncidentDetail table will have a FK constraint so that the IncidentDetail.IncidentNbr will need to have a value in either the Incident.IncidentNbr column OR the PendIncident.PendIncidentNbr column.
Is it possible to have a FK constraint on a single column that references into two different tables or will I need a second PendIncidentNbr column in the IncidentDetail table that has its own FK constraint to PendIncident.PendIncidentNbr?
Is that enough to ensure that the IncidentDetail table satisfies at least one of the FK constraints?
The other approach I can think of is to drop the FK constraints all together and use a check constraint where either the IncidentDetail.IncidentNbr column or IncidentDetail.PendIncidentNbr column has a value.
You can have FK constraints on a single column that references into two different tables but it will not work with your use case.
Since an incidentNbr exists either in Incident table or PendIncident table at any given point in time, having two FK constraints in IncidentDetail table will fail as soon as you attempt to insert a record in this child table. Since the incident exists in one parent table but not the other, it will throw an integrity constraint violation error w.r.t. second FK.
Using a check constraint can be a viable solution for this scenario.
Code snippet for quick reference -
Create table table_a(col_a number primary key);
Create table table_b(col_b number primary key);
Create table table_c(col_c number);
ALTER TABLE table_c
ADD CONSTRAINT fk_c_a
FOREIGN KEY (col_c)
REFERENCES table_a(col_a);
ALTER TABLE table_c
ADD CONSTRAINT fk_c_b
FOREIGN KEY (col_c)
REFERENCES table_b(col_b);
Insert into table_a values(100);
Insert into table_b values(200);
Insert into table_c values(100); —-This statement will throw integrity constraint violation error
No, a foreign key can only refer to one parent table.
You will either need two separate columns in INCIDENT_DETAIL, each with its own FK, or else combine INCIDENT and PENDINCIDENT into a single table with a type or status column.
The fact that you find yourself with a single column that seems to refer to either of two parent tables suggests to me that perhaps they are really the same thing at different states of processing.
I have the following 2 tables:
Table A
AId INT NOT NULL
BId INT NOT NULL
Table B
BId INT NOT NULL
AId INT NOT NULL
AId of Table A is the primary key, and BId is a foreign key. Same thing is applied for Table B.
What I am trying to do is, I need to insert record in any table but both tables should get affected.
Is it possible or not, if possible then please suggest how?
Many thanks in advance...
your telling about cross reference and it will not going to work
if you problem is automatically insert data into second table when insert happen to first table, use triggers
CREATE TRIGGER [TRIG_MyTable]
ON [MyTable]
AFTER INSERT
Use deferred constraint on foreign key.
This isn't a big deal, but my OCD is acting up with the following problem in the database I'm creating. I'm not used to working with databases, but the data has to be stored somewhere...
Problem
I have two tables A and B.
One of the datafields is common to both tables - segments. There's a finite number of segments, and I want to write queries that connect values from A to B through their segment values, very much asif the following table structure was used:
However, as you can see the table Segments is empty. There's nothing more I want to put into that table, rather than the ID to give other table as foreign keys. I want my tables to be as simple as possible, and therefore adding another one just seems wrong.
Note also that one of these tables (A, say) is actually master, in the sense that you should be able to put any value for segment into A, but B one should first check with A before inserting.
EDIT
I tried one of the answers below:
create table A(
id int primary key identity,
segment int not null
)
create table B(
id integer primary key identity,
segment int not null
)
--Andomar's suggestion
alter table B add constraint FK_B_SegmentID
foreign key (segment) references A(segment)
This produced the following error.
Maybe I was somehow unclear that segments is not-unique in A or B and can appear many times in both tables.
Msg 1776, Level 16, State 0, Line 11 There are no primary or candidate
keys in the referenced table 'A' that match the referencing column
list in the foreign key 'FK_B_SegmentID'. Msg 1750, Level 16, State 0,
Line 11 Could not create constraint. See previous errors.
You can create a foreign key relationship directly from B.SegmentID to A.SegmentID. There's no need for the extra table.
Update: If the SegmentIDs aren't unique in TableA, then you do need the extra table to store the segment IDs, and create foreign key relationships from both tables to this table. This however is not enough to enforce that all segment IDs in TableB also occur in TableA. You could instead use triggers.
You can ensure the segment exists in A with a foreign key:
alter table B add constraint FK_B_SegmentID
foreign key (SegmentID) references A(SegmentID)
To avoid rows in B without a segment at all, make B.SegmentID not nullable:
alter table B alter column SegmentID int not null
There is no need to create a Segments table unless you want to associate extra data with a SegmentID.
As Andomar and Mark Byers wrote, you don't have to create an extra table.
You can also CASCADE UPDATEs or DELETEs on the master. Be very carefull with ON DELETE CASCADE though!
For queries use a JOIN:
SELECT *
FROM A
JOIN B ON a.SegmentID = b.SegmentID
Edit:
You have to add a UNIQUE constraint on segment_id in the "master" table to avoid duplicates there, or else the foreign key is not possible. Like this:
ALTER TABLE A ADD CONSTRAINT UNQ_A_SegmentID UNIQUE (SegmentID);
If I've understood correctly, a given segment cannot be inserted into table B unless it has also been inserted into table A. In which case, table A should reference table Segments and table B should reference table A; it would be implicit that table B ultimately references table Segments (indirectly via table A) so an explicit reference is not required. This could be done using foreign keys (e.g. no triggers required).
Because table A has its own key I assume a given segment_ID can appear in table A more than once, therefore for B to be able to reference the segment_ID value in A then a superkey would need to be defined on the compound of A_ID and segment_ID. Here's a quick sketch:
CREATE TABLE Segments
(
segment_ID INTEGER NOT NULL UNIQUE
);
CREATE TABLE A
(
A_ID INTEGER NOT NULL UNIQUE,
segment_ID INTEGER NOT NULL
REFERENCES Segments (segment_ID),
A_data INTEGER NOT NULL,
UNIQUE (segment_ID, A_ID) -- superkey
);
CREATE TABLE B
(
B_ID INTEGER NOT NULL UNIQUE,
A_ID INTEGER NOT NULL,
segment_ID INTEGER NOT NULL,
FOREIGN KEY (segment_ID, A_ID)
REFERENCES A (segment_ID, A_ID),
B_data INTEGER NOT NULL
);
I have two tables, the first has a primary key that is an identity, the second has a primary key that is not, but that key has a foreign key constraint back to the first table's primary key.
If I am inserting one record at a time I can use the Scope_Identity to get the value for the pk just inserted in table 1 that I want to insert into the second table.
My problem is I have many records coming from selects I want to insert in both tables, I've not been able to think of a set based way to do these inserts.
My current solution is to use a cursor, insert in the first table, get key using scope_identity, insert into second table, repeat.
Am I missing a non-cursor solution?
Yes, Look up the output clause in Books online.
I had this problem just this week: someone had introduced a table with a meaningless surrogate key into the schema where naturally keys are used. No doubt I'll fix this soon :) until then, I'm working around it by creating a table of data to INSERT from: this could be a permanent or temporary base table or a derived table (see below), which should suit your desire for a set-based solution anyhow. Use a join between this table and the table with the IDENTITY column on the natural key to find out the auto-generated values. Here's a brief example:
CREATE TABLE Test1
(
surrogate_key INTEGER IDENTITY NOT NULL UNIQUE,
natural_key CHAR(10) NOT NULL CHECK (natural_key NOT LIKE '%[^0-9]%') UNIQUE
);
CREATE TABLE Test2
(
surrogate_key INTEGER NOT NULL UNIQUE
REFERENCES Test1 (surrogate_key),
data_col INTEGER NOT NULL
);
INSERT INTO Test1 (natural_key)
SELECT DT1.natural_key
FROM (
SELECT '0000000001', 22
UNION ALL
SELECT '0000000002', 55
UNION ALL
SELECT '0000000003', 99
) AS DT1 (natural_key, data_col);
INSERT INTO Test2 (surrogate_key, data_col)
SELECT T1.surrogate_key, DT1.natural_key
FROM (
SELECT '0000000001', 22
UNION ALL
SELECT '0000000002', 55
UNION ALL
SELECT '0000000003', 99
) AS DT1 (natural_key, data_col)
INNER JOIN Test1 AS T1
ON T1.natural_key = DT1.natural_key;