Parece que a falta de suporte para impor 2 restrições básicas (chave única e estrangeira) é um motivo para a perda de muitas horas de depuração e a solução de problemas difíceis. O que começa como um problema trivial e fácil de corrigir (linhas dup / tabelas de detalhes primários inconsistentes) passa despercebido, cresce e gera cenários de borda complexos em nosso aplicativo ou mesmo em nosso hardware (por exemplo, auto-associação com dups pode causar inflação e esgotamento do armazenamento

@Netezza serve a vários propósitos em nosso ambiente: produção, pesquisa, qa e preparação. Naturalmente, nossos processos de ETL não podem ser maduros e não podem verificar todas as restrições em todos esses cenários. Mesmo em nossos aplicativos mais maduros usados na produção, onde os dados são verificados enquanto o ETL os carrega, criamos uma série de tabelas, cada uma delas como resultado de um cálculo em seus antecessores. Às vezes, a integridade dos dados é interrompida ao longo do caminho, não logo no início (como resultado de uma declaração de buggy)

lguém pode recomendar uma metodologia / ferramenta para evitar essas dores de cabeç