Column Store indexes were introduced in SQL Server 2012 with a flavor of Non-Clustered index i.e. “Non-Clustered ColumnStore” index. However there is a big limitation that the underlying table becomes read-only as soon as you create one.

In SQL Server 2014 this behavior is unchanged and addition to this you can also create ColumnStore index as a Clustered index. And the good thing is that the table having “Clustered ColumnStore” index can also be updated. However there is one more big limitation here that there is no Clustered Key with this type if index, thus risking the Uniqueness in the table.

–> Here we will see this limitation and a workaround which can be used in some scenarios:

Notice: While creating this index there is no provision to provided the “Clustering Key”, as this index includes all of the columns in the table, and stores the entire table by compressing the data and store by column.

On checking the metadata (by ALT+F1) of the table, you will see NULL under the index_keys column:

– Now let’s check this feature of absence of Uniquenes. We will enter 2 records with same value:

We get an error that you cannot create more indexes if you have a Clustered ColumnStore index:
Msg 35303, Level 16, State 1, Line 25
CREATE INDEX statement failed because a nonclustered index cannot be created on a table that has a clustered columnstore index. Consider replacing the clustered columnstore index with a nonclustered columnstore index.

–> Workaround: As a workaround we can create an Indexed/Materialized View on top this table, with Clustering Key as the PK (1st column of the table/view):

– As expected we get an error after we inserted 1st records and tried to insert the 2nd duplicate record:
(1 row(s) affected)
Msg 2601, Level 14, State 1, Line 48
Cannot insert duplicate key row in object ‘dbo.vwTableWithCCI’ with unique index ‘IDX_vwTableWithCCI’. The duplicate key value is (1).
The statement has been terminated.

–> Not sure why Microsoft has put this limitation of not maintaining the Uniqueness with these indexes. While using this workaround you need to consider this approach if possible. Like in some scenarios where the table is very big and there are frequent updates (INSERT/UPDATE/DELETES) this approach of maintaining another Indexed-View would be expensive. So this approach should be evaluated before implementing.

How many rows you are inserting by Bulk load? You are seeing slow performance may be because you are having more than 100k rows and thus bulk load is bypassing the delta-store and directly inserting into compressed rows.

Creating the Cluster index, the Unique Key is also created. There are nothing like Cluster Key in SQL. The Index on top of View are working like index on “results” not directly as an index on the table/s used by view. Updating the view check all below table constraints. This is not bug. you have missunderstand the concept.