In one of our tables there is an existing non-clustered Primary Key on a UNIQUEIDENTIFIERcolumn, heavily used in FKs.
We now want to add an IDENTITY column and create a unique clustered index for this.
I do not need an explanation of clustered vs. non-clustered or about "what is a primary key?".
I want to
drop all indexes
add the new column with IDENTITY
create the unique clustered index on the new column
re-create all indexes
My question are:
Will the new clustered index be used as look up key?
Will the Primary Key use the clustered key?
What implications could be, using a clustered key and a non-clustered PK side by side?
Thank you!
Will the new clustered index be used as look up key?
Yes the clustered key will be the look up key.
Will the Primary Key use the clustered key?
Yes primary key always has a clustered index attached to it.
What implications could be, using a clustered key and a non-clustered PK side by side?
This depends on the usage of your table and the associated columns.
Related
I'm setting up a partitioned by hash table in PostgreSQL 12 which will have 256 partitions. I'm using uuid as my primary key for the table. Is it acceptable to use the same uuid column as the hash key?
Not only acceptable, but required.
Per the docs, 11.6. Unique Indexes
"PostgreSQL automatically creates a unique index when a unique constraint or primary key is defined for a table. The index covers the columns that make up the primary key or unique constraint (a multicolumn index, if appropriate), and is the mechanism that enforces the constraint."
Also per the docs, 5.11.2.3. Limitations,
The following limitations apply to partitioned tables:
"Unique constraints on partitioned tables must include all the partition key columns. This limitation exists because PostgreSQL can only enforce uniqueness in each partition individually."
From https://stackoverflow.com/a/51087864/3284469
primary keys can be primary indices.
Must the search key of a primary index be or related to a primary key ? Will the answer be different in PostgreSQL and other DBMS? Thanks.
Postgres doesn't have "primary index", all indexes are implemented the same way, and point directly to the data rows.
Must the search key of a primary index be or related to a primary key
It must be a search on the expression used to form the primary index.
if the primary index is constrained to be an index on the primary key then yes else no.
Will the answer be different in PostgreSQL and other DBMS?
yes, because postgresql does not have primary index. although a clustered index is a bit like a primary index. the clustered index can be an index on on any expression, it need not reference the primary key at all.
with postgreql there is no requirement that a table have any index. but if you want to define relations between tables then indexes are required.
TL;DR
I am seeking clarity on this: does a FOREIGN KEY require a UNIQUE CONSTRAINT on the other side, specifically, in Postgres and, generally, in relational database systems?
Perhaps, I can test this, but I'll ask, if the UNIQUE CONSTRAINT is required by the FOREIGN KEY what would happen if I don't create it? Will the Database create one or will it throw an error?
How I got there
I had earlier on created a table with a column username on which I imposed a unique constraint. I then created another table with a column bearer_name having a FOREIGN KEY referencing the previous table's column username; the one which had a UNIQUE CONSTRAINT.
Now, I want to drop the UNIQUE CONSTRAINT on the username column from the database because I have later on created a UNIQUE INDEX on the same column and intuitively I feel that they serve the same purpose, or don't they? But the database is complaining that the UNIQUE INDEX has some dependent objects and so it can't be dropped unless I provide CASCADE as an option in order to drop even the dependent object. It's identifying the FOREIGN KEY on bearer_name column in the second table as the dependent object.
And is it possible for the FOREIGN KEY to be a point to the UNIQUE INDEX instead of the UNIQUE CONSTRAINT?
I am seeking clarity on this: does a FOREIGN KEY require a UNIQUE CONSTRAINT on the other side
No it does not require only UNIQUE CONSTRAINT. It could be PRIMARY KEY or UNIQUE INDEX.
Perhaps, I can test this, but I'll ask, if the UNIQUE CONSTRAINT is required by the FOREIGN KEY what would happen if I don't create it? Will the Database create one or will it throw an error?
CREATE TABLE tab_a(a_id INT, b_id INT);
CREATE TABLE tab_b(b_id INT);
ALTER TABLE tab_a ADD CONSTRAINT fk_tab_a_tab_b FOREIGN KEY (b_id)
REFERENCES tab_b(b_id);
ERROR: there is no unique constraint matching given keys
for referenced table "tab_b"
DBFiddle Demo
And is it possible for the FOREIGN KEY to be a point to the UNIQUE INDEX instead of the UNIQUE CONSTRAINT?
Yes, it is possible.
CREATE UNIQUE INDEX tab_b_i ON tab_b(b_id);
DBFiddle Demo2
I am trying to add a Non clustered index on a tvt - something along the lines of ...
UNIQUE NONCLUSTERED (row_number) INCLUDE (event_datetime, venue_id)
is this not allowed on TVTs?
Thanks,
Erich
I believe you cannot!
A nonclustered index cannot be created on a user-defined table type unless the index is the result of creating a PRIMARY KEY or UNIQUE constraint on the user-defined table type. (SQL Server enforces any UNIQUE or PRIMARY KEY constraint by using an index.)
You can see more about restriction on UDT's here:
https://msdn.microsoft.com/en-us/library/bb522526(v=sql.105).aspx
Can I drop primary key index without dropping primary key constraint in postgresql?
Your question is a bit confusing. I think you must mean this:
Can I drop an index on a column but still keep the uniqueness constraint on that column?
No. A uniqueness constraint requires an index. You can make your constraint into an ordinary non-primary index, but you can't make it not an index.
Also, read about primary keys in the documentation:
Technically, a primary key constraint is simply a combination of a unique constraint and a not-null constraint.
So if a column is a primary key it has by definition a unique constraint and therefore also an index. You cannot have a primary key that isn't an index.