Partage via

Types de données de table dans SQL Synapse

  • Article

Dans cet article, vous trouverez des recommandations pour définir les types de données de table dans un pool dédié Synapse SQL.

Types de données

Un pool dédié Synapse SQL prend en charge les types de données les plus couramment utilisés. Pour obtenir la liste des types de données pris en charge, consultez les types de données dans l’instruction CREATE TABLE. Pour Synapse SQL serverless, reportez-vous à l’article Interroger des fichiers de stockage avec un pool SQL serverless dans Azure Synapse Analytics et Guide pratique pour utiliser OPENROWSET avec le pool SQL serverless dans Azure Synapse Analytics

Réduction de la longueur de ligne

En réduisant la taille des types de données, vous réduisez la longueur de ligne, ce qui entraîne une amélioration des performances de requête. Utilisez le plus petit type de données qui fonctionne pour vos données.

  • Évitez de définir des colonnes de caractères ayant une grande longueur par défaut. Par exemple, si la valeur la plus longue est de 25 caractères, définissez la colonne en tant que VARCHAR(25).
  • Évitez d’utiliser NVARCHAR lorsque vous avez uniquement besoin de VARCHAR.
  • Lorsque c’est possible, utilisez NVARCHAR(4000) ou VARCHAR(8000) au lieu de NVARCHAR(MAX) ou VARCHAR(MAX).
  • Évitez d’utiliser des valeurs à virgules flottantes et des valeurs décimales avec une échelle de 0 (zéro). Ces valeurs doivent être de type TINYINT, SMALLINT, INT ou BIGINT.

Notes

Si vous utilisez des tables externes PolyBase pour charger vos tables Synapse SQL, la longueur définie pour la ligne de table ne doit pas dépasser 1 Mo. Lorsqu’une ligne avec des données de longueur variable dépasse 1 Mo, vous pouvez télécharger la ligne avec BCP, mais pas avec PolyBase.

Identification des types de données non pris en charge

Si vous migrez votre base de données à partir d’une autre base de données SQL, vous pouvez rencontrer des types de données qui ne sont pas pris en charge dans SQL Synapse. Utilisez cette requête pour identifier les types de données non pris en charge dans votre schéma SQL existant.

SELECT  t.[name], c.[name], c.[system_type_id], c.[user_type_id], y.[is_user_defined], y.[name]
FROM sys.tables  t
JOIN sys.columns c on t.[object_id]    = c.[object_id]
JOIN sys.types   y on c.[user_type_id] = y.[user_type_id]
WHERE y.[name] IN ('geography','geometry','hierarchyid','image','text','ntext','sql_variant','xml')
 OR  y.[is_user_defined] = 1;

Solutions de contournement pour les types de données non pris en charge

La liste suivante présente les types de données que SQL Synapse ne prend pas en charge, ainsi que des alternatives à ceux-ci.

Type de données non pris en charge Solution de contournement
geometry varbinary
Geography varbinary
hierarchyid nvarchar(4000)
image varbinary
text varchar
ntext nvarchar
sql_variant Fractionnez la colonne en plusieurs colonnes fortement typées.
table Convertissez-les en tables temporaires ou envisagez de stocker les données dans le stockage à l’aide de CETAS.
timestamp Corrigez le code à utiliser datetime2 et la fonction CURRENT_TIMESTAMP. Seules les constantes sont prises en charge en tant que valeurs par défaut, par conséquent le paramètre current_timestamp ne peut pas être défini comme une contrainte par défaut. Si vous devez migrer les valeurs de version de ligne à partir d’une colonne de type horodatage, utilisez le paramètre BINARY(8) ou VARBINARY(8) pour les valeurs de version de ligne NOT NULL ou NULL.
xml varchar
type défini par l’utilisateur Revenez au type de données natif lorsque c’est possible.
valeurs par défaut Les valeurs par défaut prennent uniquement en charge des littéraux et des constantes.

Étapes suivantes

Pour plus d’informations sur le développement des tables, consultez Vue d’ensemble des tables.