Даже bigint не хватило?

Hints:

1. Decimal - не лучший тип данных для первичного/внешнего ключа.

2. В связанных таблицах ПК тоже должны быть кластерными.

3. SQL Server Books Online:
PRIMARY KEY constraints create clustered indexes automatically if no clustered index already exists on the table and a nonclustered index is not specified when you create the PRIMARY KEY constraint.

4. В MS SQL 7/2000 остальные индексы содержат значения кластерного,
поэтому поле с кластерным индексом должно быть небольшого размера (в идеале - int).

Грустно очень.

У нас тоже по неопытности сделали несколько табличек с кривыми ПК, в основном с char(n).
Но потихоньку все перевели на int, потому как достало.

В БОЛ написано что, если определен кластерный индекс,
то остальные индексы ссылаются уже на него.
А если не определен, то ссылаются на некое физическое row ID (RID),
"comprised of the file number, page number, and slot number of the row".

Возможно в вашем случае, как раз этот RID оказывается лучше,
чем decimal(13) - и по размеру, и по скорости.

Чтобы узнать точно,
проверьте размеры всех индексов и планы запросов -
в обоих вариантах (с кластерным индексом и без него).