# Clustered index example of exception to the rule

**URL:** <https://forums.toadworld.com/t/clustered-index-example-of-exception-to-the-rule/37222>\
**Category:** Toad for SQL Server\
**Created:** [April 7, 2016, 1:34pm UTC](https://forums.toadworld.com/t/clustered-index-example-of-exception-to-the-rule/37222 "2016-04-07T13:34:19Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![tsharp89](https://avatars.discourse-cdn.com/v4/letter/t/e68b1a/32.png) [@tsharp89](https://forums.toadworld.com/u/tsharp89)\
**Post date:** [April 7, 2016, 1:34pm UTC](https://forums.toadworld.com/t/clustered-index-example-of-exception-to-the-rule/37222/1 "2016-04-07T13:34:19Z")

</div>

Per my research the ideal clustered index should be a narrow column and unique. We are currently on SQL Server 2012 and have a database setup for merge replication. I am in the process of adding a new table, StoreOPenDocuments, to our database. I am unsure what the clustered index should be.

Table StoreOpenDocuments

```
      StoreOpenDocumentsID defined as UniqueIdentifier

      CustomerID defined as UniqueIdentifier

      InvoiceNumber

      GrossAmount

      .

```

Table MemberShipList (existing table)

```
      MemberShipListID UniqueIdentifier

      CustomerID UniqueIdentifier

      StoreName

      StoreAddressLine1

      .

```

Would it make sense to make the StoreOpendocuments.CustomerID the clustered index even though it is not unique and is done on a UniqueIdentifier column?

Majority of our select statements will have where CustomerID = XXX

Or should I have the StoreOpenDocumetnsID be the clustered index, at least it is unique.

Thank you in advance for your time,

Tsharp89

---

<div class="post-metadata">

**Author:** ![c.zach](https://avatars.discourse-cdn.com/v4/letter/c/ce73a5/32.png) [@c.zach](https://forums.toadworld.com/u/c.zach)\
**Post date:** [April 8, 2016, 1:29am UTC](https://forums.toadworld.com/t/clustered-index-example-of-exception-to-the-rule/37222/2 "2016-04-08T01:29:37Z")

</div>

I’d rather leave the table as a heap omitting any clustered index before I would choose a uniqueidentifier-column as clustered index. Instead define non-clustered Indexes on the unique (primarykey) and another one on the customerid-column. Anyway, you’ll still have the problem of fast fragmentation but not on the clustered index.

If you’re not willing to use a heap then maybe an additional int-identity column would be a good choice for a clustered index.

see e.g. [www.sqlskills.com/…/](http://www.sqlskills.com/blogs/kimberly/guids-as-primary-keys-andor-the-clustering-key/)