Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
What are the good example columns for which I should never create an index? As per my understanding the clustered index should often be done on primary keys (default) as it represents base data as a whole. But on which columns I should never create a non-clustered index?
You cannot say for sure. The fact is: you cannot create an index on any column (or combination of columns) that has a max size of more than 900 bytes - so any columns like VARCHAR(1000) or VARCHAR(MAX) cannot be indexed.
Other than that - it reallly depends on what your system does! There's no magic rule what columns to index - or which to avoid.
In general: fewer indexes are better than too many. Most DB developers tend to over-index their databases - but as I said - this is really heavily dependent on the exact situation of your system - there's no simple, general rules to follow here.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 days ago.
Improve this question
How does read query works in dynamoDB? I know that it internally calculates the hash based on the partition key and finds out the in which partition the item is present. After finding the partition how do you find the specific location of the item/record. Does it scan the complete partition for that item. If it scans the complete partition then how is dynamoDB called a key value lookup store?
I have searched for that in AWS Documentation, It's quite fascinating that is not mentioned anywhere.
A query returns all items with a given partition key value, ordered by sort key value. No, it doesn't need to scan the partition to do this because there is an internal index.
See Data distribution: Partition key and sort key:
it stores all the items with the same partition key value physically close together, ordered by sort key value.
I agree that it's difficult to find any AWS-supplied documentation that confirms that there is a partition-level index on pk+sk or discusses the implementation of the indexing (LSM, B-Tree etc.) Will update this answer if/when I find evidence.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 1 year ago.
Improve this question
I have a question about designing a table for events.
Which one is better using a multi-column primary key, or using a sequential primary key with multi-column unique index?
Columns of this table are like this:
Generally in SQL Server, PRIMARY KEY is created as unique clustered index in the background.
So, it is good practice to keep clustered index key as:
Unique (avoids effort to add uniquifier to make the value unique)
Narrow (does not occupy lot of space)
Incremental (avoids fragmentation)
So, in your case , it is better to go for
Sequential Primary key & multi column unique index
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I am designing a database with a table to store vehicles and since the vehicle identification number is a 17 digit alphanumeric serial number my idea is to use it as the primary key, with a datatype of char(17).
Numerous other tables will then have the VIN as a foreign key.
A number of queries/searches will run with the VIN number as parameter since it's how we would like to track the vehicles as well as other data related to it.
The VIN number will never change, but I'm unsure if it would cause any serious performance degradation (or other complications I'm not aware of) since some queries will use joins and others not :/
By using the VIN as primary key I do not have to create a unique constraint / additional index - BUT it has to be char(17) a data type other than int for which primary keys are supposedly optimized...
What I'm also not 200% sure of is that every VIN number out there is the same length (very unlikely) but in that case how would using a varchar(17) affect the whole situation... if at all.
Thanks!
Just a personal opinion..
I always use int as a primary key. Primary key is in most cases always a clustered index. It's 4 bytes vs. 17 bytes and you can always put a non-clustered index on your VIN column. Keep things simple and clear. It's just my opinion though.
In my opinion, regarding performance, it indeed is not a good idea. It very much depends how many cars you will store in the database though. On the other hand, if your applications and queries use the VIN as parameter then it is the best option as the column is indexed and must be unique.
hope this helps
ps: akward seeing other people's suggestions on this topic!
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
Imagine I have a table with only 2 columns (FKs to other tables). I want to define "the primary key of this table is the combination of the 2 values".
What happens if I don't have a PK in this kind of table?
Without a UNIQUE constraint or unique index defined on the two columns, the table could have duplicate rows.
Also, a primary key is a clustered index by default: you would need to separately index the table for expected query performance.
Refer to another SO question and yet another SO question declared as a duplicate of it regarding the differences between primary key & unique constraints and unique indexes.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
Many people have asked me that what is the advantage of one null value in unique key?
i am still unable to find the answer of that question
Although this question solicits speculation, there's one factual reason that a single NULL value makes sense from an implementors point of view: In the on-disk B-tree structure that SQL Server uses to implement an index, the NULL value is just like any other value. As long as the designers of SQL Server do not decide to create a special case for NULL values, this is the behavior you get by default.
And being able to index NULL values makes sense and is a useful feature. Counter-intuitively can use an index to seek on NULL: WHERE IndexCol IS NULL.
The unique constrain means that no duplicated values are allowed. So, there is nothing wrong to have one null value.
FYI, after SQL Server 2008 and later you are allowed to create a UNIQUE index on a column that have multiple NULL values. This is done using a Filtered Index.
I just wanted to check what #MartinSmith said about that NULL = NULL is not true and that the standard is not applied in SQL Server. So, after quick research I have found the following explanation proving his point:
A unique key constraint does not imply the NOT NULL constraint in
practice. Because NULL is not an actual value (it represents the lack
of a value), when two rows are compared, and both rows have NULL in a
column, the column values are not considered to be equal. Thus, in
order for a unique key to uniquely identify each row in a table, NULL
values must not be used. According to the SQL standard and Relational
Model theory, a unique key (unique constraint) should accept NULL in
several rows/tuples — however not all RDBMS implement this feature
correctly.