Champ Django vers mappages de type SQL Server

Cet article documente comment les types de champs de modèles Django correspondent aux types de données SQL Server lors de l’utilisation du mssql-django backend.

Table de cartographie des types de champs

Champ de Django Type SQL Server Remarques
AutoField int avec IDENTITY(1,1) Clé primaire à incrément automatique.
BigAutoField bigint avec IDENTITY(1,1) Clé primaire à incrément automatique 64 bits.
SmallAutoField smallint avec IDENTITY(1,1) Clé primaire à incrément automatique de 16 bits.
BooleanField bit Magasins 0 ou 1.
CharField(max_length=N) nvarchar(N) Données de caractères Unicode.
DateField date Date sans heure.
DateTimeField datetime2 Date et heure avec fractions de seconde. Utilise l’offset datetimetime lorsque USE_TZ=True.
DecimalField(max_digits=M, decimal_places=D) numérique(M, D) Décimal à précision fixe.
DurationField bigint Stocké sous forme de microsecondes.
EmailField nvarchar (254) CharField avec validation d’email.
FileField nvarchar(100) Stocke le chemin du fichier.
FilePathField nvarchar(100) Stocke le chemin du système de fichiers.
FloatField float Virgule flottante 64 bits (float(53)). SQL Server accepte également le synonyme double precision.
IntegerField int Entier signé 32 bits.
BigIntegerField bigint Entier signé 64 bits.
SmallIntegerField smallint Entier signé 16 bits.
PositiveIntegerField int Avec une contrainte >= 0CHECK .
PositiveBigIntegerField bigint Avec une contrainte >= 0CHECK .
PositiveSmallIntegerField smallint Avec une contrainte >= 0CHECK .
GenericIPAddressField Nvarchar (39) Adresse IPv4 ou IPv6.
JSONField nvarchar(max) Avec la contrainte de vérification JSON.
SlugField nvarchar(50) CharField avec validation de slug.
TextField nvarchar(max) Texte Unicode de longueur illimitée.
TimeField time Temps sans date.
URLField nvarchar(200) CharField avec validation d’URL.
UUIDField char(32) UUID stocké sous forme de chaîne hexadécimale de 32 caractères.
BinaryField Varbinaire(N) Données binaires brutes. Le backend sert max_length à émettre varbinary(N).
ForeignKey C’est pareil pour le champ référencé Crée une contrainte d’indice et de code de la ligne de commande.
OneToOneField C’est pareil pour le champ référencé Crée un indice unique et une contrainte FK.
ManyToManyField N/A Crée une table intermédiaire.

Comportements spécifiques à SQL Server

Certains types de champs Django présentent un comportement spécifique à la plateforme lorsqu’ils sont utilisés avec SQL Server.

Limitation d’AutoField

Modifier un champ de modèle de ou vers AutoField au moment de la migration n’est pas pris en charge. Si vous devez changer le type de clé primaire, créez un nouveau champ et migrez les données manuellement.

Champ booléen et bit

Stockage 0 SQL Server et 1. Django correspond True/False à ces valeurs. NULL est supporté par BooleanField(null=True).

Prise en charge de DateTimeField et de fuseaux horaires

Dans USE_TZ=True vos paramètres Django, DateTimeField utilisez le décalage de datetimeoffset pour enregistrer les dates en fonction du fuseau horaire. Quand USE_TZ=False, il utilise datetime2.

Si vous activez USE_TZ après avoir créé les colonnes, vous devez migrer manuellement les colonnes datetime2 existantes vers datetimeoffset. Pour plus d’informations, voir Prise en charge des fuseaux horaires dans mssql-django.

TextField vs CharField

SQL Server mappe les deux TextField et CharField vers nvarchar. TextField utilise nvarchar(max) tandis que CharFieldnvarchar(N) où N est max_length.

Tous les champs de chaîne utilisent nvarchar (Unicode)

Le mssql-django backend mappe tous les champs de chaînes Django (CharField, TextField, EmailField, URLField, SlugField, et autres) en nvarchar, le type de chaîne Unicode. Il n’y a pas d’option intégrée pour utiliser varchar (non-Unicode) à la place.

C’est intentionnel. La gestion des chaînes de Django est Unicode partout, et nvarchar garantit que tous les caractères sont stockés correctement, quel que soit le langage ou l’encodage. Utiliser nvarchar évite la perte de données due aux incompatibilités de jeux de caractères.

Compromis :

  • NVARchar utilise 2 octets par caractère, contre 1 octet par caractère pour varchar avec des collations à un seul octet.
  • Les limites de taille des clés d’index s’appliquent (900 octets pour les index non clusterisés). Une colonne nvarchar(450) atteint la limite de 900 octets (450 x 2 octets), tandis qu’une colonne varchar(900) atteint la même limite en utilisant des caractères à un seul octet.
  • Si vos données sont exclusivement ASCII, nvarchar double le stockage par rapport à varchar.

Si vous avez besoin de colonnes varchar :

Pour les bases de données héritées ou les exigences strictes de stockage, créez un champ personnalisé qui remplace db_type:

from django.db import models

class VarcharField(models.CharField):
    def db_type(self, connection):
        return f"varchar({self.max_length})"

class LegacyProduct(models.Model):
    sku = VarcharField(max_length=50)  # Creates varchar(50) instead of nvarchar(50)

    class Meta:
        managed = False  # For existing tables
        db_table = "LegacyProduct"

Caution

L’utilisation de colonnes varchar risque de perdre des données si des caractères non-ASCII sont écrits. Utilisez cette approche uniquement lorsque vous êtes certain que la colonne stocke uniquement des données ASCII, ou lorsque vous devez correspondre un schéma de base de données existant.

Contenu connexe

  • Last updated on