As we know we can have only one Primary key in a table, so is there any way to know the maximum number of Unique keys in a table.I have read a post according to which no of Unique keys depend on number of clustered index.
Check this link
http://www.orafaq.com/forum/t/152739/
If this SQL Server then check this Maximum Capacity Specifications for SQL Server
I think you are confusing youself with unique constraints and clustered constraints.
Unique key is a key by which you can easily tell which exatcly record you are dealing with.
Clustered key is a key which handles the physical position of the record on the hard disk.
So you can have many unique constraints for your record, but only the one which will order the records on the disk. Please refer the link mentioned by #user3414693, if you are using the MS SQL server:
Nonclustered indexes per table:
999 (Maximum sizes/numbers SQL Server (32-bit))
999 Maximum sizes/numbers SQL Server (64-bit)
You should note that here are all the indexes for the table, not only the unique ones.
Can't find specific information for the Oracle right now.
PS: Also you should note that having the primary key as clustered key can be a serious performance problem for the huge tables if you have a primary key a uniqueidentifier-type of column. Uniqueidentifier for real is a very-very big number, and it isn't being sorted like IDENTITY columns, so it is possible to face a situation during adding the new record when you have to move physically all the table data.
Related
I use sql server express 2012. If I add the same row to database 999999 times does the sql engine recgonize it and not
add this data 99999 times because its the same data and under the hood
it just save the id and point the first record to save space?
It depends as to how you have defined your table structure. If there is a primary key or unique(which does not appear to be present as per your statement) key then it will not allow. Else it will store all the data in the table. Also it does not make sense to store that huge amount of duplicates in your table. :)
Also check this:
SQL server will allow you to create a clustered index on non unique
column, but uniqueness is one of the most desirable attribute for any
indexes especially for a clustered index.Even if SQL server allow to
create clustered index on a non unique column , internally SQL server
add 4 bytes value for all duplicate instance of clustered key and this
4 bytes variable length column is known as uniquiifier .In this case
SQL server consider the clustered key as the combination of non unique
column on which clustered index is defined and internally generated
uniquifier column.This value will be stored where ever the clustered
key to be stored.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Performance difference between Primary Key and Unique Clustered Index in SQL Server
I make sure that I searched this forum but nobody asked this question before and I couldn't find any answer in anywhere too.
My question is = "What’s the difference between a primary key and a clustered index?"
Well, for starters, one is a key, and the other one is an index.
In most database lingo, key is something that somehow identifies the data, with no explicit relation to the storage or performance of the data. And a primary key is a piece of data that uniquely identifies that data.
An index on the other hand is something that describes a (faster) way to access data. It does not (generally) concern itself with the integrity and meaning of the data, it's just concerned with performance and storage. In SQL Server specifically, a clustered index is an index that dictates the physical order of storage of the rows. The things that it does are quite complex, but a useful approximation is that the rows are ordered by the value of the clustered index. This means that when you do not specify a order clause, the data is likely to be sorted by the value of the clustered index.
So, they are completely different things, that kinda-sorta compliment each other. That is why SQL Server, when you create a primary key via the designer, throws in a free clustered index along with it.
Before you can ask the difference between primary key and clustered index, you have to know that a key and an index are not the same thing.
A key can be a primary key or a foreign key. There can be only one primary key per table (but it might be more than one column). A key is a logical thing, it serves the business logic and defines the integrity of data. A foreign key is a reference to a primary key of another table.
Indexes helps to speed up your queries, because it builds references to columns of your choice. So it creates separate files that helps your queries that use indexed columns.
A clustered index is a special index that defines the physical order of your table (it should be a sequential data).
I tried to explain this with my own words, but you'll find all resources you need with a google search (and I definitely recommend that you read a lot of this ! )
Primary key is unique identifier for record. It's responsible for unique value of this field. It's simply existing or specially created field or group of fields that uniquely identifies row.
And clustered index is data structure that improves speed of data retrieval operations through an access of ordered records. Index is copy of one part of table. It takes additional physical place on hard disk.
In much of the RDBMS, as far as I know, when you create PK the engine in back creates clustered index. PK used for Entity integrity when clustered index sets data order and used for performance.
I have a table where I haven't explicitly defined a primary key, it's not really required for functionality... however a coworker suggested I add a column as a unique primary key to improve performance as the database grows...
Can anyone explain how this improves performance?
There is no indexing being used (I know I could add indexes to improve performance, what's not clear is how a primary key would also improve performance.)
The specifics
The main table is a log of user activity, it has a auto incrementing column for each entry, so it's already unique, but it isn't set as a primary key
This log table references activity tables which detail the specific activity, referenced by that autoincrementing entry in the main table. So the value is only unique in the main log table, there could be 100 entries in an activity table that reference that value as an identifier (ie. for session 212 Niall did these 500 things).
As you might guess the bulk of data is in the activity tables.
As Kimberly Tripp (the Queen of Indexing) clearly shows in her excellent blog post, The Clustered Index Debate Continues..., having a clustered index on your SQL Server table is beneficial - for all operations - yes, even for inserts!
To quote Kimberly:
Inserts are faster in a clustered table (but only in the "right" clustered table) than compared to a heap. The primary problem here is
that lookups in the IAM/PFS to determine the insert location in a heap
are slower than in a clustered table (where insert location is known,
defined by the clustered key). Inserts are faster when inserted into a
table where order is defined (CL) and where that order is
ever-increasing.
Since your primary key will by default automatically create a clustered index on that column you define, I would argue that yes, having a primary (clustering) key on your SQL Server table - even a log table - does have positive performance effects.
Primary keys can help performance - it tells SQL Server something important about that field - that it's unique and NOT NULL. This can help create more efficient execution plans.
This MSDN reference on Improving SQL Server Performance is worth a read.
Quote:
When primary and foreign keys are defined as constraints in the
database schema, the server can use that information to create optimal
execution plans.
A primary key automatically sets an index on the primary column. Setting an index to your table will increase performance on your queries.
You don't need to set a primary key to speed up your performance but you should set indexes to your table that will speed up your queries.
It depends on your queries and table what indexes make sense and which don't.
To add to the above - generally if you frequently search on a field, it is a good candidate for an index. Also, searching on an integer ID is usually faster than a string, for example.
Indexes take more storage space, but can increase search performance on that field.
I'm having a rather silly problem. I'll simplify the situation: I have a table in SQL Server 2008 R2 where I have a field 'ID' (int, PK) and a Name (nvarchar(50)) and Description (text) field. The values in the Name - field should be Unique. When searching the table, the Name - field will be used so performance is key here.
I have been looking for 2 hours on the internet to completely understand the differences between Unique Key, Primary Key, Unique Index and so on, but it doesn't help me solve my problem about what key/constraint/index I should use.
I'm altering the tables in SQL Server Management Studio. My question for altering that Name - field is: should I use "Type = Index" with "Is Unique = Yes" or use "Type = Unique Key"?
Thanks in advance!
Kind regards,
Abbas
A unique key and a primary key are both logical constraints. They are both backed up by a unique index. Columns that participate in a primary key are not allowed to be NULL-able.
From the point of view of creating a Foreign Key the unique index is what is important so all three options will work.
Constraint based indexes have additional metadata stored that regular indexes don't (e.g. create_date in sys.objects). Creating a non constraint based unique index can allow greater flexibility in that it allows you to define included columns in the index definition for example (I think there might be a few other things also).
A unique key cannot have the same value as any other row of a column in a table. A primary key is the column field(s) that is a unique key and not null which is used as the main look up mechanism (meaning every table should have a primary key as either a column or combination of columns that represent a unique entry).
I haven't really used indexes much, but I believe it follows the same logic.
See http://en.wikipedia.org/wiki/Unique_key for more information.
An index is a collection the DBMS uses to organize your table data efficiently. Usually you want to create an index on columns and groups of columns that you frequently search on. For example, if you have a column 'name' and you are searching your table where name = '?' and index on that column will create separate storage that orders that table so searching for a record by name is fast. Typically primary keys are automatically indexed.
Of course the above is a bit too general and you should consider profiling queries before and after adding an index to ensure it's being used and speeding things up. There are quiet a few subtleties to indexes that make the application specific. They take extra storage and time to build and maintain so you always want to be judicious about adding them.
Hope this helps.
this is undoubtedly a newbie question, but I haven't been able
to find a satisfactory answer.
When creating a link table for many-to-many relationships, is it better to
create a unique id or only use two foreign keys of the respective tables (compound key?).
Looking at different diagrams of the Northwind database for example, I've come across
both 'versions'.
That is: a OrderDetails table with fkProductID and fkOrderID and also versions
with an added OrderDetailsID.
What's the difference? (does it also depend on the DB engine?).
What are the SQL (or Linq) advantages/disadvantages?
Thanks in advance for an explanation.
Tom
ORMs have been mandating the use of non-composite primary keys to simplify queries...
But it Makes Queries Easier...
At first glance, it makes deleting or updating a specific order/etc easier - until you realize that you need to know the applicable id value first. If you have to search for that id value based on an orders specifics then you'd have been better off using the criteria directly in the first place.
But Composite keys are Complex...
In this example, a primary key constraint will ensure that the two columns--fkProductID and fkOrderID--will be unique and indexed (most DBs these days automatically index primary keys if the clustered index doesn't already exist) using the best index possible for the table.
The lone primary key approach means the OrderDetailsID is indexed with the best index for the table (SQL Server & MySQL call them clustered indexes, to Oracle they're all just indexes), and requires an additional composite unique constraint/index. Some databases might require additional indexing beyond the unique constraint... So this makes the data model more involved/complex, and for no benefit:
Some databases, like MySQL, put a limit on the amount of space you can use for indexes.
the primary key is getting the most ideal index yet the value has no relevance to the data in the table, so making use of the index related to the primary key will be seldom if ever.
Conclusion
I don't see the benefit in a single column primary key over a composite primary key. More work for additional overhead with no net benefit...
I'm used to use PrimaryKey column. It's because the primary key uniquely identify the record.
If you have a cascade-update settings on table relations, the values of foreign keys can be changed between "SELECT" and "UPDATE/DELETE" commands sent from application.