[SP-pm] DBIx::Class insert ignore

Blabos de Blebe blabos at gmail.com
Thu Sep 17 00:04:39 PDT 2009


> Veja que não estou pichando o SQL

Você na verdade está pichando você mesmo.

> quando são bancos normais..normalizados..com poucos campos..

Balela.

> mas isso para o meu trabalho não suporta as necessidades...só isso..

Já te demonstrei que isso não é verdade.

Necessidade de quê?

Você está caindo em uma falha grotesca de design. Está tentando
transformar bacia em prego só porque tem um martelo.

Você está tentando criar tabelas de zilhares de campos em um banco de
dados relacional. Cadê o relacional dessa abordagem? Já te demonstrei
que dá pra substituir facilmente seus milhares de campos por menos de
10 tabelas com menos de 10 campos cada usando o tal do "relacional",
chaves primárias, estrangeiras e índices.

Se alguém te disse que era só pegar os seus aquivos binários e
espelhar no banco fazendo "um simpes de-para", lamento, mas não vai
funcionar decentemente. Os paradigmas são outros. É tudo diferente.

Do jeito que você está fazendo, ser um "formato proprietário", texto
plano ou planilha dá no mesmo.

Também já demonstrei que fazer parte do que seu sistema faz em
catalyst é trabalho de um fim de semana, principalmente desenhando o
banco da forma adequada.

O que você está fazendo é pegar uma ferrari, trocar o motor original
por um motor de lambreta e adaptar toda a mecânica do carro pra
funcionar assim, ao invés de aprender a dirigir ou contratar um
motorista.

Além do mais, até o momento não vi um benchmark medindo as diferenças
entre o seu formato binário e um banco de dados relacional bem
desenhado, nem tão pouco uma definição de requisitos para serem
auditados.

Dizer que milhares de dados é algo grande? Nem estamos falando de GB
ainda, estamos na casa dos KB.

E os *milhões* de dados que são processados diariamente pelo sistema
financeiro em cima de Oracle, Informix e cia?

E o que o Google usa pra te trazer 2 bilhoes de páginas que sabem o
que é google?
http://www.google.com.br/search?q=google

De repente essa "grande quantidade" ainda nem atingiu um número para
que n*log(n) se torne relevante. Já pensou nisso?

Então uma dica: ou delegue logo esse sistema para alguém que saiba o
que é um grafo ou pare de perder tempo com "tecnologias modernosas",
afinal, o seu sistema já faz o que você precisa que ele faça. Se não
está afim de fazer do jeito certo, melhor ficar como está. Pelo menos
voce domina o que está acontecendo.



2009/9/16  <claudio em dpreferencial.com.br>:
> Blabos..
>
> Veja que não estou pichando o SQL.. eu uso sql.. mas de forma bem simples..
> quando são bancos normais..normalizados..com poucos campos..
> mas isso para o meu trabalho não suporta as necessidades...só isso..
>
> Não sou melhor do que ninguém.. e vc mesmo é uma  prova viva que sempre
> estou disposto a ouvir.. aprender.. melhorar..
> eu sou louco para ver alguém me mostrar uma forma melhor, mais fácil de
> atender os meus clientes..pago para isso..
>
> Mas infelizmente as idéias e propostas não atendem.. fazer né..
> por isso tive que virar programador..rsrs
>
> temos que tomar aquela breja..
>
> Abs
>
>
> ----- Original Message ----- From: "Blabos de Blebe" <blabos em gmail.com>
> To: <saopaulo-pm em mail.pm.org>
> Sent: Wednesday, September 16, 2009 1:59 PM
> Subject: Re: [SP-pm] DBIx::Class insert ignore
>
>
> Vou avisar pro Google que MySQL não é bom pra eles :)
>
> 2009/9/16 Eden Cardim <edencardim em gmail.com>:
>>
>> 2009/9/16 <claudio em dpreferencial.com.br>:
>>>
>>> No meu caso os registros são gigantes.. podendo atingir até 10.000
>>> campos...
>>> até onde estudei.. q foi pouco.. descobri que em mysql existe limites
>>> muito
>>> pequenos, do tipo:
>>> - Quantidade máxima de campos.. algo em torno de 3.500
>>> - Quantidade máxima de campos para serem manipulados de uma só vez.. algo
>>> em
>>> torno de 50..
>>> .. não tive tempo de estudar sobre o limite dos outros bcos.
>>>
>>> Por isso, a indicação padrão do mercado, sempre foi transformar os campos
>>> em
>>> novos registros... rsrsrs..
>>>
>>> Bom, concluindo..
>>>
>>> Um registro bem simples de 500 campos,
>>> no mysql demora cinco segundos para update.. (no meu sistema não demora
>>> um..rsrs)
>>>
>>> Agora imagina como isso impacta nas operações c/ grandes volumes de
>>> registros.
>>>
>>> Até o momento não achei uma solução razoável, para esta questão...
>>>
>>> Se souber de algo que ajude nesta tarefa, aviso,
>>> se alguém tiver uma luz, desde já agradeço.
>>
>> Já expliquei antes pra você que sua modelagem está errada, por isso é
>> lenta em sistemas geranciadores de bancos de dados de verdade.
>>
>> --
>> Eden Cardim Need help with your Catalyst or DBIx::Class project?
>> Code Monkey http://www.shadowcat.co.uk/catalyst/
>> Shadowcat Systems Ltd. Want a managed development or deployment platform?
>> http://edenc.vox.com/ http://www.shadowcat.co.uk/servers/
>> _______________________________________________
>> SaoPaulo-pm mailing list
>> SaoPaulo-pm em pm.org
>> http://mail.pm.org/mailman/listinfo/saopaulo-pm
>>
> _______________________________________________
> SaoPaulo-pm mailing list
> SaoPaulo-pm em pm.org
> http://mail.pm.org/mailman/listinfo/saopaulo-pm
> _______________________________________________
> SaoPaulo-pm mailing list
> SaoPaulo-pm em pm.org
> http://mail.pm.org/mailman/listinfo/saopaulo-pm
>


More information about the SaoPaulo-pm mailing list