Problema

O principal problema que precisamos é usar a expressão regular no MS SQL Server 2019, com capacidade de pelo menos o nível da expressão regular POSIX.

Soluções possíveis

Este Q/A do stackoverflow conclui corretamente que, se a consulta deve depender de expressões regulares, você deve usar o CLR. Este artigo Readgate elabora mais essa abordagem. Então, um de meus colegas e eu propusemos essa solução, mas meu outro colega afirmou categoricamente que usar CLR aqui seria um grande risco para segurança e estabilidade, e usar script externo (Python ou R) é mais seguro.

Esta parece ser uma afirmação duvidosa, uma vez que o código do usuário no CLR pode ser gerenciado , então talvez o contrário seja verdade, mas não consegui convencer meu colega.

Na minha outra pergunta que escrevi em meu desespero porque fui forçado a usar script externo e ainda produzir uma consulta extremamente rápida. O usuário do SQLpro afirma em seu comentário que:

Usar Python ou R pode ser pior em termos de segurança do que usar CLR!

Que eu costumo acreditar.

Perguntas

Então eu tenho duas perguntas:

1. Qual solução Regexp é script externo mais seguro ou baseado em CLR (conforme descrito aqui )? E porque?

2. Também propus executar o código python no mesmo Windows Server (deve ser o mesmo servidor, por causa de uma política) mas com o python intrepeter instalado no SO. Porque os resultados são exportados para arquivos CSV de qualquer maneira e armazenados no SQL Server. Então eu poderia usar o módulo de multiprocessamento do Python para obter o desempenho certo. A resposta foi a mesma que executar o Python dentro do SQL Server é mais seguro do que em um aplicativo externo. O que também é uma afirmação questionável.

Para uma instalação de servidor PostgreSQL no Linux, é benéfico desabilitar o diário do sistema de arquivos.

Dica: Como o WAL restaura o conteúdo do arquivo de banco de dados após uma falha, os sistemas de arquivos registrados não são necessários para o armazenamento confiável dos arquivos de dados ou arquivos WAL. Na verdade, a sobrecarga do journaling pode reduzir o desempenho, especialmente se o journaling fizer com que os dados do sistema de arquivos sejam liberados para o disco. Felizmente, a liberação de dados durante o journaling pode ser desabilitada com uma opção de montagem do sistema de arquivos, por exemplo, data=writeback em um sistema de arquivos Linux ext3. Os sistemas de arquivos registrados melhoram a velocidade de inicialização após uma falha.

de: Documentação oficial Write-Ahead Logging (WAL)

Infelizmente não encontrei informações semelhantes sobre o SQL Server no Windows ou Linux, mas...

Como o SQL Server Sever, como todos os sistemas modernos de gerenciamento de banco de dados relacional, fazem WAL, parece lógico que também se pode e deve desabilitar o registro do sistema de arquivos em um sistema de arquivos Ext4 dedicado aos dados do MS SQL Server em uma instalação do Linux e talvez a mesma declaração significa NTFS em uma instalação do Windows.

Em que medida as afirmações anteriores são verdadeiras?

Problema

Pretendo carregar um CSV com mais de 10 milhões de registros no PostgreSQL v12.1, uma de suas colunas tem valores "categóricos", então criar um tipo enumerado para ele parece ser uma boa escolha, mas contém 208 categorias.

O campo mais curto tem 2 e o mais longo tem 11 caracteres. A média de todos os campos é 2,4. A codificação de caracteres é UTF8, mas todos os caracteres são ASCII .

Perguntas:

Qual tipo devo usar enumerated ou varchar ?

informação adicional

Eu descarto char porque a documentação oficial do PostgreSQL diz o seguinte sobre char , varchar e text :

Dica: Não há diferença de desempenho entre esses três tipos, além do aumento do espaço de armazenamento ao usar o tipo com preenchimento em branco e alguns ciclos extras de CPU para verificar o comprimento ao armazenar em uma coluna com restrição de comprimento. Embora o caractere(n) tenha vantagens de desempenho em alguns outros sistemas de banco de dados, não existe tal vantagem no PostgreSQL; na verdade, character(n) é geralmente o mais lento dos três devido aos seus custos adicionais de armazenamento. Na maioria das situações, a variação de texto ou caractere deve ser usada.

Um valor enum no PostgreSQL ocupa 4 bytes no disco (consulte 8.7.4. Detalhes de implementação). Considerando isso e o comprimento médio de string de 2,4 usando o tipo enum , levaria a um uso de disco um pouco maior (stings curtos no PostgreSQL precisam de um espaço em disco extra de byte). Ainda tenho a intuição de que usar enum é uma escolha melhor, pois sua implementação torna muitas operações mais rápidas contra ele.