pwaring's questions

Eu tenho um aplicativo legado executando o MariaDB 10.5 com algumas opções de design de banco de dados ruins (por exemplo, valores financeiros armazenados como VARCHAR(50)) que estou tentando melhorar.

Por exemplo, posso alterar uma coluna total_amount VARCHAR(50) para um DECIMAL mais sensato com:

ALTER TABLE orders MODIFY total_amount DECIMAL(12, 2);

No entanto, quando faço isso, às vezes recebo avisos como o seguinte:

Data truncated for column 'total_amount' at row 120058

Como eles não aparecem até depois de executar a consulta ALTER TABLE, não posso verificar se o truncamento é importante ou não. Por exemplo, se houver um espaço em branco à direita que foi removido, tudo bem, mas se o valor numérico foi alterado, esse é um problema importante. A grande maioria das linhas são modificadas sem problemas, mas preciso verificar todas as linhas que geram um aviso.

Existe uma maneira de perguntar ao MariaDB: 'se eu executasse este comando ALTER TABLE, quais linhas mudariam e quais seriam os valores antes e depois nessas linhas'? Muitos outros softwares têm uma opção de 'dry run' que me permite fazer isso, por exemplo, posso executar o rsync com --dry-run e ele me dirá quais arquivos ele transferiria, mas não os transferiria.

Sei que poderia criar um clone da tabela, ALTER o clone, comparar com o original e excluir o clone, mas se houver uma maneira mais fácil de fazer isso, economizaria muito esforço.

Eu tenho uma tabela MariaDB existente que desejo manter um histórico de alterações usando a funcionalidade interna de controle de versão do sistema. Estou usando o MariaDB 10.5, mas também testei tudo nesta questão no 10.11 (a versão para a qual este sistema será movido nos próximos 6 a 12 meses).

Também quero armazenar o histórico separadamente, pelos seguintes motivos:

• Cada linha é editada em média 10 vezes, então o conjunto de dados do histórico acabará tendo 10x o tamanho do conjunto de dados atual.
• Todas as consultas interativas (aproximadamente 95% de todas as consultas) serão executadas no conjunto de dados atual, portanto, quero mantê-lo o menor possível.
• As consultas que precisam de acesso ao conjunto de dados do histórico são executadas em trabalhos em lote durante a noite em que os tempos de resposta são menos problemáticos (por exemplo, levar 1s para retornar em vez de 0,1s é aceitável).

No entanto, se eu tentar fazer isso em uma tabela existente com a seguinte consulta:

ALTER TABLE t ADD SYSTEM VERSIONING PARTITION BY SYSTEM_TIME;

isso falha com:

SQL Error [1217] [23000]: (conn=5) Cannot delete or update a parent row: a foreign key constraint fails

Isso acontece mesmo se eu desativar a verificação de chave estrangeira (SET FOREIGN_KEY_CHECKS=0) antes de executar a consulta.

A explicação que encontrei está na página de chaves estrangeiras da documentação do MariaDB :

Tabelas particionadas não podem conter chaves estrangeiras e não podem ser referenciadas por uma chave estrangeira.

Isso significa que é impossível ter controle de versão do sistema com o histórico salvo separadamente se uma tabela contiver ou for referenciada por uma chave estrangeira? Isso parece ser o resultado de minhas investigações, mas também parece estranho, dado que a maioria dos bancos de dados relacionais contém chaves estrangeiras e a documentação do MariaDB tem uma seção inteira sobre como manter o histórico em uma partição separada - presumivelmente porque é um caso de uso comum.

Existe alguma maneira de contornar isso no MariaDB ou tenho que manter o histórico com os dados atuais (o que aumentará o conjunto de dados em um fator de 10)? A outra opção é criar uma tabela t_history separada e fazer com que o aplicativo acompanhe o histórico, mas isso não captura as alterações feitas fora do aplicativo, por exemplo, se um desenvolvedor executar manualmente uma consulta UPDATE.