Leandro,
2008/6/23 Mozart Hasse <[EMAIL PROTECTED]>: >> Não vejo futuro. Conheci gente que não vê futuro nem em unificação de >> sintaxe SQL e estruturas de bancos de dados, que dirá em unificação de >> modelagem. Leandro DUTRA: >Não sei se entendi a parte de estruturas ? a sintaxe SQL certamente >deveria ser unificada. Mas não será. Eu me referi a 'estruturas' como as outras "coisas" que estão nos bancos de dados hoje em dia além das tabelas 'físicas' e índices. Coisas como Triggers, Views, Chaves estrangeiras, Stored Procedures, Rules, Defaults, Functions, Domains, etc. Pode-se modelar de forma diferente se for do interesse do analista usar alguns desses recursos específicos a determinado banco de dados. Perde-se a compatibilidade (o que para muitos é um preço alto demais), porém em alguns casos ganha-se um nível de produtividade que viabiliza muitos negócios. >> Unificar o modelo implicaria em aceitar um desempenho horrível para certas >> operações > Teoricamente não, pelo menos não no modelo relacional. Mas com SQL, sim. O desempenho dos bancos de dados na prática está muito aquém do desempenho esperado conceitualmente, ao menos em várias tabelas de milhões de registros que eu tive de remodelar por causa de lentidão. Quando o modelo cresce demais (como em qualquer ERP), passamos a ter dezenas de consultas diferentes sobre a mesma tabela de milhões de registros, e nem sempre (nas versões antigas do Postgres raramente) o otimizador sabe que fazer com tantos JOINs para deixar o desempenho aceitável. >> ou em torná-lo tão genérico que consultar qualquer picuinha se >> tornaria uma jornada épica por dúzias de tabelas radicalmente normalizadas > Visões existem para isso... Quando *um monte* de tabelas puder ser visto de *dúzias* de maneiras diferentes, visões passam a ser um problema, pois o desenvolvedor sempre vai preferir pegar uma ou duas colunas prontas de uma das visões disponíveis (assumindo que ele seja um gênio da documentação e nomenclatura e *ache* a visão certa no meio de todas as outras, o que em termos práticos é muito difícil) ao invés de montar um SQL só para aquela situação. Se a visão tiver JOINs com tabelas pouco usadas, UNIONs, SubSELECTs ou funções de agregação e o desenvolvedor *não* usar todos os campos, o otimizador dificilmente vai conseguir dar um tempo de resposta decente comparado à consulta específica para aquela situação. Quando isso acontece em larga escala se transforma num desastre que inviabiliza a aplicação, independente da quantidade de CPUs, discos SCSI e pentes de memória disponíveis. Bom, aí até pode-se questionar se o número de objetos de banco de dados seria tão grande a ponto de ter estes problemas numa aplicação 'pequena' como um controle de estoque. Bom, se quiser no futuro integrá-la com um ERP, meu parecer é de que sim. Atenciosamente, Mozart Hasse _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
