Migrar aplicativos Django de outros bancos de dados para SQL Server

Este artigo fornece diretrizes para migrar aplicativos Django do PostgreSQL, MySQL ou SQLite para SQL Server usando o mssql-django back-end.

Overview

O ORM do Django abstrai a maioria das diferenças de banco de dados, mas alguns comportamentos e dialetos SQL variam entre back-ends. Este guia aborda as principais diferenças encontradas ao migrar para SQL Server.

Etapa 1: Instalar mssql-django

Instale o mssql-django pacote e suas dependências:

pip install mssql-django

Verifique se o Microsoft Driver ODBC para SQL Server está instalado. Consulte Instalar mssql-django para obter instruções específicas da plataforma.

Etapa 2: atualizar DATABASE a configuração

Substitua sua configuração de banco de dados existente em settings.py:

# Example: From PostgreSQL
# DATABASES = {
#     "default": {
#         "ENGINE": "django.db.backends.postgresql",
#         "NAME": "mydb",
#     },
# }

# To SQL Server
DATABASES = {
    "default": {
        "ENGINE": "mssql",
        "NAME": "<your-database>",
        "USER": "<your-username>",
        "PASSWORD": "<your-password>",
        "HOST": "<your-server>",
        "PORT": "1433",
        "OPTIONS": {
            "driver": "ODBC Driver 18 for SQL Server",
        },
    },
}

Etapa 3: Criar novas migrações

Comece com um histórico de migração limpo para SQL Server:

# Remove existing migration files (keep __init__.py)
# Then regenerate
python manage.py makemigrations
python manage.py migrate

Principais diferenças do PostgreSQL

Recursos específicos do PostgreSQL a serem substituídos

Se o seu código usa recursos específicos do PostgreSQL de django.contrib.postgres, substitua-os:

# PostgreSQL ArrayField - replace with JSONField or related table
# Before
from django.contrib.postgres.fields import ArrayField
tags = ArrayField(models.CharField(max_length=50))

# After (using JSONField)
tags = models.JSONField(default=list)

# PostgreSQL HStoreField - replace with JSONField
# Before
from django.contrib.postgres.fields import HStoreField
metadata = HStoreField()

# After
metadata = models.JSONField(default=dict)

Principais diferenças do MySQL

Principais diferenças do SQLite

Diferenças de ordenação

O agrupamento controla como o SQL Server compara e ordena o texto. Essa é uma das fontes mais comuns de comportamento inesperado ao migrar do PostgreSQL ou do MySQL.

Diferenciar maiúsculas de minúsculas

A ordenação padrão de SQL Server (SQL_Latin1_General_CP1_CI_AS) não diferencia maiúsculas de minúsculas. O PostgreSQL diferencia maiúsculas de minúsculas por padrão.

Esse comportamento significa que, após a migração, consultas que antes distinguiam entre "Smith" e "smith" passam a tratá-los como iguais:

# On PostgreSQL: returns only exact case matches
# On SQL Server (default collation): returns both "Smith" and "smith"
User.objects.filter(last_name="Smith")

Se o aplicativo depender de comparações que diferenciam maiúsculas de minúsculas, você terá duas opções:

• Altere o agrupamento do banco de dados ou da coluna para uma variante com distinção entre maiúsculas e minúsculas:

  -- Database-level (affects all new columns)
  ALTER DATABASE [<your-database>] COLLATE Latin1_General_CS_AS;
  
  -- Column-level (for specific columns)
  ALTER TABLE [<your-table>]
  ALTER COLUMN [<column-name>] NVARCHAR (150) COLLATE Latin1_General_CS_AS;
  

• Use a pesquisa do __exact Django com uma substituição de ordenação no SQL bruto para consultas direcionadas.

Sensibilidade a acentos

A agrupação padrão do SQL Server é sensível a acentos (AS), o que corresponde ao comportamento do PostgreSQL. Caracteres como é e e são tratados como diferentes. Se você precisar de comparações que não diferenciam ênfase, use uma ordenação que termina em _AI.

Configurar ordenação no mssql-django

Substitua a ordenação padrão para pesquisas de campo de texto na configuração do banco de dados:

DATABASES = {
    "default": {
        "ENGINE": "mssql",
        "NAME": "<your-database>",
        "OPTIONS": {
            "driver": "ODBC Driver 18 for SQL Server",
            "collation": "Latin1_General_CS_AS",  # Case-sensitive
        },
    },
}

Etapa 4: Atualizar o SQL personalizado

Se o código contiver SQL bruto, atualize-o para SQL Server sintaxe:

# PostgreSQL syntax
# cursor.execute("SELECT * FROM products LIMIT 10 OFFSET 20")

# SQL Server syntax
cursor.execute("SELECT * FROM products ORDER BY id OFFSET 20 ROWS FETCH NEXT 10 ROWS ONLY")

Diferenças comuns de sintaxe SQL:

Diferenças de isolamento de transação

O PostgreSQL usa MVCC (controle de concorrência multiversão) para o seu nível de isolamento READ COMMITTED. Leitores nunca bloqueiam escritores e escritores nunca bloqueiam leitores.

A configuração padrão READ COMMITTED do SQL Server usa bloqueio, o que significa que as consultas de leitura podem ficar bloqueadas enquanto aguardam a conclusão das transações de escrita. Se o aplicativo tiver um bloqueio maior após a migração, considere habilitar READ COMMITTED SNAPSHOT no banco de dados:

ALTER DATABASE [<your-database>]
SET READ_COMMITTED_SNAPSHOT ON;

Isso faz com que o SQL Server passe a usar o controle de versão de linha em READ COMMITTED (semelhante ao MVCC do PostgreSQL), em vez de usar bloqueios. Os leitores veem a última versão confirmada de uma linha sem esperar por gravadores ativos.

Etapa 5: Migrar dados

A estratégia de migração de dados depende do tamanho do conjunto de dados:

Conjuntos de dados pequenos (<500 MB)

Use Django's dumpdata/loaddata:

# On the source database
python manage.py dumpdata --natural-foreign --natural-primary -o data.json

# Switch settings.py to SQL Server, then:
python manage.py migrate
python manage.py loaddata data.json

Conjuntos de dados grandes (>500 MB)

Para migrações grandes, use ferramentas especializadas para evitar problemas de esgotamento de memória e tempo limite. O ORM do Django não é a ferramenta certa para cargas em massa nesta escala. Ignore-o para a movimentação de dados e permita que o Django gerencie o esquema e a lógica do aplicativo posteriormente.

Validação pós-migração

Após a migração, valide a consistência da semente de identidade para colunas de incremento automático:

-- Check identity seed and current value for all tables
SELECT 
    TABLE_NAME,
    IDENT_SEED(TABLE_SCHEMA + '.' + TABLE_NAME) AS IdentitySeed,
    IDENT_INCR(TABLE_SCHEMA + '.' + TABLE_NAME) AS IdentityIncrement,
    IDENT_CURRENT(TABLE_SCHEMA + '.' + TABLE_NAME) AS CurrentIdentity
FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_TYPE = 'BASE TABLE'
    AND OBJECTPROPERTY(OBJECT_ID(TABLE_SCHEMA + '.' + TABLE_NAME), 'TableHasIdentity') = 1
ORDER BY TABLE_NAME;

Se CurrentIdentity exceder IdentitySeed + record_count, redefina a semente:

DBCC CHECKIDENT ('your_table', RESEED, new_seed);

Conteúdo relacionado

• Migrar aplicativos Django do PostgreSQL para SQL Server
• Instalar mssql-django
• Mapeamentos de tipos de campos do Django para tipos do SQL Server
• Limitações e recursos sem suporte no mssql-django
• Gerenciamento de transações no mssql-django
• Suporte a fuso horário no mssql-django
• JSONField com SQL Server