Tiddo's questions

Eu "herdei" um aplicativo da web que foi projetado e implementado de maneira horrível (tanto o aplicativo quanto o banco de dados). Por exemplo, os dados principais são armazenados usando uma espécie de armazenamento de valor-chave emulado em um banco de dados Postgres 8.2, tornando praticamente impossível extrair dados úteis dele em um período de tempo razoável.

Atualmente estou trabalhando duro para substituir todo o aplicativo + banco de dados, no entanto, levará alguns meses até que o novo aplicativo seja concluído. Isso é um problema, pois o site é muito lento devido ao design extremamente ruim do banco de dados e às consultas ainda piores. Portanto, estou planejando corrigir o design do banco de dados e as consultas no site ativo até que o site tenha um tempo de carregamento aceitável como uma solução temporária.

No entanto, tenho algumas limitações para contornar, as mais problemáticas são:

• Terei que fazer tudo de dentro de um CMS de construção proprietário.
• As consultas são todas distribuídas em muitos arquivos e não há como procurá-los. Portanto, é quase impossível garantir que atualizei todas as consultas para uma tabela específica.
• Não tenho acesso direto ao banco de dados, mas posso executar consultas usando um editor de consultas no CMS, mas apenas para tabelas pertencentes ao aplicativo (portanto, não há tabelas pg_* para mim).
• Não tenho acesso a um ambiente de desenvolvedor, nem posso criar um. Tudo tem que ser feito ao vivo.

Então, basicamente, terei que migrar um banco de dados ao vivo ao longo de alguns dias, ao mesmo tempo em que atualizo o aplicativo ao vivo para que ele possa lidar com o novo aplicativo, sem poder pesquisar o uso de cada tabela.

Com todas essas desvantagens levadas em consideração, elaborei o seguinte plano:

1. Crie tabelas inicialmente vazias para armazenar os dados de maneira sã.
2. Crie gatilhos nas tabelas antigas que podem sincronizar os dados com os novos.
3. Exporte os dados das tabelas antigas para as novas tabelas e ative os gatilhos.
4. Substitua as consultas uma a uma.

Usando esta estratégia, terei 2 bancos de dados sincronizados após a etapa 3. Inicialmente, todas as consultas irão para o banco de dados antigo, mas enquanto estou atualizando as consultas lentamente, o banco de dados antigo será menos usado e o novo mais.

Levando em consideração essa situação "subótima", essa é uma boa estratégia para corrigir alguns dos problemas? Que coisas devo levar em consideração ao fazer isso?

Observe que entendo perfeitamente que esta é uma missão suicida muito arriscada. No entanto, terei que fazer algo em um curto espaço de tempo, caso contrário, o site ficará totalmente inutilizável.

Qual é a melhor prática para armazenar metadados de registros individuais em um banco de dados?

Preciso armazenar metadados comuns, como hora de criação e hora da última atualização para muitas tabelas em meu banco de dados. Encontrei algumas soluções diferentes:

1. Armazene os metadados diretamente nas tabelas.

   Prós:

   • Os metadados estão diretamente vinculados aos registros
   • Nenhuma junção é necessária para recuperar metadados

   Contras:

   • Muitas colunas duplicadas são necessárias (a menos que a herança seja usada)
   • Metadados e dados de negócios não são separados

2. Crie uma tabela de metadados gerais e use chaves estrangeiras virtuais para vincular dados às tabelas e registros corretos.

   Prós:

   • Sem duplicação de colunas
   • Os metadados são separados dos dados de negócios

   Contras:

   • Sem links diretos entre metadados e dados (FKs não podem ser usados)
   • Junções requerem uma condição adicional

3. Crie tabelas de metadados individuais para cada tabela que requer metadados.

   Prós:

   • Os metadados estão diretamente vinculados aos registros
   • Os metadados são separados dos dados de negócios

   Contras:

   • Muitas tabelas extras são necessárias
   • Muitas colunas duplicadas são necessárias (a menos que a herança seja usada)

Existem mais opções, prós ou contras do que as que mencionei aqui? E qual é a melhor prática para armazenar esses metadados?

Eu tenho uma tabela de mensagens em um banco de dados, que inclui um id de remetente e um tipo de mensagem (e, claro, muitas outras colunas não relevantes para esta questão). Eu tento criar uma consulta que conta quantas mensagens de cada tipo um usuário enviou.

por exemplo, se eu tiver a seguinte tabela:

----------------------
identificação | usuário_id | tipo de mensagem
----------------------
1 | 1 | privado
2 | 1 | público
3 | 1 | privado
----------------------

Então eu quero obter o seguinte:

---------------------
identificação | privado | público
---------------------
1 | 2 | 1
---------------------

Então, na verdade, quero agrupar por message_type e user_id, mas em vez de gerar várias linhas por usuário, quero criar várias colunas, uma para cada message_type

Posso conseguir isso sem codificar os tipos de mensagem em minha consulta?

Até onde eu pude descobrir, muitos DBMSs (por exemplo, mysql, postgres, mssql) usam combinações fk e pk apenas para restringir as alterações nos dados, mas raramente são usados ​​nativamente para selecionar automaticamente as colunas a serem unidas (como a junção natural faz com nomes). Por que é que? Se você já definiu um relacionamento entre 2 tabelas com um pk/fk, por que o banco de dados não consegue descobrir que, se eu juntar essas tabelas, quero juntá-las nas colunas pk/fk?

EDIT: para esclarecer um pouco:

suponha que eu tenha uma tabela1 e uma tabela2. table1 one tem uma chave estrangeira na coluna a, que faz referência à chave primária na table2, a coluna b. Agora se eu juntar essas tabelas, terei que fazer algo assim:

SELECT * FROM table1
JOIN table2 ON table1.a = table2.b

No entanto, eu já defini usando minhas chaves que table1.a faz referência a table2.b, então me parece que não deve ser difícil fazer um sistema DBMS usar automaticamente table1.a e table2.b como colunas de junção, tal que se pode simplesmente usar:

SELECT * FROM table1
AUTO JOIN table2

No entanto, muitos DBMS parecem não implementar algo assim.