I have the following three sample tables (simplified demo for purpose of question):
CREATE TABLE Teams
(
Id int IDENTITY(1,1) NOT NULL,
Name varchar(50) NOT NULL,
PRIMARY KEY (Id)
)
CREATE TABLE TeamGroups
(
Id int NOT NULL,
TeamId int NOT NULL,
PRIMARY KEY (Id,TeamId)
)
CREATE TABLE RoomBookings
(
Id int NOT NULL,
TeamGroupId int NOT NULL,
RoomId int NOT NULL,
PRIMARY KEY (Id)
)
and I have the following foreign key already set up:
ALTER TABLE TeamGroups WITH CHECK
ADD CONSTRAINT [FK_TeamGroups_Teams]
FOREIGN KEY (TeamId) REFERENCES Teams(Id)
The idea is that each Team can be in zero or more TeamGroups, and each TeamGroup can have zero or more RoomBookings
To reflect that, I want to add a foreign key from the RoomBookings table into the TeamGroups table.
I tried using the Relationships GUI in Management Studio to create the foreign key (primary key table: TeamGroups.ID, foreign key table: RoomBookings.TeamGroupId) but I get an error:
The columns in table 'TeamGroups' do not match an existing primary key
or UNIQUE constraint
I'm assuming it's because the TeamGroups table has a two-column primary key?
I don't really want to make a foreign key constraint from the TeamGroups table (eg, the key is present in the TeamGroups table), as the table will eventually be used by other tables (such as EquipmentBookings, GroupManagers, etc).
Any help?
If your primary key is made up from more than one columns, then all foregin keys also must have all those columns - there's no way around this.
But I don't understand why you'd get this error trying to link TeamGroups to Team based on the Team.Id column.... that should work just fine.
Try using this:
ALTER TABLE TeamGroups WITH CHECK
ADD CONSTRAINT [FK_TeamGroups_Teams]
FOREIGN KEY (TeamId) REFERENCES Teams(Id);
You had Teams (which is not a valid column in TeamGroups at all), and you had REFERENCES Teams.id which is wrong - it needs to be REFERNCES Teams(Id); (column in parenthesis - not the "dot" notation)
Update: from TeamGroups to RoomBookings - yes.... either use both columns from TeamGroups in your RoomBookings table - or what would stop you from making the TeamGroups.Id column an INT IDENTITY and then have the PK on just this one column?? Any good reason for that??
CREATE TABLE TeamGroups
(
TeamGroupId int NOT NULL,
TeamId int NOT NULL,
PRIMARY KEY (TeamGroupId)
)
ALTER TABLE dbo.RoomBookings
ADD CONSTRAINT FK_RoomBookings_TeamGroup
FOREIGN KEY TeamGroupId REFERENCES TeamGroups(TeamGroupId)
For instance, if I have a students table:
CREATE TABLE student (
student_id NUMBER(8),
student_name VARCHAR2(30),
CONSTRAINT pk_student PRIMARY KEY (student_id)
);
And a subject table:
CREATE TABLE subject (
subject_id NUMBER(8),
subject_name VARCHAR2(30),
CONSTRAINT pk_subject PRIMARY KEY (subject_id)
);
And then I create a third table of student's favorites subjects:
CREATE TABLE fav_sub (
student_id NUMBER(8),
subject_it NUMBER(8),
CONSTRAINT pk_fav_sub PRIMARY KEY (student_id, subject_id),
CONSTRAINT fk_1_fav_sub FOREIGN KEY (student_id) REFERENCES student(student_id),
CONSTRAINT fk_2_fav_sub FOREIGN KEY (subject_id) REFERENCES subject(subject_id)
);
Do I then need to manually create indexes for the foreign keys in the fav_sub table such as:
CREATE INDEX in_1_fav_sub ON fav_sub(student_id);
CREATE INDEX in_2_fav_sub ON fav_sub(subject_id);
Or are the indexes for the foreign keys automatically created by the database, since they're part of the composite key?
Edit: Just to clarify, I'm not asking if an index for a foreign key is automatically created, I'm asking if an index for a foreign key is created WHEN it's part of a composite key, since Oracle automatically indexes primary keys.
The creation of the primary key indexes the combination of [student_id, subject_id]. Adding foreign key constraints to each individual column does not create an index on them, and if you want it (which is probably a good idea), you'd have to manually create it.
What is the best way to make a simple many-to-many cross reference table which contains nothing but two columns which are themselves primary keys in other tables?
Does anyone have concrete evidence for or against creating a table with a single unique index, but no primary key? (Alternatives are detailed below).
Put another way: How does SQL Server internally uniquely identifies rows a) that have a primary key and b) that do not have a primary key?
In detail:
Given the input tables:
CREATE TABLE Foo ( FooID bigint identity(1,1) not null primary key, other stuff... )
CREATE TABLE Bar ( BarID bigint identity(1,1) not null primary key, other stuff... )
The three basic options are (in all cases assume a foreign key is created on the FooID and BarID columns):
-- Option 1: Compound primary key
CREATE TABLE FooBarXRef (
FooID bigint not null
, BarID bigint not null
, PRIMARY KEY ( FooID, BarID )
, CONSTRAINT FK... etc
)
-- Option 2: Independent primary key + unique index
CREATE TABLE FooBarXRef (
FooBarXRefID bigint identity(1,1) not null primary key
, FooID bigint not null
, BarID bigint not null
, CONSTRAINT FK... etc
);
CREATE UNIQUE INDEX I_FooBarXRef_FooBar ON FooBarXRef ( FooID, BarID );
-- Option 3: Unique index, no explicit primary key:
CREATE TABLE FooBarXRef (
FooID bigint not null
, BarID bigint not null
, CONSTRAINT FK... etc
);
CREATE UNIQUE INDEX I_FooBarXRef_FooBar ON FooBarXRef ( FooID, BarID );
Does having a separate identity PK on the xref table to be redundant; that may needlessly introduces another layer of constraint checking on the database engine?
On the other hand are multi-column primary keys problematic? With a proposed solution to have the xref table contain only the two foreign keys, and define a unique index on those columns, but not define a primary key at all... ?
I suspect that doing so will cause SQL Server to create an internal primary key for the purposes of uniquely identifying each row, thus yielding the same redundant constraints as if a primary key were defined explicitly--but I have no proof or documentation to support this. Other questions and answers suggest that there is not an internal primary key by default (i.e. no equivalent to the Oracle ROWID); as the %%physloc%% is an indicator of where a row is currently stored and thus is subject to change. My intuition is that the engine must create something to uniquely identify a row in order to implement cursors, transactions, and concurrency.
The concept of a primary key is really about relational theory; maintaining referential integrity by building relationships across multiple tables. The SQL Server engine, by default, creates a unique clustered index when a primary key is built (assuming a clustered index doesn't exist at the moment).
It's this clustered index that defines a unique row at the leaf level. For tables that have a non-unique clustered index, SQL Server creates a 4byte "uniquifier" to to the end of your key.
TestTable1 Primary Key
TestTable2 Primary Key & Unique Non-Clustered
TestTable3 Unique Clustered
TestTable4 Primary Clustered (same as Table1 & Table3, since a primary key CAN be defined on a non-clustered index I prefer this to always define which structure I want).
TestTable2 is redundant, it's create a unique clustered index to store all the records at it's leaf level. It's then creating a unique non-clustered index to enforce uniqueness once again. Any changes on the table will hit the clustered and then the non-cluster.
TestTable1, TestTable3, TestTable4 are a tie in my book, a unique clustered index structure is created on all. There is no physical difference in the way records are stored on a page.
However for SQL Server Replication, all replicated tables required a primary key. If your'll be using Replication in the future you may want to make sure all your unique clustered indexes are primary keys as well.
I seem to be unable to paste in my verifying scripts, so here they are on hastebin.
http://hastebin.com/qucajimixi.vbs
Well, it all depends on the requirement. As far as I know
PRIMARY KEY= UNIQUE KEY+NOT NULL key
What this tells you is that you can have multiple
NOT NULL UNIQUE INDEXES(NON CLUSTERED)
but
CANNOT HAVE MULTIPLE PRIMARY KEYS IN A TABLE( CLUSTERED).
I am a huge believer of Relational database model and working with the PRIMARY-FOREIGN KEYS relationships. DB replication requires you to have Primary Key on a table ; therefore, it is always a good practice to create Primary Key instead of UNIQUE keys for your table.
I have two tables, Table JOB and Table USER, here is the structure
CREATE TABLE JOB
(
ID NUMBER NOT NULL ,
USERID NUMBER,
CONSTRAINT B_PK PRIMARY KEY ( ID ) ENABLE
);
CREATE TABLE USER
(
ID NUMBER NOT NULL ,
CONSTRAINT U_PK PRIMARY KEY ( ID ) ENABLE
);
Now, i want to add foreign key constraint to JOB referencing to USER table, as
Alter Table JOB ADD CONSTRAINT FK_USERID FOREIGN KEY(USERID) REFERENCES USER(ID);
this throws Oracle (ORA-02270) : no matching unique or primary key for this column-list error, doing some investigation it appears that we need to have either unique key or primary key constraint on USERID but I cannot have that as one USERID can have multiple JOBS associated with him, any thoughts or suggestions on how to fix this issue?
Researched ORA-02270 and SO related question
The ORA-2270 error is a straightforward logical error: it happens when the columns we list in the foreign key do not match a primary key or unique constraint on the parent table. Common reasons for this are
the parent lacks a PRIMARY KEY or UNIQUE constraint altogether
the foreign key clause references the wrong column in the parent table
the parent table's constraint is a compound key and we haven't referenced all the columns in the foreign key statement.
Neither appears to be the case in your posted code. But that's a red herring, because your code does not run as you have posted it. Judging from the previous edits I presume you are not posting your actual code but some simplified example. Unfortunately in the process of simplification you have eradicated whatever is causing the ORA-2270 error.
SQL> CREATE TABLE JOB
(
ID NUMBER NOT NULL ,
USERID NUMBER,
CONSTRAINT B_PK PRIMARY KEY ( ID ) ENABLE
); 2 3 4 5 6
Table created.
SQL> CREATE TABLE USER
(
ID NUMBER NOT NULL ,
CONSTRAINT U_PK PRIMARY KEY ( ID ) ENABLE
); 2 3 4 5
CREATE TABLE USER
*
ERROR at line 1:
ORA-00903: invalid table name
SQL>
That statement failed because USER is a reserved keyword so we cannot name a table USER. Let's fix that:
SQL> 1
1* CREATE TABLE USER
SQL> a s
1* CREATE TABLE USERs
SQL> l
1 CREATE TABLE USERs
2 (
3 ID NUMBER NOT NULL ,
4 CONSTRAINT U_PK PRIMARY KEY ( ID ) ENABLE
5* )
SQL> r
1 CREATE TABLE USERs
2 (
3 ID NUMBER NOT NULL ,
4 CONSTRAINT U_PK PRIMARY KEY ( ID ) ENABLE
5* )
Table created.
SQL> Alter Table JOB ADD CONSTRAINT FK_USERID FOREIGN KEY(USERID) REFERENCES USERS(ID);
Table altered.
SQL>
And lo! No ORA-2270 error.
Alas, there's not much we can do here to help you further. You have a bug in your code. You can post your code here and one of us can spot your mistake. Or you can check your own code and discover it for yourself.
Note: an earlier version of the code defined HOB.USERID as VARCHAR2(20). Because USER.ID is defined as a NUMBER the attempt to create a foreign key would have hurl a different error:
ORA-02267: column type incompatible with referenced column type
An easy way to avoid mismatches is to use foreign key syntax to default the datatype of the column:
CREATE TABLE USERs
(
ID number NOT NULL ,
CONSTRAINT U_PK PRIMARY KEY ( ID ) ENABLE
);
CREATE TABLE JOB
(
ID NUMBER NOT NULL ,
USERID constraint FK_USERID references users,
CONSTRAINT B_PK PRIMARY KEY ( ID ) ENABLE
);
The data type in the Job table (Varchar2(20)) does not match the data type in the USER table (NUMBER NOT NULL).
In my case the problem was cause by a disabled PK.
In order to enable it:
I look for the Constraint name with:
SELECT * FROM USER_CONS_COLUMNS WHERE TABLE_NAME = 'referenced_table_name';
Then I took the Constraint name in order to enable it with the following command:
ALTER TABLE table_name ENABLE CONSTRAINT constraint_name;
We have the following script for create a new table:
CREATE TABLE new_table
(
id NUMBER(32) PRIMARY KEY,
referenced_table_id NUMBER(32) NOT NULL,
CONSTRAINT fk_new_table_referenced_table_id
FOREIGN KEY (referenced_table_id)
REFERENCES referenced_table (id)
);
and we were getting this error on execution:
[42000][2270] ORA-02270: no matching unique or primary key for this
column-list
The issue was due to disabled primary key of the referenced table in our case. We have to enable it using the following sql:
ALTER TABLE referenced_table ENABLE PRIMARY KEY USING INDEX;
after that we created new table using first script without any issues
The scheme is correct, User.ID must be the primary key of User, Job.ID should be the primary key of Job and Job.UserID should be a foreign key to User.ID. Also, your commands appear to be syntactically correct.
So what could be wrong? I believe you have at least a Job.UserID which doesn't have a pair in User.ID. For instance, if all values of User.ID are: 1,2,3,4,6,7,8 and you have a value of Job.UserID of 5 (which is not among 1,2,3,4,6,7,8, which are the possible values of UserID), you will not be able to create your foreign key constraint. Solution:
delete from Job where UserID in (select distinct User.ID from User);
will delete all jobs with nonexistent users. You might want to migrate these to a copy of this table which will contain archive data.
Most Probably when you have a missing Primary key is not defined from parent table. then It occurs.
Like Add the primary key define in parent as below:
ALTER TABLE "FE_PRODUCT" ADD CONSTRAINT "FE_PRODUCT_PK" PRIMARY KEY ("ID") ENABLE;
Hope this will work.
I faced the same issue in my scenario as follow:
I created textbook table first with
create table textbook(txtbk_isbn varchar2(13)
primary key,txtbk_title varchar2(40),
txtbk_author varchar2(40) );
Then chapter table:
create table chapter(txtbk_isbn varchar2(13),chapter_title varchar2(40),
constraint pk_chapter primary key(txtbk_isbn,chapter_title),
constraint chapter_txtbook foreign key (txtbk_isbn) references textbook (txtbk_isbn));
Then topic table:
create table topic(topic_id varchar2(20) primary key,topic_name varchar2(40));
Now when I wanted to create a relationship called chapter_topic between chapter (having composite primary key) and topic (having single column primary key), I faced issue with following query:
create table chapter_topic(txtbk_isbn varchar2(13),chapter_title varchar2(40),topic_id varchar2(20),
primary key (txtbk_isbn, chapter_title, topic_id),
foreign key (txtbk_isbn) references textbook(txtbk_isbn),
foreign key (chapter_title) references chapter(chapter_title),
foreign key (topic_id) references topic (topic_id));
The solution was to refer to composite foreign key as below:
create table chapter_topic(txtbk_isbn varchar2(13),chapter_title varchar2(40),topic_id varchar2(20),
primary key (txtbk_isbn, chapter_title, topic_id),
foreign key (txtbk_isbn, chapter_title) references chapter(txtbk_isbn, chapter_title),
foreign key (topic_id) references topic (topic_id));
Thanks to APC post in which he mentioned in his post a statement that:
Common reasons for this are
- the parent lacks a constraint altogether
- the parent table's constraint is a compound key and we haven't referenced all the columns in the foreign key statement.
- the referenced PK constraint exists but is DISABLED
When running this command:
ALTER TABLE MYTABLENAME MODIFY CONSTRAINT MYCONSTRAINTNAME_FK ENABLE;
I got this error:
ORA-02270: no matching unique or primary key for this column-list
02270. 00000 - "no matching unique or primary key for this column-list"
*Cause: A REFERENCES clause in a CREATE/ALTER TABLE statement
gives a column-list for which there is no matching unique or primary
key constraint in the referenced table.
*Action: Find the correct column names using the ALL_CONS_COLUMNS
The referenced table has a primary key constraint with matching type. The root cause of this error, in my case, was that the primary key constraint was disabled.
Isn't the difference between your declaration of USERID the problem
JOB: UserID is Varchar
USER: UserID is Number?
If primary key is not already defined on parent table then this issue may arise. Please try to define the primary key on existing table.
For eg:
ALTER TABLE table_name
ADD PRIMARY KEY (the_column_which_is_primary_key);
create table articles(code varchar2(30)constraint articles_pk primary key,titre varchar2(30),
support varchar2(30) constraint support_fk references supports(support),type_support varchar2(30),
numeroDePage varchar2(30),datepublication date,categorie varchar2(30)constraint categorie_fk references organismes(categorie),
tendance varchar2(30)constraint tendance_fk references apreciations(tendance));
create table date_dimension (
id serial primary key,
date_id date,
..... others
);
create table temp (
id serial primary key,
from_date integer,
to_date integer,
value integer,
foreign key (from_date, to_date) references date_dimension(id, id)
);
How can I refer both from_date and to_date to id field in date_dimension?
The current code fails to do that saying
ERROR: there is no unique constraint matching given keys for referenced table "date_dimension"
Thank you
each FOREIGN KEY constraint added to a table will always relate one row in the referencing table to one row* in the referant. If you want to have each row in the referencing to refer to two distinct rows in the referant, you need two, separate foreign key constraints.
you want:
foreign key (from_date) references date_dimension(id)
foreign key (to_date) references date_dimension(id)
You almost always want to have exactly the rows in the foreign key to be the same as the primary key in the referant.
* Actually, there may be more than one row in the referant if the foreign key is smaller than a candidate key of the referant. this is seldom useful, though, and almost certainly unrelated to the problem you're describing