Existe um equivalente T-SQL para pontuação como [0-9] é para números e [az] é para letras?

A maior dificuldade em chegar a uma solução precisa está em definir exatamente quais caracteres serão incluídos (ou excluídos, conforme a direção que fizer mais sentido para a operação). Significado:

• Estamos falando de VARCHARdados / ASCII ou dados NVARCHAR/ Unicode? A lista de caracteres de pontuação para dados ASCII depende da página de código que, por sua vez, depende do agrupamento. ( nesta questão estamos lidando com dados ASCII ).
• Estamos lidando com pesquisas que diferenciam maiúsculas de minúsculas ou não?
• Para qual agrupamento a coluna está definida? O agrupamento nos informará a página de código e a distinção entre maiúsculas e minúsculas. ( nesta questão que estamos tratandoLatin1_General_CI_AS )
• o termo "pontuação" significa apenas caracteres de pontuação padrão (por exemplo ., ,, ;, :, etc) ou significa caracteres não alfanuméricos?
• Os caracteres de espaço em branco estão incluídos?
• Os personagens de controle estão incluídos?
• E os símbolos monetários como ¢, £, ¥, etc?
• E quanto a símbolos como ©e ™?
• Quais personagens são considerados "alfa"? Os caracteres não ingleses, como Â, É, Ñ, ß, Þestão incluídos?
• Como esta pergunta lida com teclados do Reino Unido (consulte a discussão para esta pergunta), e quanto ao caractere Æ/ æ?

Para ajudar a facilitar a clareza em relação ao comportamento esperado, a consulta a seguir mostrará todos os 256 caracteres do conjunto de caracteres Latin1 (ou seja, página de código 1252) e como funcionam as duas variações da solução proposta por @Shaneis . O primeiro campo (rotulado como Latin1_General_CI_AS) mostra a LIKEcláusula conforme proposta por @Shaneis (no momento em que este livro foi escrito) e o segundo campo (rotulado como Latin1_General_100_BIN2) mostra uma modificação em que cancelei o Collation para especificar um binário (ou seja, um Collation terminando em _BIN2; o _BINOs agrupamentos estão obsoletos, portanto, não os use se você tiver acesso às _BIN2versões), o que significava que também precisava adicionar o A-Zintervalo para filtrar letras maiúsculas, pois o agrupamento atual não diferencia maiúsculas de minúsculas:

;WITH nums AS
(
  SELECT TOP (256) (ROW_NUMBER() OVER (ORDER BY (SELECT NULL)) - 1) AS [Decimal]
  FROM   [master].[sys].[all_objects]
)
SELECT nm.[Decimal],
       CHAR(nm.[Decimal]) AS [Character],
       CASE WHEN CHAR(nm.[Decimal]) LIKE '%[^a-z0-9]%'
               THEN 'x' ELSE '' END AS [Latin1_General_CI_AS],
       CASE WHEN CHAR(nm.[Decimal]) LIKE '%[^a-z0-9A-Z]%' COLLATE Latin1_General_100_BIN2
               THEN 'x' ELSE '' END AS [Latin1_General_100_BIN2]
FROM   nums nm;

ATUALIZAR

Deve-se mencionar que SE alguém está realmente procurando encontrar caracteres que são classificados como "pontuação" (e não "símbolo de moeda", "símbolo matemático", etc) e SE não está proibido de usar SQLCLR / carregar um arquivo personalizado Assembly (o SQLCLR foi introduzido com o SQL Server 2005 e ainda não encontrei um bom motivo para não permitir isso, especialmente porque o Banco de Dados SQL V12 do Azure oferece suporte a SAFEAssemblies), então você pode usar Expressões Regulares, mas não pelo motivo que a maioria das pessoas iria adivinhar.

Em vez de usar expressões regulares para criar um intervalo de caracteres mais funcional, ou mesmo em vez de usar algo como \w(significando qualquer caractere de "palavra"), você pode especificar a categoria Unicode dos caracteres que deseja filtrar e existem várias categorias definidas :

https://www.regular-expressions.info/unicode.html#category

Você pode até especificar o Bloco Unicode para filtrar, como "InBengali" ou "InDingbats" ou "InOptical_Character_Recognition", etc:

https://www.regular-expressions.info/unicode.html#block

Existem vários exemplos de criação de funções RegEx para SQL Server (embora a maioria dos exemplos não siga as práticas recomendadas do SQLCLR), ou você pode baixar a versão gratuita da biblioteca SQL# (que eu criei) e usar a função escalar RegEx_IsMatch da seguinte maneira :

SQL#.RegEx_IsMatch(Unicode-String-Expression, N'\p{P}', 1, NULL)

A \p{P}expressão significa \p= Categoria Unicode e {P}= todas as pontuações (em oposição a um tipo específico de pontuação, como "Pontuação do Conector"). E a categoria "Pontuação" inclui toda a pontuação em todos os idiomas! Você pode ver a lista completa no site Unicode.org através do seguinte link (existem atualmente 717 Code Points nessa categoria):

http://unicode.org/cldr/utility/list-unicodeset.jsp?a=%5B%3AGeneral_Category%3DPunctuation%3A%5D

Uma versão atualizada da consulta de teste mostrada acima, incluindo outro campo que usa SQL#.RegEx_IsMatch com \p{P}, e os resultados de todos os 3 testes em todos os 256 caracteres da página de código 1252 (ou seja, Latin1_General) foram publicados em PasteBin.com em:

Consulta T-SQL e resultados para filtrar tipos de caracteres

ATUALIZAÇÃO
O seguinte foi mencionado na discussão relacionada:

Você fez uma boa observação sobre caracteres acentuados, sendo eles nomes de hotéis de todo o mundo, haverá caracteres acentuados nos nomes, para o meu problema, gostaria de classificá-los como caracteres alfa válidos.

Nesse caso:

1. Existem 11 caracteres não ingleses incluídos no conjunto de caracteres Latin1/Página de código que não correspondem ao a-zintervalo. São eles: ð Ð Þ þ œ Œ š Š ž Ž Ÿ. Eles precisam ser adicionados ao curinga e, embora não sejam necessários no momento, não faria mal nenhum adicioná-los A-Zpara que o padrão funcione tão bem em um agrupamento com distinção entre maiúsculas e minúsculas. O resultado final é:
   LIKE '%[^a-zA-Z0-9ðÐÞþœŒšŠžŽŸ]%'

2. Considerando que esses dados podem incluir "nomes de hotéis de todo o mundo", eu recomendo alterar o tipo de dados da coluna para NVARCHARque você possa armazenar todos os caracteres de todos os idiomas. Manter isso como VARCHARcorre um risco muito alto de eventualmente ter perda de dados, pois você só pode representar os idiomas baseados em latim, e nem mesmo totalmente para aqueles que recebem as seis categorias suplementares de Unicode que fornecem caracteres adicionais relacionados ao latim.

Posso estar simplificando demais isso um pouco, mas, se dissermos que a pontuação é tudo o que resta quando os valores alfanuméricos são removidos, o seguinte procurará por strings que contenham caracteres não alfanuméricos.

Create Table #Test
(
Value   VarChar(10)
) 
Insert Into #Test
Values ('123a'), ('456b'), ('12ABC'),('AB!23'),('C?D789')

-- Original
Select      *
From        #Test
Where       Value like '[0-9][0-9][0-9][a-z]'

-- Non Alpha-numeric
SELECT * FROM #Test WHERE Value LIKE '%[^a-z0-9]%';

DROP TABLE #Test;