Is it possible to auto increment a column in SQL Server WITHOUT it being a primary key?
If yes how can this be done.
Thanks
Yes. There is no requirement that IDENTITY columns be made a primary key.
CREATE TABLE T
(
X INT PRIMARY KEY,
Y INT IDENTITY(1,1)
)
Though I'm not sure when this would be useful. If you have a natural key that you want to use as the PK then you would probably want to put a unique constraint on the surrogate alternate key anyway.
For purposes of setting up FK relationships SQL Server doesn't care if the column(s) is the PK or not it just requires a unique index on it/them.
Declare the column with the IDENTITY keyword, and simply do not create a PRIMARY KEY constraint on it.
Related
In my table I have a self increment identity key but its not primary. If alter this key to make it primary also, in an existing table will it cause any problems?
No its pretty safe. Use:
alter table create primary key (column_name)
In some ways this question follows on from this one. One of the injunctions in the MariaDB documnetation suggests that having tables on a clustered database without a primary key is not desirable. In my application I have as a rule been using one UNIQUE key (VARCHAR(8)) per table with no PRIMARY key. My understanding is that a PRIMARY key is merely a special kind of UNIQUE key. Question - is the current UNIQUE key usage adequate for keeping MariaDB Galera happy or do I explciitly need to convert my UNIQUEs to PRIMARYs? On the face of it this does not make much sense to me but perhaps there are reasons for doing so?
In the absence of a PRIMARY key, InnoDB/XtraDB will first try to use a UNIQUE index. If neither exist it will make up an internal primary key that is not reliable between galera nodes.
You are correct that a PRIMARY key is basically a UNIQUE index with the only difference being that there can only be one PRIMARY key. It is also used for the physical layout of the data but that isn't as important here.
As long as there is only one UNIQUE index, you should be fine. However, I don't think it would be reliable if you add another UNIQUE index. Because of that and for good practice, you should probably make that UNIQUE index the PRIMARY key.
a PRIMARY KEY require that the column is NOT NULL
in the table CREATE TABLE p (a INT, b INT, UNIQUE (a)); you can have 2 rows where a IS NULL.
in the table CREATE TABLE p2 (a INT, b INT, PRIMARY KEY (a)); the a column automaticly becomes a NOT NULL column.
SHOW CREATE TABLE p2;
CREATE TABLE `p2` (
`a` int(11) NOT NULL DEFAULT '0',
`b` int(11) DEFAULT NULL,
PRIMARY KEY (`a`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1
I have a table
documents
(
year int not null,
number int not null,
document_types_id int not null,
...
)
The primary key is year + number + document_types_id.
I think that a better primary key would be year + document_types_id + number. Is there a way to reorder this composition (not columns in table, PK and FK combination) without deleting and recreation of PK, because this PK is used as a FK in many other tables.
Thanks.
Your foreign keys are referencing your primary key, so your foreign keys are 3-dimensional (year + number + document_types_id). If you are going to get rid of a dimension then even if you try to modify your primary key your constraints will tell you that you can't get rid of the given column, so you should handle your foreign keys first and then you can modify your primary key. Steps:
Write all your foreign keys into a list to enable you to know which were the foreign keys before.
Get rid of all the foreign keys referencing your primary key
Modify/recreate your primary key
Recreate your foreign keys according to the new version of your primary key.
You have to drop the primary key first to alter it later. Otherwise you get a message, that there can't be two primary keys on one table.
But that's no problem, just do
Alter Table myTable NOCHECK Constraint All
then alter your tables as you like, then do
Alter Table myTable CHECK Constraint ALL
and you're fine.
The equivalent in MySQL would be:
SET FOREIGN_KEY_CHECKS = 0;
and
SET FOREIGN_KEY_CHECKS = 1;
If dropping the FK on other tables is a problem, then you can create a non-clustered index with those columns in that order and provide hints (WITH INDEX(ALTER TABLE syntax leaves no scope for an ALTER CONSTRAINT statement.
No. In the relational model, there is no meaningful ordering to the attributes in a key. But in SQL, there is. The correspondence of columns of a foreign key, to the columns of the primary or unique key the FK references, is by ordinal position, not by name.
So the ordering of the columns in the key declaration is meaningful, and if that meaning/ordering is currently used effectively, then you cannot change it without breaking the current use.
Besides. That the theory attaches no meaning to the ordering of the key attributes/columns, is not without reason. What exactly do you think is "better" with your "re-ordered" key, compared to the existing one ?
I have about 5000 records in a table in SQL Server 2008
I need to add a primary key. I don't care what it is, maybe an autonumber would be best?
How do I add a primary key to every record ?
I also would like this primary key to be generated automatically when I add new rows!
Try this:
ALTER TABLE myTable ADD id INT IDENTITY
CONSTRAINT id _pk PRIMARY KEY;
I am aware of Oracle's create table syntax
CREATE TABLE MyTable(
id int primary key,
...
);
This will create a table called MyTable with an int primary key. So, nothing new here.
but I am having difficulties understanding the following query:
CREATE TABLE departament (
cod_dept INTEGER CONSTRAINT dept_key PRIMARY KEY,
dept_name CHAR(15) NOT NULL,
admission DATE NOT NULL,
localization CHAR(20))
When I look up on Oracle's SQL Developer software on departement's table, I can see 4 columns: cod_dept, dept_name, admission and localization. On the constraints tab, I can also see dept_key, but I am confused as to what this might mean. What is dept_key purpose here?
Edit
Ok, seems it is a way to define the name of the constraint you're adding to the table. My next question is why don't you just call it the same name as the primary key column? From what I've seen it seems Oracle by default just creates a random name for the constraint!
Thanks
When you write id int primary key, Oracle will create a primary key constraint to ensure uniqueness of primary key values. All constraints have names, so in this case Oracle assigns an autogenerated name to this constraint. But you can set a name of this constraint explicitly using the CONSTRAINT syntax:
cod_dept INTEGER CONSTRAINT dept_key PRIMARY KEY
This name may be used later to refer to the constraint, for example, to delete or modify it:
ALTER TABLE department DROP CONSTRAINT dept_key;
EDIT:
Constraint names are unique across the schema, so Oracle can't just use the name of primary key column as a constraint name.
Primary keys can be explicitly be named. dept_key is just a name.
dept_key is the name of the primary key constraint. That means cod_dept is the unique identifier for your table, the mechanism for identifying a row, and so it can only have one occurrence of any given value.
That is the constraint you created representing the primary key.
A table is made up of:
Columns (where the data lives)
Indexes (indexed copies of the data used for faster searching)
Constraints (rules about what data can be in the table, including PK, FK, and check constraints).
dept_key is the name of the constraint. You specified the name here : "INTEGER CONSTRAINT dept_key PRIMARY KEY," so it will create a constraint with the name dept_key.
Another syntax for the same would be to write the following after your CREATE TABLE instruction.
ALTER TABLE department
ADD CONSTRAINT dept_key PRIMARY KEY (cod_dept)
dept_key is then the name of the constraint you created to be the primary key for this table. In order for a database engine to know the primary key, and to index it for fastest results and so forth, it needs to create a known constraint that is indexed. Here, it is you who has given the name which is dept_key.
For you kind information, it is often seen to write PK_[table name] for primary keys constraints and FK_[current_table_name]_[foreign_table_name] for foreign keys constraints.
Hope this helps! =)
I think whenever we create a Primary Key value then by default Oracle will crate constraint for it with the same name but it looks like that u are creating constraint with some other name.
Thank You