[firebase-br] Indice

[Gustavo Moda]

2009/3/11 Forrest® <fernando.bg em gmail.com>

>
>
> Bom dia Adriano
>
> Como você disse cada caso é um caso e teria que conhecer bem o negócio
> para estar falando com certeza. Mas nesse caso não seria melhor ter
> normalizado como o Eduardo comentou e onde precisa fazer essas
> consultas envolvendo várias tabelas e vários unions não daria para
> criar views ou procedures selecionáveis que acredito não daria tanta
> diferença na performace e seria só dar um select na view ou procedure.
>

Olá, Adriano,

Como Forrest falou, uso VIEW para normalizar a consulta, criando termáticas.
Exemplos: Lançamentos de Notas,  Lançamentos de Títulos, etc.
Desenvolvemos uma PROCEDURE que monta a  QUERY on-fly e rodamos pelo EXECUTE
STATTMENT de acordo com os filtros.. Esse recurso otimizou a performace do
Balancete, RAZÃO e do DIÁRIO. A desvantagem de montar a QUERY em tempo de
execução é ter um erro de RUNTIME.. Mas tratando bem os filtros e testando
não tivemos problemas, rodo a 4 anos nesse esquema. Na versão 1.5. era o
unico recurso que tínhamos, hoje na 2.1. temos tabelas temporárias que
usamos alguns caso, tais como: em um relatório auxiliar comparando
lançamentos contaeis com os docuemntos,  ou inconsistências contábeis.

Outra coisa, dados imutáveis não mantenho relacionamento, gravo os campos
nessa tabela de contabildiade.Ex. Codigo Contábil, isso não muda. Não
preciso ficar fazendo INNER com a tabela de plano de contas., salvo os
campos na hora de criar o lançamento.

Espero ter ajudado.