CREATE TABLE [TABELA DE VENDEDORES] ([MATRÍCULA] [CHAR] (5), [NOME] [VARCHAR] (100), [PERCENTUAL COMISSÃO] [MONEY])

Usar o money é uma alternativa estranha para o [PERCENTUAL COMISSÃO]

No SQL estruturalmente o Money ele é um "inteiro" com 4 casas decimais, com 8 bytes de dados

sugiro um DECIMAL(6,3) que ocuparia menos espaço e teria o mesmo efeito, pois o DOUBLE teria "arredondamentos" indesejados dependendo do caso

Na verdade o uso do tipo money no SQL Server (ou seus equivalentes) em outros SGDBs deixa a implementação inicial simples (intuitiva) mas quase sempre leva a problemas no futuro. Visualmente é vantajoso se ter, por exemplo, um cifrão antes de 100 ($100) indicando que se trata de cem unidades de real, por exemplo. Mas são dados que quase sempre estarão sujeitos a processamentos posteriores. Logo, no exemplo dado, ao se tentar somar os valores, por exemplo, das comissões, se teria de "retirar" todos os cifrões, calcular as somas, e depois "voltar" com um cifrão para a resposta. Claro que o SGBD Sql Server consegue prover essas "transformações" de forma transparente para os usuários. Mas é uma boa prática de desenvolvimento se antecipar a esse tipo de problema porque em muitas situações (como nos diversos casos de formatos de datas) o SGDB Sql Server sozinho não consegue otimizar todo o necessário para nós desenvolvedores levando a um ponto em que somente quando o tipo de dado começar a ser incompatível que se percebe o problema. Esses casos, geralmente implicam numa gama de funções auxiliares, manipulações de strings, conversão e (re)conversões de dados de um lado para outro, etc, 'sujando' os códigos, 'gastando' processamento e espaço e incorrendo em riscos maiores de erros.