Ao exportar meu banco de dados do MySQL versão 8, vejo esta linha, o que está me deixando intrigado.
É para uma coluna/campo virtual
`Rego` varchar(12) GENERATED ALWAYS AS (concat(`Call_Sign`,_utf8mb4' ',`Vehicle`)) VIRTUAL,
Especificamente o que é esse artefato Call_Sign,_utf8mb4' dentro do concat?
Quando transfiro novas alterações de esquema do MariaDB para o MySQL, funciona na maior parte do tempo. Às vezes, tenho que mexer.
Mas meu principal problema é quando faço backup do esquema e dos dados do MySQL e tento restaurá-los para meu PC, bem, desisti. Isso requer muitas alterações. Muitos problemas estão relacionados a conjuntos de caracteres.
Há algo que eu possa fazer para tornar o #2 mais fácil? Talvez algumas regras sobre o que evitar no MySQL.
Tenho um servidor REST em execução no Amazon EC2 Windows com MySQL. Parece que, após um longo período de inatividade, o MySQL está encerrando as conexões. Estou usando Delphi com FireDAC. Recebo este erro nos logs
conFD: TFDPhysMySQLConnection: . O servidor MySQL foi embora [errno=2006, sqlstate="HY000"]
Pelo Google, parece que são 8 horas. Eu poderia aumentar isso, mas eventualmente isso ainda vai acontecer durante os feriados (talvez).
É a única tarefa do MySQL em execução, então não preciso conservar recursos. Qual é outra maneira de resolver isso?
Quero registrar consultas em apenas uma tabela.
Eu encontrei estes
SET GLOBAL log_output = "FILE"; which is set by default.
SET GLOBAL general_log_file = "/path/to/your/logfile.log";
SET GLOBAL general_log = 'ON';
No entanto, isso registra todas as consultas.
Há perguntas no SO, mas elas são para registro total.
Eu sempre armazenei Application Options como um arquivo Ini no Windows, pois era mais rápido de acessar do que o banco de dados. Além disso, às vezes, você precisa ler algumas delas antes de acessar o banco de dados.
A desvantagem é que se você fizer backup do banco de dados, as opções não aparecerão.
Eu poderia salvá-los
Estou pensando em armazená-los como um array JSON em um campo. Há alguma desvantagem nisso?
Não acho que importe em que o aplicativo é escrito, pois posso implementar qualquer coisa dentro do razoável. Não só há bibliotecas JSON (e INI) incorporadas ao Delphi, como também tenho minhas próprias bibliotecas super-rápidas de manipulação de JSON (e INI). E o MariaDB também suporta JSON.
O aplicativo é escrito em Delphi (Pascal) compilado para Windows. Mas partes do conjunto podem muito bem ser escritas em PHP (mais adiante).
Sempre usei direitos de acesso do usuário como um conjunto (de bits) no código e os armazenei como vários bigints (dependendo de quantos eu precisava).
Estes são direitos como
Portanto, eles não estão relacionados apenas a bancos de dados.
Vejo que eu poderia armazená-lo como um array JSON de descrições, mas isso poderia ficar muito grande (e talvez lento). Eu poderia usar uma sigla de 4 letras para cada um.
Existe uma terceira maneira de fazer isso para minimizar a verbosidade no código?
Tenho um banco de dados MariaDB na minha máquina de desenvolvimento e um no servidor do cliente.
Conforme estou desenvolvendo, estou atualizando o esquema do banco de dados (junto com o código). Quando atinjo um marco, quero atualizar os metadados do banco de dados no servidor.
Existe uma maneira de marcar o esquema atual e então produzir um sql para as alterações?
Há uma pergunta semelhante aqui , mas
Criei um banco de dados onde um dos campos de uma tabela é definido como enum('M', 'B'). A ferramenta que estou usando converte-o para um tipo variante . Gostaria de substituí-lo e tratá-lo como um caractere. Então a questão é, ele é armazenado como um caractere no banco de dados?
Como exemplo, pegue uma tabela de cidade com 2 colunas
com índices em ambos.
Eu quero fazer uma pesquisa independente de caso por city_name.
Eu sei que posso usar como , mas isso não é muito eficiente.
Uma maneira seria armazenar a variação de letras maiúsculas do city_name em outro campo .
Mas não posso deixar de pensar que deveria haver uma maneira de usar charset ou collation para fazer isso.
Alguém pode me apontar na direção certa, por favor.