There are two tables - orders and a list of services. In the first there is a bool field that the order is approved, if it is true then you can’t insert / delete values in the second table. With the UPDATE of the first table and the DELETE of the second, it is clear.
INSERT make as
INSERT INTO b (a_id, b_value)
SELECT *
FROM (VALUES (1, 'AA1-BB1'),(1, 'AA1-BB2'),(1, 'AA1-BB3')) va
WHERE (SELECT NOT confirm FROM a WHERE a_id = 2);
https://dbfiddle.uk/?rdbms=postgres_12&fiddle=7b0086967c1c38b0c80ca5624ebe92e9
How to forbid to insert without triggers and stored procedures? Is it possible to compose somehow complex constraint or a foreign key for checking conditions at the DBMS level?
The most recent version of Postgres supports generated columns. So, you can do:
alter table b add confirm boolean generated always as (false) stored;
Then create a unique key in a:
alter table a add constraint unq_a_confirm_id unique (confirm, id);
And finally the foreign key relationship:
alter table b add constraint fk_b_a_id_confirm
foreign key (confirm, a_id) references a(confirm, id);
Now, only confirmed = false ids can be used. Note that this will prevent updates to a that would invalidate the foreign key constraint.
Related
I have these Oracle tables:
CREATE TABLE AGENT(
ID INTEGER NOT NULL,
GROUP_ID NUMBER(38,0),
........
)
/
CREATE INDEX IX_RELATIONSHIP_AG_GROUP ON AGENT (GROUP_ID)
/
ALTER TABLE AGENT ADD CONSTRAINT AGENTID PRIMARY KEY (ID)
/
CREATE TABLE AGENT_CONFIG(
AGENT_CONFIG_ID INTEGER NOT NULL,
AGENT_ID INTEGER,
.......
)
/
CREATE INDEX IX_RELATIONSHIP16 ON AGENT_CONFIG (AGENT_ID)
/
ALTER TABLE AGENT_CONFIG ADD CONSTRAINT KEY17 PRIMARY KEY (AGENT_CONFIG_ID)
/
ALTER TABLE AGENT_CONFIG ADD CONSTRAINT RELATIONSHIP16 FOREIGN KEY (AGENT_ID) REFERENCES AGENT (ID)
/
I want to use the first table AGENT as main table to store data. Into the second table I want to store configuration about AGENT and use AGENT ID as unique ID.
But I have this problem: I insert successfully row into table AGENT. I need to also add empty row with the same ID into table AGENT_CONFIG and later update that row. How I can duplicate this ID value duplication? Probably with Oracle table trigger? Is three any other way like special relation between the tables?
I use this SQL Query for insert into AGENT table:
INSERT INTO AGENT ("ID, GROUP_ID, NAME.....) VALUES (AGENT_SEQ.nextval, ?, ......)
Is this correct query:
INSERT INTO AGENT (ID, GROUP_ID......) VALUES (AGENT_SEQ.nextval, ?.......)
RETURNING id INTO INSERT INTO AGENT_CONFIG (AGENT_SEQ.nextval, Agent_ID) VALUES (id)"
For this use currval pseudocolumn (as #Nicholas Krasnov specified) of the sequence that you are using after you use nextval for table "AGENT". Currval will duplicate the value that you used for table "AGENT".
So for example :
1. INSERT INTO AGENT (ID, GROUP_ID......) VALUES (AGENT_SEQ.nextval, .......)
2. INSERT INTO AGENT_CONFIG (AGENT_CONFIG_ID,AGENT_ID) VALUES (NULL,AGENT_SEQ.CURRVAL) ;
Link for Sequence Pseudocolumns --> https://docs.oracle.com/cd/B28359_01/server.111/b28286/pseudocolumns002.htm
To establish a 1:1 or 1:{1,n} relation is not that easy:
On every insert in the parent table you'd have to make sure an according insert in the child table is also made.
On every delete from the parent table you'd have to make sure to delete the according child records (usually via cascading delete or by mere foreign key constraints).
On every delete from the child table you'd have to make sure it's not the last one for its parent. (And in that case either forbid the delete or delete the parent with it.)
Forbid or react on updates to the IDs.
You can solve this by disabling (i.e. not granting) direct inserts and deletes (and maybe updates) on the table and provide PL/SQL functions to handle these instead.
If you are okay, however, with a 1:{0,1} or 1:{0,n} relation, then you can simply write the parent record and then look up its ID to write the child record(s).
I have a database from previous project that I want to use in another project, from security reasons I need to update the IDs of one of the table. Problem is that the table is heavily referenced by foreign keys from other tables:
CREATE TABLE "table_table" (
"id" serial NOT NULL PRIMARY KEY,
"created" timestamp with time zone NOT NULL,
);
CREATE TABLE "table_photo" (
"id" serial NOT NULL PRIMARY KEY,
"table_id" integer NOT NULL REFERENCES "table_table" ("id") DEFERRABLE INITIALLY DEFERRED,
);
Now if I change the id on table_table the reference from table_photo won't work.
I will probably use something like this to change the IDs:
UPDATE table_table SET id = id + 15613;
I have read somewhere that I could use ON UPDATE CASCADE constraints to do this but I am not very sure how to use it.
btw: I am using Django ORM.
Get the constraint name with \d "table_photo", which shows:
Foreign-key constraints:
"table_photo_table_id_fkey" FOREIGN KEY (table_id) REFERENCES table_table(id) DEFERRABLE INITIALLY DEFERRED
Then replace it with a constraint that has on update cascade:
ALTER TABLE "table_photo"
DROP CONSTRAINT "table_photo_table_id_fkey",
ADD CONSTRAINT "table_photo_table_id_fkey"
FOREIGN KEY ("table_id")
REFERENCES "table_table"
ON UPDATE CASCADE
DEFERRABLE INITIALLY DEFERRED;
Now when you do your UPDATE, referenced row IDs are automatically updated. Adding an index on "table_photo"."table_id" will help a lot.
This can be slow for big tables though. An alternative if you have large tables is to do it in a couple of stages. For table A with field id that's referenced by table B's field A_id:
Add a new column, new_id, to A, with a UNIQUE constraint. Leave it nullable.
Add a new column, A_new_id to table B, giving it a foreign key constraint to A(new_id).
Populate A.new_id with the new values
Do an
UPDATE B
SET A_new_id = A.new_id
FROM A
WHERE B.A_id = A.id;
to do a joined update, setting the new ID values in B.A_new_id to match.
Drop the column B.A_id and rename B.A_new_id to B.A_id.
Drop the column A.id and rename A.new_id to A.id
Create a PRIMARY KEY constraint on the renamed A.id, USING the index created automatically before.
It's a lot more complicated, especially since for big tables you usually want to do each of these steps in batches.
If this seems too complicated, just do it with a cascading foreign key constraint like above.
I am trying to insert a row into my database table, but I keep on getting a SQL error.
I have a table called tbl_template_log, it has 3 Forgain Keys, user_id, temp_id, savedtemp_id, at the moment I only want to Insert a row with user_id and set temp_id and savedtemp_id to 0.
Query:
INSERT INTO tbl_template_log (user_id, temp_id, savetemp_id, send_date, send_to, email_send) VALUES (user_id=77, temp_id=0, savetemp_id=0, send_date='2013-10-10', send_to='test#test.com', email_send='hello')
Error:
INSERT INTO tbl_template_log (user_id, temp_id, savetemp_id, send_date, send_to, email_send) VALUES (user_id=77, temp_id=0, savetemp_id=0, send_date='2013-10-10', send_to='test#test.com', email_send='hello')
MySQL said: Documentation
#1452 - Cannot add or update a child row: a foreign key constraint fails (`admin_boltmail`.`tbl_template_log`, CONSTRAINT `tbl_template_log_ibfk_1` FOREIGN KEY (`user_id`) REFERENCES `tbl_user` (`user_id`))
From What I understand there is some sort of issue with user_id that the ID of the user has to be existing in tbl_user and ID 77 is an existing user id.....
Could some one point out a mistake I am doing. Thx
You can't add a row to this table unless the other tables specified in your foreign key constraints already have a record with the field value you're trying to insert. That's what a foreign key constraint means.
You're trying to break the rule you defined on your table. No, the database won't let you break the rule. You'll either have to add records to the foreign key tables or disable the constraints.
In my PostgreSQL 9.1 database I've defined RULEs that delete rows from child tables whenever a parent table row is deleted. This all worked OK, until I introduced inheritance. If the parent (referencing) table INHERITS from another table and I delete from the base table then the DELETE succeeds, but the RULE doesn't appear to fire at all - the referenced row is not deleted. If I try to delete from the derived table I get an error:
update or delete on table "referenced" violates foreign key constraint "fk_derived_referenced" on table "derived"
There is no other row in the parent table that would violate the foreign key: it's being referenced by the row that's being deleted! How do I fix this?
The following script reproduces the problem:
-- Schema
CREATE TABLE base
(
id serial NOT NULL,
name character varying(100),
CONSTRAINT pk_base PRIMARY KEY (id)
);
CREATE TABLE referenced
(
id serial NOT NULL,
value character varying(100),
CONSTRAINT pk_referenced PRIMARY KEY (id)
);
CREATE TABLE derived
(
referenced_id integer,
CONSTRAINT pk_derived PRIMARY KEY (id),
CONSTRAINT fk_derived_referenced FOREIGN KEY (referenced_id) REFERENCES referenced (id)
)
INHERITS (base);
-- The rule
CREATE OR REPLACE RULE rl_derived_delete_referenced
AS ON DELETE TO derived DO ALSO
DELETE FROM referenced r WHERE r.id = old.referenced_id;
-- Some test data
INSERT INTO referenced (id, value)
VALUES (1, 'referenced 1');
INSERT INTO derived (id, name, referenced_id)
VALUES (2, 'derived 2', 1);
-- Delete from base - deletes the "base" and "derived" rows, but not "referenced"
--DELETE FROM base
--WHERE id = 2;
-- Delete from derived - fails with:
-- update or delete on table "referenced" violates foreign key constraint "fk_derived_referenced" on table "derived"
DELETE FROM derived
WHERE id = 2
As I said in my comment, this seems an unusual way to do things. But you can make it work with a deferred constraint.
CREATE TABLE derived
(
referenced_id integer,
CONSTRAINT pk_derived PRIMARY KEY (id),
CONSTRAINT fk_derived_referenced FOREIGN KEY (referenced_id)
REFERENCES referenced (id) DEFERRABLE INITIALLY DEFERRED
)
INHERITS (base);
The PostgreSQL docs, Rules vs. Triggers, say
Many things that can be done using triggers can also be implemented
using the PostgreSQL rule system. One of the things that cannot be
implemented by rules are some kinds of constraints, especially foreign
keys.
But it's not clear to me that this specific limitation is what you're running into.
Also, you need to check if other records are still referencing the to-be-deleted rows. I added a test derived record#3, which points to the same #1 reference record.
-- The rule
CREATE OR REPLACE RULE rl_derived_delete_referenced
AS ON DELETE TO tmp.derived DO ALSO (
DELETE FROM tmp.referenced re_del
WHERE re_del.id = OLD.referenced_id
AND NOT EXISTS ( SELECT * FROM tmp.derived other
WHERE other.referenced_id = re_del.id
AND other.id <> OLD.id )
;
);
-- Some test data
INSERT INTO tmp.referenced (id, value)
VALUES (1, 'referenced 1');
-- EXPLAIN ANALYZE
INSERT INTO tmp.derived (id, name, referenced_id)
VALUES (2, 'derived 2', 1);
INSERT INTO tmp.derived (id, name, referenced_id)
VALUES (3, 'derived 3', 1);
-- Delete from base - deletes the "base" and "derived" rows, but not "referenced"
--DELETE FROM base
--WHERE id = 2;
-- Delete from derived - fails with:
-- update or delete on table "referenced" violates foreign key constraint "fk_derived_referenced" on table "derived"
EXPLAIN ANALYZE
DELETE FROM tmp.derived
WHERE id = 2
;
SELECT * FROM tmp.base;
SELECT * FROM tmp.derived;
SELECT * FROM tmp.referenced;
How to specify a trigger which checks if the data inserted into a tables foreign key attribute, actually exists in the references table. If it exist no action should be performed , else the trigger should delete the inserted tuple.
Eg: Consider have 2 tables
R(A int Primary Key) and
S(B int Primary Key , A int Foreign Key References R(A) ) .
I have written a trigger like this :
Create Trigger DelS
BEFORE INSERT ON S
FOR EACH ROW
BEGIN
Delete FROM S where New.A <> ( Select * from R;) );
End;
I am sure I am making a mistake while specifying the inner sub query within the Begin and end Blocks of the trigger. My question is how do I make such a trigger ?
Wouldn't a foreign key constraint better achieve what you want?
ALTER TABLE [dbo].[TABLE2] WITH CHECK
ADD CONSTRAINT [FK_TABLE2_TABLE1] FOREIGN KEY([FK_COLUMN])
REFERENCES [dbo].[TABLE1] ([PK_COLUMN])
GO
This is what foreign key constraints are meant to do - specifically, not allow a record to be inserted that violate the foreign key relationship.
Note that to make this example more readable, I used different column and table names - S, A, R and B looked like a mess.