So I've got Table ActorInMovies, which has 3 foreign keys.
CREATE TABLE ActorInMovie(
ID_ROLE bigserial REFERENCES Role(ID_ROLE) ON DELETE CASCADE,
ID_ACTOR bigserial REFERENCES Actor(ID_Actor) ON DELETE CASCADE,
ID_MOVIE bigserial REFERENCES Movie(ID_Movie) ON DELETE CASCADE,
CONSTRAINT ActorInMovie_pk PRIMARY KEY (ID_ROLE));
I assumed that when I try to insert something like:
INSERT INTO ActorInMovie (ID_ROLE, ID_ACTOR) values (1,1);
that it would result in an error as ID_MOVIE was not specified (null I supposed).. but it automatically starts assigning indexes staring from 1.
What am I doing wrong? As written here, I thought that "PostgreSQL automatically creates indexes on primary keys and unique constraints, but not on the referencing side of foreign key relationships."
I have a very hard time imagining a use case where a serial(or bigserial) column references another column. It's usually the other way round: the serial column should go on the other end of the foreign key constraint.
I have an equally hard time imagining a design where a movie_id needs to be bigint instead of just int. There aren't nearly enough movies on this planet.
Also, there is a good chance, a column called movie_id in a table called actor_in_movie should be defined as NOT NULL.
In short: I doubt your design flies at all. Maybe something like:
CREATE TABLE actor (actor_id serial PRIMARY KEY, actor text, ...);
CREATE TABLE movie (movie_id serial PRIMARY KEY, movie text, ...);
CREATE TABLE actor_in_movie(
role_id serial PRIMARY KEY
,actor_id int NOT NULL REFERENCES actor(actor_id) ON DELETE CASCADE
,movie_id int NOT NULL REFERENCES movie(movie_id) ON DELETE CASCADE
);
A NOT NULL constraint is redundant, while the column is included in the primary key.
You probably want indices on actor_id and on movie_id in actor_in_movie.
More details:
How to implement a many-to-many relationship in PostgreSQL?
This is simply bigserial working exactly as advertised. It has nothing to do with the foreign key constraint, or with an index.
Related
I'm new to SQL. I was trying to run sql schema, here is a part of code
create table PageColours (
id serial,
userID serial references users(id),
--references users(id),
isTemplate boolean default'false',
name NameValue not null unique,
primary key (id)
);
create table People (
id serial,
email EmailValue not null unique,
givenName NameValue not null,
familyName NameValue,
invitedID serial references Events(id),
attendedID serial references Events(id),
primary key (id)
);
create table users(
id serial
references People(id),
passWord varchar not null,
BillingAddress serial not null
references Places(id),
HomeAddress serial
references Places(id),
ListID serial
references ContactLists(id),
ColorID serial
references PageColours(id),
primary key (id)
);
It returns[2020-07-03 15:28:19] [42P01] ERROR: relation "people" does not exist
[2020-07-03 15:28:19] [42P01] ERROR: relation "users" does not exist
In fact all foreign key reference table reference not exist. When i remove the reference, the table can be created, can someone please help me ?
The script is run sequentially. So when the pagecolours table is created, the users table does not yet exist and thus the references users fails.
You need to re-order the script, so that the users table is created first. But as you have a circular reference (users references pagecolours and pagecolours references users) you need to create the tables without an "inline" reference, and then at the end of the script you need to run an ALTER TABLE to create the foreign keys.
But having a circular reference like that, is usually not a good idea. But if you are 100% sure you need it, you should at least declare the foreign keys as deferrable, to make inserting rows easier.
Also: serial is not a datatype. A foreign key column that references a serial column should be defined as an integer. In general it is recommended to move away from serial and use integer generated always as identity instead.
I'm running PostgreSQL 9.4 and have the following table:
CREATE TABLE user_cars (
user_id SERIAL REFERENCES users (id) ON DELETE CASCADE,
car CHARACTER VARYING(255) NOT NULL,
CONSTRAINT test UNIQUE (user_id, car)
);
The table allows a user to have multiple cars, but only use the car name once. But other users may have the same car name.
I would like to have another table with references to the unique constraint test, and have tried stuff like:
CREATE TABLE mappings (
other_id CHARACTER(9) REFERENCES other (id) ON DELETE CASCADE,
user_cars REFERENCES user_cards (test) ON DELETE CASCADE
);
But that fails "obviously". I would like to make sure that other_id only have a single references to a user_car entry.
So to explain, how can I in table mappings have a references to test from table user_cars.
This is the thing that fails currently:
user_cars REFERENCES user_cards (test) ON DELETE CASCADE
Don't use composite foreign key references, if you can avoid it. Just add a unique id to the table:
CREATE TABLE user_cars (
user_car_id serial primary key,
user_id int REFERENCES users (id) ON DELETE CASCADE,
car CHARACTER VARYING(255) NOT NULL,
CONSTRAINT test UNIQUE (user_id, car)
);
Then mappings is simply:
CREATE TABLE mappings (
mapping_id serial primary key,
user_car_id int references user_cars(user_car_id) on delete cascade,
other_id CHARACTER(9) REFERENCES other (id) ON DELETE CASCADE,
);
If car should be unique, add UNIQUE constrain only on car column.
If user should be unique, add UNIQUE constrain only on user column.
If you add UNIQUE constrain on combination, then there will be duplicate values in the table.
UPDATE:
You can add multiple constraints on single column. With Foreign key add UNIQUE constraint as well on user_cars column in mapping table.
For a store I have many store_offers which is a one-to-many relationship.
However, for a table
create table store (
id bigserial primary key
);
I can use a single primary key id (SQLfiddle):
create table store_offer (
id bigserial primary key,
store_id bigint not null,
constraint fk__store_offer__store
foreign key (store_id)
references store(id)
);
or a composite primary key (id, store_id) (SQLFiddle):
create table store_offer (
id bigserial not null,
store_id bigint not null,
constraint fk__store_offer__store
foreign key (store_id)
references store(id),
primary key(id, store_id)
);
My question is "what does make more sense here?". Imho the composite key should be the correct way to do it since a store_offer is actually "bound" to as store. But one can argue that this is already the case since the first version has a foreign key. On the other hand a store_offer primary key actually must not change once it's created. You have to create a new store_offer and delete the old one if you want discard one. But you cannot simply change store_id in the second approach.
So what is the correct answer here?
Using primary key(id, store_id) is a bad idea. This will make many queries more complicated and more prone to error. It sounds like what you are really trying to make is a many-to-many relationship between stores and offers. If this is the case you should have a store table with unique store_id as a primary key, an offer table with unique offer_id as a primary key and a store_offer table that has a primary key of store_id and offer_id.
I am creating a table that has two values that are both primary and foreign at the same time. I do not know how to create them in SQL. Here is what I did but I get the error, there must only be one primary key. what is the correct way?
CREATE TABLE movie_director(
director_id CHAR(8)
constraint pk_director_id_movie_director
PRIMARY KEY
constraint fk_director_id_movie_director
REFERENCES director,
movie_id VARCHAR(30)
constraint pk_movie_id_movie_director
PRIMARY KEY
constraint fk_movie_id_movie_director
REFERENCES movie
)
What you seem to be looking for is a compound primary key. Change your table definition to something like the following:
CREATE TABLE movie_director(
director_id CHAR(8)
constraint fk_director_id_movie_director
REFERENCES director,
movie_id VARCHAR(30)
constraint fk_movie_id_movie_director
REFERENCES movie,
CONSTRAINT PK_MOVIE_DIRECTOR
PRIMARY KEY (DIRECTOR_ID, MOVIE_ID));
Your error seems pretty clear. There can only be one PRIMARY KEY on a table.
You need to create a COMPOUND PRIMARY KEY which consists of two columns (director_id,movie_id).
From wikipedia:
In database design, a compound key is a key that consists of two or more attributes that uniquely identify an entity occurrence.
Is it possible to have a foreign key that references another foreign key in a different table, or can it only reference primary and unique keys?
A foreign key can reference any field defined as unique. If that unique field is itself defined as a foreign key, it makes no difference. A foreign key is just to enforce referential integrity. Making a field a foreign key doesn't change the field itself in any way. If it is a unique field, it can also be the target of another FK.
For example:
create table Table1(
PK int identity primary key,
...
);
create table Table2( -- 1-1 relationship with Table1
PKFK int primary key,
...,
constraint FK_Table2_1 foreign key( PKFK ) references Table1( PK )
);
create table Table3( -- relates to Table2
PKFKFK int primary key,
...,
constraint FK_Table3_2 foreign key( PKFKFK ) references Table2( PKFK )
);
I know of no DBMS where this is not the case. And I agree with Horse, there is nothing wrong with the practice.
Is it possible to have a foreign key that references another foreign key in a different table
Yes. In fact contrary to accepted answer, the referenced FK column doesn't even have to be unique! - at least in MySQL. see https://www.db-fiddle.com/f/6RUEP43vYVkyK2sxQQpBfj/0 for a demo of the same.
which brings up the question that if the FK is not unique in the parent table, then who is the parent row? The purpose of FKs is to establish parent-child relationship.