I have a table with 2 primary key columns : ID and StudentID.
ID column is set to isIdentity = Yes with auto increment.
I've tested it multiple times before, but for some reason this time, when I insert a duplicate value on StudentID, it does not throw the error but instead added it on to the database. 2 of the same values are displayed when I show the table data.
What can be the problem here?
You have a compound primary key on ID and StudentID. That means you the combination of ID and StudentID together must be unique. Since ID is an identity column that combination of ID and StudentID will always be unique (because ID is already unique on its own).
You can change the primary key to be on ID only. Then you can add a unique index on StudentID. For example:
create unique index idx_studentID on yourTable(StudentID)
That will insure that the StudentID column, in fact, contains only unique values.
It seems like you may not actually need ID column, but that's a little wider discussion than your original question.
You can't have 2 "primary keys". You can have a compound primary key (meaning the combination needs to be unique, which is what it sounds like you have now. Or, You can have one "primary" key and one "unique" constraint which is what it sounds like you want.
You cannot have 2 Primary Keys. You can have multiple Unique Keys if needed, which should help you in your case. Make sure to go back to your table creation and double check which column is your Primary Key and work from there.
Do not mix up identity, primary key and unique key.
Any table can have identity key which you can setup on table. Here seed can be say 1, then increment it by 1. So incremental order will like 1,2,3...and so on.
Primary key, one can define on specific column of the table. Identity key can be used as primary key. But you can have identity column as well primary key on same table. Primary key is one and only for the table.So if you are treating identity as primary key, then you will have no further table column as primary key.
Unique key, can be more than one column with your table.
While fetching rows from table data, if you provide combination of identity key, primary key and unique key then search will be fastest
During my first response, I have mentioned that one can generate identity column by soft coding and it will not be treated as primary key.Following is syntax one can use while creating table.
1] If one wish to set identity column as primary key
--id int identity(1,1) primary key
2] If one doesn't wish to set identity column as primary key and still wish
to us identity column then donot us word primary key for identity column.
--id int identity(1,1)
In this 2] case scenario, one may create primary key on other table column.
Related
One of the values to be inserted into a table is a foreign key. I need to figure out how to, inside the CHECK clause, check if a value in another table is equal to a specific value using the foreign key (which is unique in the other table).
Example Diagram
As an example, the MonkeySpecies table has a unique primary key. I need to make it so that the Monkey table can only be added to if the SpeciesID in the MonkeySpecies table is not 'extinct'.
I would like to ask in which cases its proper to use UNIQUE keyword in SQL. I know that if I declare a column as a primary key has uniqueness on its own but what happens with other attributes like country? Is it proper to use a unique constraint there?
The unique keyword in sql is used whenever you want each and every row entry of that column to be different from each other. A primary key column is automatically unique but there are some cases in which you may want more columns to be unique.
For example if you have a product_id as primary key it will ensure that no other row will have a product with product_id as that row. And in addition to that, you want that no two rows should have the same product_imei, then you can make the product_imei unique.
You can make a composite primary key like Primary Key(column1,column2) but that will mean that the combination you get from product_id and product_imei will be unique.
For example
(DLK-22,356938035643809) and (DLK-22, 11111111111111) both can exist in a table if (product_id,product_imei) is the primary key.
So you can use a unique constraint on as much columns as you like and its need depends on the scenario of the problem you are facing. You can use the unique constraint with the country if that helps you, there is no problem in doing so
The UNIQUE constraint ensures that all values in a column are different. Both the UNIQUE and PRIMARY KEY constraints provide a guarantee for uniqueness for a column or set of columns. A PRIMARY KEY constraint automatically has a UNIQUE constraint.
As any other constraint the UNIQUE constraint enforces some level of data quality. If you add this constraint to a column, then all values on that column will be different.
For example, on a table where EMPLOYEE_PK is already unique (because it's the PK) you may want to enforce the CARD_NUMBER column is also unique; that's the number displayed on the employee card. In your model the card number may be different from the PK, and you may also need to make sure it's unique.
Another extra benefit of a UNIQUE constraint is that other tables can link foreign keys to it. Since a UNIQUE column effectively acts as a "table key", any other table can establish a foreign key pointing to it. I've met many people who [wrongly] think that foreign keys can only point to primary keys.
I would like to add an autoincrementing integer field called uid to an existing table assoc, but it doesn't look like I can do that unless it's a primary key.
I have fields local_id and remote_id which are the existing primary key pair, and I do that so that I can INSERT OR IGNORE INTO assoc so that I don't get duplicate primary keys, but if I have a pair of columns as a primary key, I can't seem to use them as an update (see other SO question).
Could anyone suggest how to restructure the table (and implement that restructuring using ALTER TABLE) so that I can get the behavior I need:
a single autoincrementing key, so I can use that for UPDATEs
a pair of fields local_id and remote_id so that the pair (local_id, remote_id) remains unique in the table
In this case, you could drop the primary key on your existing columns, create the new primary key integer autoincrementing column, then create a UNIQUE index on the other two columns.
Aha, I don't need to -- there's a builtin rowid column.
CREATE TABLE Orders
-> (
-> ID SMALLINT UNSIGNED NOT NULL,
-> ModelID SMALLINT UNSIGNED NOT NULL,
-> Descrip VARCHAR(40),
-> PRIMARY KEY (ID, ModelID)
-> );
Basically, this appears to me to be creating two primary key on one table. Is that correct?
I thought that we could create a number of unique keys in one table, but only one primary key.
How is it that my system is allowing the creation of multiple primary keys?
Please advise: what are the rules governing this?
Your system is not allowing multiple primary keys - it is creating the key based on 2 columns (ID, ModelID)
Think of it like it suggest, a 'KEY'. So the key would be all of the columns specified. In your case you can have multiple rows with the same 'ID' and multiple rows with the same 'ModelID' but there shall never be two rows that have the same 'ID' AND 'ModelID'.
So in this case it is not saying that the column 'ID' must be unique nor is it saying that 'ModelID' must be unique, but only the combination.
You are making 1 primary key. But that key is a combination of 2 values.
Which is not a wrong thing to do. But in your case it does look wrong.
You seem to have a primary key named ID and a foreign key named ModelID. You should probable have an index on the ModelID, and a primary key constraint on the ID
You can have one primary key (thats why it is called the primary key)
You can have multiple UNIQUE keys if you like.
Hoping someone can shed some light on this: Do lookup tables need their own ID?
For example, say I have:
Table users: user_id, username
Table categories: category_id, category_name
Table users_categories: user_id, category_id
Would each row in "users_categories" need an additional ID field? What would the primary key of said table be? Thanks.
You have a choice. The primary key can be either:
A new, otherwise meaningless INTEGER column.
A key made up of both user_id and category_id.
I prefer the first solution but I think you'll find a majority of programmers here prefer the second.
You could create a composite key that uses the both keys
Normally if there is no suitable key to be found in a table you want to create a either a composite key, made up of 2 or more fields,
ex:
Code below found here
CREATE TABLE topic_replies (
topic_id int unsigned not null,
id int unsigned not null auto_increment,
user_id int unsigned not null,
message text not null,
PRIMARY KEY(topic_id, id));
therefor in your case you could add code that does the following:
ALTER TABLE users_categories ADD PRIMARY KEY (user_id, category_id);
therefor once you want to reference a certain field all you would need is to pass the two PKs from your other table, however to link them they need to each be coded as a foreign key.
ALTER TABLE users_categories ADD CONSTRAINT fk_1 FOREIGN KEY (category_id) REFERENCES categories (category_id);
but if you want to create a new primary key in your users_categories table that is an option. Just know that its not always neccessary.
If your users_categories table has a unique primary key over (user_id, category_id), then - no, not necessarily.
Only if you
want to refer to single rows of that table from someplace else easily
have more than one equal user_id, category_id combination
you could benefit from a separate ID field.
Every table needs a primary key and unique ID in SQL no matter what. Just make it users_categories_id, you technically never have to use it but it has to be there.