COMPRUEBE la restricción para aplicar ###. ###. #### coincidencia de patrones

Me gustaría tener una restricción de verificación que aplique este patrón de expresiones regulares para un código de varias partes:

^\d{3}\.\d{3}\.\d{4}$

... tres números, un punto, tres números, un punto, cuatro números.

¿Necesito crear una función CLR para imponer la coincidencia de patrones y puedo hacer referencia a la función CLR en DDL?

¿Hay alguna manera de hacer cumplir el patrón de otra manera, usando LIKE?

sql-server sql-server-2012 constraint

— mrblint
fuente

La expresión regular en su pregunta no es del todo inequívoca

En la mayoría de los tipos que admiten Unicode, \ d incluye todos los dígitos de todos los scripts. Excepciones notables son Java, JavaScript y PCRE. Estos sabores Unicode solo coinciden con los dígitos ASCII con \ d.

Entonces, en muchos sabores, coincidiría ١١١.١١١.١١١١(ese personaje es el dígito árabe-índico uno )

Supongo que solo quieres que coincida con el latín 0-9. Puedes usar

DECLARE  @T TABLE
(
Col CHAR(12) CHECK (
                   Col LIKE REPLACE('ddd.ddd.dddd','d','[0-9]') 
                                  COLLATE Latin1_General_100_BIN2
                   )
)

Estoy usando la cláusula de intercalación binaria para que las cadenas les guste ¾¾¾.¾¾¾.¾¾¾¾o 10².10².1000no pasen la verificación ( como puede suceder en algunas intercalaciones ).

Ninguno de estos coincidiría con la expresión regular CLR deseada y, si bien el uso de la sintaxis establecida ( [0123456789]) en lugar de la sintaxis de rango ( [0-9]) resuelve la primera, todavía depende de la clasificación si 2coincide ²o no.

Estoy usando REPLACEel LIKEpatrón en lugar de codificarlo porque me parece más legible lo que el patrón está comprobando. Es más fácil ver tres dígitos y un punto seguido de tres dígitos, otro punto y luego cuatro dígitos en ese formato que el análisis [0-9][0-9][0-9].[0-9] [0-9][0-9].[0-9][0-9][0-9][0-9].

También facilita el intercambio de implementación.

Si decide que desea la semántica completa de la expresión regular CLR, después de todo, podría cambiar '[0-9]'arriba a abajo (y probablemente cambiar la columna NCHAR(12)en ese caso)

'[' +
 /*48-57 Basic Latin*/
N'0-9'+
 /*1632-1641 Arabic-Indic*/
N'٠-٩'+
 /*1776-1785 Extended Arabic-Indic*/
N'۰-۹'+
 /*1984-1993 Nko*/
N'߀-߉'+
 /*2406-2415 Devanagari*/
N'०-९'+
 /*2534-2543 Bengali*/
N'০-৯'+
 /*2662-2671 Gurmukhi*/
N'੦-੯'+
 /*2790-2799 Gujarati*/
N'૦-૯'+
 /*2918-2927 Oriya*/
N'୦-୯'+
 /*3046-3055 Tamil*/
N'௦-௯'+
 /*3174-3183 Telugu*/
N'౦-౯'+
 /*3302-3311 Kannada*/
N'೦-೯'+
 /*3430-3439 Malayalam*/
N'൦-൯'+
 /*3558-3567 Sinhala*/
N'෦-෯'+
 /*3664-3673 Thai*/
N'๐-๙'+
 /*3792-3801 Lao*/
N'໐-໙'+
 /*3872-3881 Tibetan*/
N'༠-༩'+
 /*4160-4169 Myanmar*/
N'၀-၉'+
 /*4240-4249 Myanmar Shan*/
N'႐-႙'+
 /*6112-6121 Khmer*/
N'០-៩'+
 /*6160-6169 Mongolian*/
N'᠐-᠙'+
 /*6470-6479 Limbu*/
N'᥆-᥏'+
 /*6608-6617 New Tai Lue*/
N'᧐-᧙'+
 /*6784-6793 Tai Tham Hora*/
N'᪀-᪉'+
 /*6800-6809 Tai Tham Tham*/
N'᪐-᪙'+
 /*6992-7001 Balinese*/
N'᭐-᭙'+
 /*7088-7097 Sundanese*/
N'᮰-᮹'+
 /*7232-7241 Lepcha*/
N'᱀-᱉'+
 /*7248-7257 Ol Chiki*/
N'᱐-᱙'+
 /*42528-42537 Vai*/
N'꘠-꘩'+
 /*43216-43225 Saurashtra*/
N'꣐-꣙'+
 /*43264-43273 Kayah Li*/
N'꤀-꤉'+
 /*43472-43481 Javanese*/
N'꧐-꧙'+
 /*43504-43513 Myanmar Tai Laing*/
N'꧰-꧹'+
 /*43600-43609 Cham*/
N'꩐-꩙'+
 /*44016-44025 Meetei Mayek*/
N'꯰-꯹'+
 /*65296-65305 Fullwidth*/
N'０-９'+
N']'  COLLATE Latin1_General_100_BIN2

— Martin Smith
fuente