Chave primária única x Chave primária composta

774 views
Skip to first unread message

Nilo Lima

unread,
Jun 16, 2009, 7:09:46 PM6/16/09
to pb...@googlegroups.com, dotnetar...@googlegroups.com
Ola,

Estou com um problema para convencer uma equipe de desenvolvimento que estou entrando agora, a nao usar chaves compostas.
Dei um boa pesquisada no grupo e no google procurando uma boa bibliografia para convence-los.
Nao encontrei nada ainda. Pesquisando aqui no grupo vi que o Mauricio Linhares falou sobre o livro Domain-Driven Design de Eric Evans. Eu tenho o PDF dele aqui e busquei por primary key e composed key e nao encontrei nada.
Algu'em conhece uma boa bibliografia para eu apresentar para a equipe.
Eles tamb'em querem colocar logica de negocio no banco usando procedures,function, trigres. Tamb'em queria mostra-los que isso nao 'e bom, ja argumentei varios fatores mas acho que eles precisam ouvir ou ler um terceiro confiavel.

Gostaria da ajuda dos senhores.
Obrigado

PS: Os acentos do meu teclado estao ruins

Juliano Oliveira

unread,
Jun 16, 2009, 7:52:23 PM6/16/09
to dotnetar...@googlegroups.com
Nilo,

Acho que a idéia é tu quebrar os argumentos deles. Qual o motivo das chaves compostas? Por que usar chaves compostas?

Sobre as regras de negócio, diga para eles algo como, "Pensem, como seria mais fácil a manutenção, ter regras de negócio espalahdas por sp´s, triggers, constraints ou centralizadas em um modelo de domínio?"

E uma dica, uma frase do Giovanni: "Não dê pérolas aos porcos". Se eles não querem, pena! 
E parabéns pela iniciativa. É difícil viu.. hehehe

[]´s

Juliano Oliveira
Analista Desenvolvedor
.Net, C#, Actionscript, Flex, NHibernate
http://programandoem.net
twitter: @juloliveira - skype: juloliveira


2009/6/16 Nilo Lima <nilo.a...@gmail.com>

Plácido Bisneto

unread,
Jun 16, 2009, 8:04:55 PM6/16/09
to dotnetar...@googlegroups.com
Olá,

Comecei a acompanhar a lista de discussão hoje e já tenho uma ótima thread! :)

Nilo, o que você deveria realmente perguntar da equipe é: 
Qual paradigma de programação vocês gostariam de usar?
Se eles responderem que querem utilizar OO, tente mostrá-los quão trabalhoso seria tentar fazer o sistema todo (incluindo manutenção) baseado nos conceitos relacionais.
Se eles conhecerem realmente de desenvolvimento OO, verão que trabalhar com frameworks ORM (EF, NHibernate e outros..) traz muitas vantagens e aceleram o processo.
Não que seja impossível implementar o padrão OO com SPs, triggers, views e etc, até porque, algumas consultas realmente você pode acelerar e muito o desempenho da aplicação com esses recursos.

Se eles acharem que é balela, peça para que eles implementem um protótipo funcional na forma deles, e você implementa um da sua forma (sem acoplar todo o sistema na base de dados).

Acredito que a melhor forma de convencê-los é tirando a "prova dos 9".
Já trabalhei com equipes que pensavam da mesma forma. Por estarem acostumados com o desenvolvimento focado em E/R, é praticamente impossível de fazê-los mudar de idéia.
A premissa das ferramentas ORM de que o software é "database independent" de nada agrega valor ao negócio, pois provavelmente eles não pretendem mudar de banco de dados.

Espero ter ajudado!


Plácido Bisneto
.NET Developer
http://cidico.wordpress.com


2009/6/16 Nilo Lima <nilo.a...@gmail.com>

Diogo Menezes

unread,
Jun 16, 2009, 8:13:57 PM6/16/09
to dotnetar...@googlegroups.com
Boa noite a todos, entrei hoje na lista e estou achando muito legal poder participar de papos inteligentes como esse.

Primeiramente, acredito que deve-se sim tentar ao máximo "dar as pérolas aos porcos" ainda mais se você está envolvido no projeto. Caso tenha que trabalhar dessa forma, estará regredindo como profissional e isso não é nada legal.

Hoje em dia o uso de chaves burras, não relacionadas ao negócio (surrogate keys) é muito comum.Chaves compostas aumentam a complexidade e sua performance pode ser suprida com a criação de índices.

Já a lógica toda no banco de dados acho completamente desnecessário, hoje temos vários modelos de desenvolvimento em camadas, a superioridade na facilidade de desenvolvimento, depuração, teste e manutenção é INDISCUTÍVEL.

Abraços !!


2009/6/16 Juliano Oliveira <jul.ol...@gmail.com>



--
Diogo Menezes

Diogo Menezes

unread,
Jun 16, 2009, 8:21:14 PM6/16/09
to dotnetar...@googlegroups.com
Realmente Plácido além de tudo que citamos ainda tem o acoplamento total a uma base de dados. 

Se um belo dia for necessário mudar a base de dados olha a dor de cabeça formada.


2009/6/16 Plácido Bisneto <placido...@gmail.com>



--
Diogo Menezes

Plácido Bisneto

unread,
Jun 16, 2009, 8:28:25 PM6/16/09
to dotnetar...@googlegroups.com
Só pra tu teres uma idéia de como é complicado isso, eu trabalhei num projeto que não sabíamos se a base de dados ia ser SQL Server ou PostgreSQL. No final, o cliente optou por usar o Oracle. hehehe :D

Santo NHibernate nessas horas! :D


Plácido Bisneto
.NET Developer
Blog: http://cidico.wordpress.com
OpenControls: http://opencontrols.codeplex.com


2009/6/16 Diogo Menezes <diogol...@gmail.com>

Diogo Menezes

unread,
Jun 16, 2009, 8:31:33 PM6/16/09
to dotnetar...@googlegroups.com
rsrs realmente Plácido, também escolhi trabalhar com NHibernate e até hoje ele nunca me deixou na mão pelo contrário.

Tenho sistemas rodando com mais de 1 milhão de usuários e atende numa boa !!!

2009/6/16 Plácido Bisneto <placido...@gmail.com>



--
Diogo Menezes

Juliano Oliveira

unread,
Jun 16, 2009, 8:46:29 PM6/16/09
to dotnetar...@googlegroups.com
Diogo,

Eu também não gostava com disso mas depois de tanto presentear porcos em vão, você acaba assumindo a frase pra si próprio.

Hoje eu tento 3 vezes pelo menos para tentar mostrar coisas boas, na quarta, já não falo mais. Na empresa onde trabalho é assim. Eles juram que a metodologia "bagunça" que ele usam nos projetos é melhor que Scrum, que Scrum só funciona para programação (e eu sugeri para o desenvolvimento de sites) entre outras besteiras.

Deve-se saber usar o "não dê pérolas aos porcos". Imagine você sozinho no meio de uma equipe de cinco pessoas gastando saliva e o time não considerando nem ouvir o que você tem a dizer. Quando isso aconteceu na empresa anterior a essa onde eu trabalho hoje aconteceu, eu procurei um ambiente melhor... troquei de emprego.


[]´s

Juliano Oliveira
Analista Desenvolvedor
.Net, C#, Actionscript, Flex, NHibernate
http://programandoem.net
twitter: @juloliveira - skype: juloliveira


2009/6/16 Diogo Menezes <diogol...@gmail.com>

Giovanni Bassi

unread,
Jun 16, 2009, 8:56:02 PM6/16/09
to dotnetar...@googlegroups.com
Eu acho que temos que tentar sim, mas até um limite.
A questão é: se o time acha que está bom, se não dói, então não tem porque mudar.
Na verdade, nessas situações geralmente não está nada bom. A questão é que o time se engana, finge que está tudo bem, e continua quebrando a cara. Mas não admite que há algo de errado. E não sou eu quem vai dizer para eles que há maneira melhor de fazer as coisas, se eles acham que está tudo certo. Eles primeiro tem que perceber isso. Eu até tento mostrar, mas como eu disse: até um limite.
É por isso que evito fazer marketing. Melhor do que ser empurrado para a empresa é ser puxado. Ela te chama quando dói, quando sabe que algo não vai bem.

Empurrar arquitetura é uma das coisas mais difíceis que já fiz. Não faço mais.

[]'s

Giovanni Bassi
Microsoft MVP, MCSD, MCPD, CSM
Arquiteto de software
http://www.giovannibassi.com


2009/6/16 Juliano Oliveira <jul.ol...@gmail.com>

Giovanni Bassi

unread,
Jun 16, 2009, 9:08:04 PM6/16/09
to dotnetar...@googlegroups.com
Tenho alguns argumentos baseados na minha experiência para esse cenário.

Para o caso de haver regras de negócio no banco:
  1. Quando mudar de banco você vai ter que reimplementar para o outro banco;
  2. Haverá duplicação de regras no código .Net, porque há conceitos que precisam vazar para a aplicação.
  3. O ganho de performance é muito pequeno, a ponto de ser desconsiderado.
  4. Não há ganho nenhum de segurança.
  5. Custa mais caro porque as ferramentas para construção não são tão evoluídas.
  6. É mais difícil testar (e portanto mais caro).
  7. Se você usar SPs para fazer o CRUD, esquece ORM. E lá vai mais dinheiro para fazer SQL na mão (ou via Table Adapters ou commands).
Quase choro quando um cliente quer fazer isso. É uma das piores decisões que podem ser tomadas. Os únicos casos em que vejo que isso é válido é em tarefas de ETL ou carga massiva de dados.

Para o caso das chaves compostas que replicam dados reais do domínio da aplicação:
  1. Qual o motivo? Podemos fazer a mesma coisa com restrições únicas.
  2. Se algo mudar no negócio, talvez você possa ter que alterar uma coluna que é chave primária de uma tabela. O custo dessa operação é muito alto se a massa de dados for muito grande. Além disso, há todo o problema da propagação da chave para as chaves estrangeiras.
  3. O custo é maior para fazer chaves estrangeiras. Qualquer chave tem que referenciar todos os campos que formam a PK. Por esse motivo o modelo fica poluído.
  4. É mais difícil falar sobre a tabela (e comunicação é fundamental). Por exemplo: "A linha que tem nome='abc' e código='xyz' está com problema". Não era mais fácil dizer: "O id 3"?
  5. É mais difícil trabalhar com um ORM. Alguns simplesmente não suportam.
  6. É mais difícil modelar as entidades.
Já trabalhei em sistemas assim. A chave composta dificulta muito o trabalho.


[]'s

Giovanni Bassi
Microsoft MVP, MCSD, MCPD, CSM
Arquiteto de software
http://www.giovannibassi.com


2009/6/16 Nilo Lima <nilo.a...@gmail.com>

tucaz

unread,
Jun 16, 2009, 9:08:04 PM6/16/09
to .Net Architects
Porque só eu sou do contra aqui no grupo? Acho que deve ter algo
errado comigo, mas anyway...

Geralmente eu diria que trabalhar com objetos ao invés de usar
procedures é a melhor ideia, mas nesse caso em especifico, nem você
sabe porque você está tentando empurrar isso pra eles, Nilo. Acredito
que não devemos tentar empurrar a mesma arquitetura de referência o
tempo todo. Ultimamente acredito que isto esteja acontecendo porque a
maioria das pessoas (aqui do grupo pelo menos) não tenham tido a
oportunidade de trabalhar com esse tipo de ferramenta (DDD e real OO)
e estão loucas pra tentar. Acho isso excelente, mudar e melhorar é
excelente, mas será que não estamos levando boas ferramentas para o
buraco tentando empurrá-las a qualquer custo?

Antes de procurar bibliografias de referência ou artigos que defendam
sua posição, veja o que você entende e porque a idéia deles não é uma
boa. É muito fácil (isso vale pra todos me included) assumir uma
posição e defende-la a todo custo e depois colocar a culpa de qualquer
fracasso no fato de não terem aceitado sua idéia.

Se o time que está envolvido no projeto não compra uma idéia, não
adianta forçar goela abaixo. Procure usar as dicas daquele vídeo de
mestrado que vimos aqui sobre padrões para introduzir novas idéias e
faça devagar, em doses leves. Mudar 100% de uma hora pra outra é tão
perigoso quanto continuar no caminho errado.

Juliano, vou "quotar" uma situação que aconteceu com você, como
exemplo, mas isso não quer dizer que você fez certo ou errado, ok?
Lembra que você foi apresentar Scrum pro pessoal da sua empresa e não
teve muito sucesso? Pronto, são algumas pessoas que nunca mais vão
querer ouvir falar a respeito. Por isso, temos que tomar muito cuidado
quanto a sermos incisivos demais em alguns casos. Uma ferramenta ou
produto só é realmente bom quando alguém compra. Se ninguém compra,
não adianta ser o melhor que existe.

Att.,
Antonio Carlos Zegunis Filho
http://blog.tucaz.net

On Jun 16, 7:56 pm, Giovanni Bassi <gig...@giggio.net> wrote:
> Eu acho que temos que tentar sim, mas até um limite.
> A questão é: se o time acha que está bom, se não dói, então não tem porque
> mudar.
> Na verdade, nessas situações geralmente não está nada bom. A questão é que o
> time se engana, finge que está tudo bem, e continua quebrando a cara. Mas
> não admite que há algo de errado. E não sou eu quem vai dizer para eles que
> há maneira melhor de fazer as coisas, se eles acham que está tudo certo.
> Eles primeiro tem que perceber isso. Eu até tento mostrar, mas como eu
> disse: até um limite.
> É por isso que evito fazer marketing. Melhor do que ser empurrado para a
> empresa é ser puxado. Ela te chama quando dói, quando sabe que algo não vai
> bem.
>
> Empurrar arquitetura é uma das coisas mais difíceis que já fiz. Não faço
> mais.
>
> []'s
>
> Giovanni Bassi
> Microsoft MVP, MCSD, MCPD, CSM
> Arquiteto de softwarehttp://www.giovannibassi.com
>
> 2009/6/16 Juliano Oliveira <jul.olive...@gmail.com>
>
> > Diogo,
> > Eu também não gostava com disso mas depois de tanto presentear porcos em
> > vão, você acaba assumindo a frase pra si próprio.
>
> > Hoje eu tento 3 vezes pelo menos para tentar mostrar coisas boas, na
> > quarta, já não falo mais. Na empresa onde trabalho é assim. Eles juram que a
> > metodologia "bagunça" que ele usam nos projetos é melhor que Scrum, que
> > Scrum só funciona para programação (e eu sugeri para o desenvolvimento de
> > sites) entre outras besteiras.
>
> > Deve-se saber usar o "não dê pérolas aos porcos". Imagine você sozinho no
> > meio de uma equipe de cinco pessoas gastando saliva e o time não
> > considerando nem ouvir o que você tem a dizer. Quando isso aconteceu na
> > empresa anterior a essa onde eu trabalho hoje aconteceu, eu procurei um
> > ambiente melhor... troquei de emprego.
>
> > []´s
>
> > Juliano Oliveira
> > Analista Desenvolvedor
> > .Net, C#, Actionscript, Flex, NHibernate
> >http://programandoem.net
> > twitter: @juloliveira - skype: juloliveira
>
> > 2009/6/16 Diogo Menezes <diogolmene...@gmail.com>
>
> >> rsrs realmente Plácido, também escolhi trabalhar com NHibernate e até hoje
> >> ele nunca me deixou na mão pelo contrário.
> >> Tenho sistemas rodando com mais de 1 milhão de usuários e atende numa boa
> >> !!!
>
> >> 2009/6/16 Plácido Bisneto <placido.dine...@gmail.com>
>
> >>> Só pra tu teres uma idéia de como é complicado isso, eu trabalhei num
> >>> projeto que não sabíamos se a base de dados ia ser SQL Server ou PostgreSQL.
> >>> No final, o cliente optou por usar o Oracle. hehehe :D
> >>> Santo NHibernate nessas horas! :D
>
> >>> Plácido Bisneto
> >>> .NET Developer
> >>> Blog:http://cidico.wordpress.com
> >>> OpenControls:http://opencontrols.codeplex.com
>
> >>> 2009/6/16 Diogo Menezes <diogolmene...@gmail.com>
>
> >>>>  Realmente Plácido além de tudo que citamos ainda tem o acoplamento
> >>>> total a uma base de dados.
> >>>> Se um belo dia for necessário mudar a base de dados olha a dor de cabeça
> >>>> formada.
>
> >>>> 2009/6/16 Plácido Bisneto <placido.dine...@gmail.com>
> >>>>> 2009/6/16 Nilo Lima <nilo.acres...@gmail.com>

Giovanni Bassi

unread,
Jun 16, 2009, 9:21:34 PM6/16/09
to dotnetar...@googlegroups.com
Tuca,

Acho que o que está acontecendo é que às vezes algum membro do grupo expressa algum sentimento de frustração com relação a isso. Ele vê tudo saindo torto, um monte de problema acumulado. Ao mesmo tempo, ele está cheio de boas idéias, coisas que sabe que funcionam, e ninguém o ouve.
Mas é aquele negócio: se você quer ficar na empresa, fazer o trabalho de formiguinha, tem que ter paciência mesmo. Concordo com você. Se.


[]'s

Giovanni Bassi
Microsoft MVP, MCSD, MCPD, CSM
Arquiteto de software
http://www.giovannibassi.com


2009/6/16 tucaz <tuc...@gmail.com>

Juliano Oliveira

unread,
Jun 16, 2009, 9:28:28 PM6/16/09
to dotnetar...@googlegroups.com
Tuca,

Acho que um "produto" pode ser bom mesmo sem conseguir vende-lo, são os casos de "realmente seria bom, mas não tenho dinheiro/não posso agora/não dá/qualquer outra coisa". Nesses caso, pelo menos você foi ouvido, chegou-se a conclusão que podem sim ser um bom produto, etc.

O que  chateia é você ser o único em um time que procura soluções e métodos diferentes para tentar ajudar, melhorar o processo/arquitetura/trabalho e tudo que você ouve do time que você está falando besteira, que nunca funciona, que como está é a única solução. Pior ainda é quando o time é formado de pessoas mal formadas que não procuram estudar e melhorar e que acham que do jeito que está tá bom!


[]´s

Juliano Oliveira
Analista Desenvolvedor
.Net, C#, Actionscript, Flex, NHibernate
http://programandoem.net
twitter: @juloliveira - skype: juloliveira


2009/6/16 tucaz <tuc...@gmail.com>

Plácido Bisneto

unread,
Jun 16, 2009, 9:33:43 PM6/16/09
to dotnetar...@googlegroups.com
Esse comodismo que me mata!


Plácido Bisneto
.NET Developer
Blog: http://cidico.wordpress.com
OpenControls: http://opencontrols.codeplex.com


2009/6/16 Juliano Oliveira <jul.ol...@gmail.com>

Régis Soares

unread,
Jun 16, 2009, 9:37:33 PM6/16/09
to dotnetar...@googlegroups.com
Nilo,
 
Vou contribuir também, pois já passei por um problema um pouco parecido há alguns anos e sei como é.
 
Se procura referência para tentar "convencê-los", seguem algumas:
 
 
O livro Patterns of Enterprise Application Architecture (P of EAA) de Martin Fowler é de leitura obrigatória para todos os desenvolvedores IMHO
 
abs
Régis Soares

2009/6/16 Juliano Oliveira <jul.ol...@gmail.com>

Rafael Rosa

unread,
Jun 16, 2009, 9:54:51 PM6/16/09
to dotnetar...@googlegroups.com
Salve,

Infelizmente dependendo do tipo de ambiente essas mudanças não irão acontecer. Se a equipe não se atualiza ou não gosta de mudar, você está num mato sem cachorro. Já tive problemas com pessoal mais velho que tinha parado no tempo ou se prendido aos ensinamentos dos anos 80 e esqueceu de evoluir, tornando qualquer inovação ou mudança de pensamento em tabu. Antes que me xinguem já tive companheiros de equipe mais velhos que me ensinaram muito e abraçavam a mudança, mas isso definitivamente não foi a regra.

Uma abordagem que pode ajudar é você, ao apresentar novas idéias, não apresentá-las num vácuo, teoria pela teoria. Pegue casos reais da sua empresa onde as técnicas que você está propondo poderiam ter ajudado, se possível implemente pequenos pedaços do jeito novo para mostrar como ficaria, apresente problemas reais, como por exemplo, aplicar uma mudança real de regra de negócio quando ela está espalhada entre o banco de dados e a aplicação.

E, talvez, o mais importante: não apresente suas idéias como a salvação da lavoura. Minha experiência (14 anos de janela) e o bom senso me diz que as pessoas se apegam ao código que escreveram e as idéias que implementaram, então ao dizer que tudo que eles estão fazendo está errado, é ruim, é burro, etc, você estará criando barreiras comportamentais que não serão facilmente sobrepostas, mesmo que eles saibam que sua idéia é melhor, pelo mero motivo de não querer dar o braço a torcer, de admitirem o erro, o desconhecimento ou a falta de atualização. Já estive do outro lado, entendo como é pensar assim, e hoje faço de tudo para me desapegar do que escrevo e aceitar mudanças, e as vezes ainda acho difícil.

Um outro conselho é que as vezes é melhor introduzir apenas uma boa idéia à nenhuma. Se você tentar impor o esquema tudo-ou-nada, então terá muito mais chances de perder. Se conseguir apresentar suas idéias de forma "desconectadas", talvez consiga introduzir pelo menos uma delas numa área onde exista menos resistência. Depois, numa outra oportunidade, se sua idéia deu certo, as pessoas estarão mais propensas a ouvi-lo e será mais fácil implementar outro pedaço, e por aí vai. Sucesso no passado é um motivador para mudança, é necessário ganhar a confiança no novo para mudar com segurança, ou pelo menos é assim que muitos funcionam. É um trabalho árduo, mas algumas pessoas gostam de fazê-lo, talvez você seja uma delas.

Se tudo der errado, aconselho fazer como eu e o Juliano, mude de emprego :) Nunca é tarde para mandar currículos.

Te desejo boa sorte, você vai precisar. Depois nos conte se conseguiu mudar algo ou não.

Atenciosamente,
Rafael Rosa
www.rafaelrosafu.com
www.rubyinside.com.br

Rafael Noronha

unread,
Jun 16, 2009, 10:02:19 PM6/16/09
to .Net Architects
Meus 0,02.

Uma boa estratégia de persuação nem sempre deve focar em termos
técnicos.
Se o pessoal não estudou para saber aquilo que é óbvio para quem
estudou, o negócio é usar de outras armas.

Apele para valor de negócio.
Más escolhas técnicas não se limitam a jogar uma arquitetura no lixo.

As consequências dessas más escolhas resultam em débito técnico.
O reflexo do débito técnico dói no bolso da empresa, com a perda de
competitividade e de eficiência.

Aí os projetos atrasam, os bugs aparecem em produção, a rotina de
trabalho não é saudável, e daí pra frente.

[]'s

Rafael Noronha
<a href="http://rafanoronha.net/">http://rafanoronha.net/</a>
follow me: <a href="http://twitter.com/rafanoronha">@rafanoronha</a>

Nilo Lima

unread,
Jun 16, 2009, 11:20:11 PM6/16/09
to dotnetar...@googlegroups.com
Não é bem assim Tucaz,

Estou tentando mudar a forma com que a equipe trabalha pois um dia vou dar manutenção no código deles e isso vai ser caro para mim.
Já trabalhei com equipes que pensavam parecido e tive muitos problemas, por isso tento vender a idéia.
Na verdade existe na equipe pessoas vinda do mundo procedural com Delphi e coisas mais antigas, que trabalham com .Net como se estivessem usando VB6.
Estou sim fazendo trabalho de formiguinha, o primeiro é procurar uma boa bibliografia para justificar idéias.

Giovanni Bassi eu já coloquei para a equipe vários fatores que você expos, teve gente que disse: "Então vamos usar o banco somente como repositório? Isso é um absurdo!"
Já iniciei o trabalho de formiga e vou me controlar para engolir vários sapos e provar que a técnica tal é mais produtiva.

Obrigado a todos pela colaboração.

2009/6/16 tucaz <tuc...@gmail.com>

tucaz

unread,
Jun 16, 2009, 11:41:38 PM6/16/09
to .Net Architects
De verdade, eu sei que colocar as regras na aplicação é uma prática
melhor do que no banco. Mas no banco funciona também! Afinal, tratar
dados é o que ele faz de melhor. Não existe só uma saída. Sai mais
barato pra você dar manutenção numa aplicação com regras na aplicação,
mas e pro resto do time? Será que se somar tudo o valor economizado
não é maior usando as regras no banco?

Esse tipo de argumentação é de difícil sustentação. É praticamente
impossível colocar em números esse tipo de custos. Muito do nosso
mundo é achismo.

Outra coisa que é complicada de discutir é algo que vi em outro
tópico, mas que acabamos esbarrando aqui também. Alguém disse e
defendeu (talvez mais que uma pessoa, não lembro) que DDD é muito mais
fácil de manter, mas quantas pessoas aqui trabalharam na manutenção de
um projeto que usasse DDD pra saber que é mais fácil e mais barato? A
maioria das pessoas aqui nunca tinha ouvido nem falar no assunto há
alguns meses atrás e de um dia pro outro acham que o negócio é mais
fácil de manter, baseados em que?

Eu estudo esse treco tem cerca de um pouco mais de um ano. Até agora
consegui executar um projeto que possa ser considerado grande e onde a
escolha da arquitetura faz diferença. Não estou mais nele e não sei
como anda a manutenção. Construi um negócio que espero que seja bom,
mas a bomba ta na mão de outras pessoas agora. Essa é minha
experiência e até agora não consigo avaliar se vale a pena ou não no
que diz respeito a manutenção.

Muitos de nós usam o discurso do baixo custo de manutenção pra
defender o uso desse tipo de arquitetura, mas quantos realmente
trabalharam na manutenção de um software a ponto disso fazer
diferença? Quantos permanecem na mesma empresa por mais de um ano?

Não quero ser o do contra aqui pessoal, mas estamos deixando a parte
lógica da computação e entrando muito na área do romantismo e do
achismo. Estamos deixando o lado emocional e a vontade de coisas novas
ficarem acima do nosso raciocinio lógico. É muito fácil falar de usar
alguma coisa nova e na hora que algum problema aparecer (e vão
aparecer), sair fazendo gambiarra por preguiça de atualizar um teste
ou refatorar muitas linhas de código.

Att.,
Antonio Carlos Zegunis Filho
http://blog.tucaz.net

On Jun 16, 10:20 pm, Nilo Lima <nilo.acres...@gmail.com> wrote:
> Não é bem assim Tucaz,
>
> Estou tentando mudar a forma com que a equipe trabalha pois um dia vou dar
> manutenção no código deles e isso vai ser caro para mim.
> Já trabalhei com equipes que pensavam parecido e tive muitos problemas, por
> isso tento vender a idéia.
> Na verdade existe na equipe pessoas vinda do mundo procedural com Delphi e
> coisas mais antigas, que trabalham com .Net como se estivessem usando VB6.
> Estou sim fazendo trabalho de formiguinha, o primeiro é procurar uma boa
> bibliografia para justificar idéias.
>
> Giovanni Bassi eu já coloquei para a equipe vários fatores que você expos,
> teve gente que disse: "Então vamos usar o banco somente como repositório?
> Isso é um absurdo!"
> Já iniciei o trabalho de formiga e vou me controlar para engolir vários
> sapos e provar que a técnica tal é mais produtiva.
>
> Obrigado a todos pela colaboração.
>
> 2009/6/16 tucaz <tuca...@gmail.com>

tucaz

unread,
Jun 16, 2009, 11:42:38 PM6/16/09
to .Net Architects
Nilo, o caminho é esse mesmo. Faça devagar e bem feito. Faça de pouco
em pouco e se você tiver paciência as coisas tendem a melhorar. Não
adianta ser radical. Radicalismo total nunca é bom em nada.

Att.,
Antonio Carlos Zegunis Filho
http://blog.tucaz.net

> Antonio Carlos Zegunis Filhohttp://blog.tucaz.net
> ...
>
> read more »

Giovanni Bassi

unread,
Jun 16, 2009, 11:54:06 PM6/16/09
to dotnetar...@googlegroups.com
Oi Tuca,

Não só no caso do DDD, mas de diversas outras escolhas, como a de regras no BD e chaves composta, eu confirmei diversas vezes que o foco em boas práticas e princípios dão resultado. Já vi sim softwares que cresceram para morrer, e outros que cresceram para viver, e as preocupações que estamos expressando, na minha experiência, de fato melhoram os resultados.
Até por já ter errado muito, sei o que não é bom. E regra no banco é um exemplo. Chave composta é outro. Mas já errei também de fazer carga de dados fora do BD, o que matou a performance, e por isso fiz a ressalva.
Não costumo falar sobre o que eu não experimentei ou pesquisei com devido aprofundamento. E quando o faço, costumo usar termos como "parece que isso funciona", ou "pode ser que...".


[]'s

Giovanni Bassi
Microsoft MVP, MCSD, MCPD, CSM
Arquiteto de software
http://www.giovannibassi.com


2009/6/17 tucaz <tuc...@gmail.com>

Rafael Noronha

unread,
Jun 17, 2009, 12:05:10 AM6/17/09
to .Net Architects
Muito interessante a sua colocação Tuca.
Vale refletir sobre.

Eu penso de maneira parecida, inclusive escrevi algo semelhante há
dois meses atrás:
http://rafanoronha.net/os-meios-possuem-um-fim/

[]'s
Rafael Noronha
http://rafanoronha.net
http://twitter.com/rafanoronha

Kemps Vieira

unread,
Jun 17, 2009, 12:11:32 AM6/17/09
to dotnetar...@googlegroups.com

Nilo, vou contribuir tb com mais um artigo do Martin Fowler!

 

Inversion of Control Containers and the Dependency Injection pattern - http://martinfowler.com/articles/injection.html

 

Acredito que para um equipe de desenvolvimento crescer e ajudar uma empresa crescer também, o mínimo que as pessoas precisam é se dedicar no auto-conhecimento e quando falamos de tecnologia isso se torna ainda mais complicado, pq a cada dia tem-se algo novo e os nossos sistemas sempre vão ficando velhos e obsoletos.

 

Pode ter certeza, essas mesmas pessoas que hoje em dia rejeitam a mudança de paradigma, amanhã estarão ligando pra vc “DESESPERADAS” qdo forem trocar de emprego ou forem demitidas, como do tipo: “...cara, preciso de uma ajuda urgente, vc manja de .Net, Unity, ASP.Net MVC, Linq, NHiber, Extensions Methods, etc... Como faço isso e aquilo?”

 

E assim a vida segue no nosso mundo e as coisas infelizmente e muitas vezes no Brasil sempre caminham um pouco mais devagar, é claro não podemos esquecer dos imbecis dos Gerentes de Projetos que contribuem para isso, não tendo o mínimo de discernimento para ao menos assumir o risco junto com a equipe, incentivar quem tem potencial e muitas vezes incentivar e acreditar que pelo menos um POC poderá ser feito para tentar validar uma nova arquitetura candidata ou mesmo mudar um paradigma para melhor....

 

T+

 

Kemps A. Vieira

System Architect

MCPD Enterprise

<br

Daniel Moreira Yokoyama

unread,
Jun 17, 2009, 12:55:00 AM6/17/09
to dotnetar...@googlegroups.com
Tuca, eu acho que vc tá esquecendo o papel do Arquiteto no meio dessa coisa toda.
 
Manutenção é triste e, pode ser que não tenha sido assim com você, mas eu já fui chamado não uma nem duas vezes pra fazer um sisteminha virar um sistemão. E nessas horas é muito cruel encontrar coisas desse tipo (regras no banco e completo desuso de tudo quanto é boa prática que conhecemos) e ouvir dos caras que fizeram a seguinte justificativa: "Era só um sisteminha".
 
E lá vai eu trazer pra aplicação toda a inteligência distribuída em centenas de stored procedures só pra migrar o banco de sql pra Oracle. Pior é ouvir todo mundo perguntando pq eu não simplesmente recriava as SP's no Oracle. Se tem algo que aprendi bem foi que Banco de dados só serve pra isso: servir dados.
 
Eu sequer apliquei qualquer coisa em DDD. Não fazem dois meses que ouvi falar a respeito. Mas o uso dele faz completo sentido uma vez que você entende o seu fim. E pra mim, tudo o que servir pra facilitar a leitura e manutenção do código, ainda que seja somente pra esse fim, eu já tô comprando. Pois apanhei muito em dar manutenção em código de quem não usava qualquer prática enquanto que dar manutenção no meu próprio código sempre foi tranquilo.
 
Não que eu nunca precisei fazer algum refactoring aqui ou ali... mas quem desenvolve sempre sabe o quão pior poderia ser se não tivesse feito direito.
 
Atenciosamente,

Daniel Moreira Yokoyama.

"I am putting myself to the fullest possible use, which is all I think that any conscious entity can ever hope to do."
(HAL 9000)



2009/6/17 tucaz <tuc...@gmail.com>

Luiz Carlos Faria

unread,
Jun 17, 2009, 1:14:35 AM6/17/09
to dotnetar...@googlegroups.com

Desculpem a demora,

 

Acredito que eu seja realmente o único a não concordar com a opinião dos que postaram seus comentários a respeito do assunto.

 

Basicamente acompanho diversas gerações de sistemas e já faz muito tempo que tenho isso muito claro em meu pensamento:

Independente da aplicação, das regras de negócio, o que faz realmente sentido para o cliente são os dados.

 

                Uma estória para descontrair:

Crie um cenário onde você tenha dois datacenters :

O fictício e recém criado “Datacenter A” possui todas as suas regras de negócio enquanto o “DataCenter B” possui as bases de dados da sua empresa.

Agora imagine receber uma carta de um grupo terrorista informando: “Vamos destruir um dos seus datacenters”.

Tendo como premissa que a ação terrorista será algo inevitável, você torceria para que qual dos dois fosse danificado?

 

Um pensamento:

Os meios e a metodologia usada para escrever os manuscritos, pergaminhos, hieróglifos, etc podem ter se perdido, mas o importante é o que tais representações de informação trouxeram.

 

As aplicações vem, as aplicações vão, linguagens, plataforma etc. Tudo vem e vai exceto os dados, o menor ponto de mudança ainda é a estrutura de dados, inevitavelmente. Não só pelo seu valor, mas pelo que eles representam em si.  O conteúdo tem valor infinitamente maior do que o canal de processamento.

 

Qual bom profissional não entenderia todo o contexto de uma aplicação apenas em olhar para um banco de dados bem modelado?

 

Sei perfeitamente que o tema em questão está relacionado apenas ao problema das PK’s Compostas, no entanto a abordagem que se tem tido sobre a função do banco de dados em aplicações OO está fora do que eu consigo enxergar como saudável.

 

Lembrando do conceito de divisão de responsabilidades, encaro que  o banco é responsável pela sanidade dos dados armazenados nele. Portanto, para mim, existem regras que devem ser aplicadas a este contexto.

Não estou falando de processamento de negócio, entretanto se alguém encarar uma constraint (seja ela qual for) como uma regra de negócio, então eu sou a favor de regras de negócio no banco sim.

 

Na questão das chaves primárias compostas, esta é uma boa prática de modelagem de dados. Existem recomendações referentes às implementações de ORM’s que dizem para usar sempre chaves burras.

Ao meu ver essa não é uma boa prática, é apenas um facilitador. De acordo com o contexto vale a pena. Depende diretamente da “política” da empresa (política formal ou informal) para modelagem.

 

É evidente e não sou tolo a ponto de discordar dos ganhos (no desenvolvimento) usando chaves burras, no entanto não acho justo.

 

Ao meu ver, as ferramentas deveriam suportar tal implementação de forma satisfatória. Não é meu o problema se uma ferramenta não suportar alguma boa prática de modelagem, é problema da ferramenta. Essa forma de modelar para mim é um workaround “politicamente não tão incorreto” porque já virou “jurisprudência”.

 

Neste caso específico eu nem faço tanta questão, mas a minha indignação vem em função de alguns problemas de infra que tive no passado por causa desta linha de raciocínio.

 

Enquanto o repositório, banco de dados no caso, não puder ser totalmente abstraído, ele não será. Esta é a minha visão, um tanto radical, conservadora, mas para mim muito sensata.

 

 

Atenciosamente

Luiz Carlos Faria

 

 

De: dotnetar...@googlegroups.com [mailto:dotnetar...@googlegroups.com] Em nome de Nilo Lima
Enviada em: quarta-feira, 17 de junho de 2009 00:20
Para: dotnetar...@googlegroups.com
Assunto: [dotnetarchitects] Re: Chave primária única x Chave primária composta

 

Não é bem assim Tucaz,



__________ Informação do ESET Smart Security, versão da vacina 4160 (20090616) __________

A mensagem foi verificada pelo ESET Smart Security.

http://www.eset.com

Daniel Moreira Yokoyama

unread,
Jun 17, 2009, 1:21:11 AM6/17/09
to dotnetar...@googlegroups.com
Eu concordo que não se pode pegar um pattern, framework ou whatever e usar por usar.
Inclusive não é esse lado que eu estou defendendo no e-mail anterior. Quando falo de usar "tudo quanto é boa prática que conhecemos" eu falo das que realmente se aplicam no contexto da implementação.
 
Uma coisa eu tenho certeza "Alta coesão e baixo acoplamento" se aplica em qualquer lugar. E, se repararmos bem, é o princípio de tudo. Afinal, é na hora de desacoplar que você identifica pontos onde pode inserir Injeção de dependência, pra não citar outros exemplos que cabem aqui.
 
Se você começar por aí, vc vai saber aonde cada recurso é útil e aplicável. E, pelo menos na minha interpretação, é onde você entende que o lugar de código é no código... não no banco.

Atenciosamente,

Daniel Moreira Yokoyama.

"I am putting myself to the fullest possible use, which is all I think that any conscious entity can ever hope to do."
(HAL 9000)



2009/6/17 Rafael Noronha <rafan...@gmail.com>

Daniel Moreira Yokoyama

unread,
Jun 17, 2009, 1:48:33 AM6/17/09
to dotnetar...@googlegroups.com
Luiz,
 
Existe uma diferença gritante entre um "Banco bem modelado" e um sistema "bem modelado" por que normalmente o modelo que se aplica a um não é o mesmo que se aplica ao outro. Então o que você disse a respeito da ferramenta não suportar uma boa prática de modelagem é um mal-entendido. Ela suporta, sim, as boas práticas de modelagem. Mas no modelo que ela implementa. Um banco de dados pode ser bem-modelado no relacional e o sistema que o consome pode ser bem modelado também, mas no modelo de objetos.
 
Mas o banco, independente de como foi modelado, acaba por fazer parte do sistema. Então lidar com a diferença entre os modelos acaba por fazer parte do nosso trabalho.
 
Em meus sistemas não uso campos de negócio para chave-primária, e o uso de constraints pode até indicar uma certa aplicação de regra de negócio no DB, mas eu não enxergo assim, é somente "modelo" (no caso, relacional).
 
Vê? Estou lidando com, no mínimo, dois modelos. (E podem haver outros, por exemplo, em outros sistemas consumindo o mesmo banco para contextos diferentes).
 
Tabelas normalizam dados, Objetos normalizam comportamento, e se você quiser usar somente um deles como lead-model pra todo o resto, você vai ter problemas.
 
Quanto a entender o contexto de uma aplicação apenas observando um banco de dados bem modelado... eu diria que aí você tá esquecendo de muita coisa. Nem tudo em um sistema é pura persistência de dados. Você tem componentes. Você tem Layers, Tiers... e, embora isso não mude o "contexto" do modelo dos seus dados, eu prefiro ver um sistema bem modelado (onde você pode ver um panorama bem mais abrangente de objetos, componentes e camadas - pra não falar dos recursos externos) do que ver um MER.
 
O banco no fim das contas vai ser apenas um repositório deste  modelo, e como ele vai ser modelado normalmente não faz muito impacto no fim das contas.

Atenciosamente,

Daniel Moreira Yokoyama.

"I am putting myself to the fullest possible use, which is all I think that any conscious entity can ever hope to do."
(HAL 9000)



2009/6/17 Luiz Carlos Faria <luizcar...@gmail.com>

Rodrigo Vieira

unread,
Jun 17, 2009, 2:31:29 AM6/17/09
to dotnetar...@googlegroups.com
Bem, essa thread ficou enorme muito rápido, eu não pude ler todas
mensagens, então desculpa se alguém aqui colocou argumentos iguais. De
qq forma, aqui vai minha experiência com chaves compostas, de
trabalhos anteriores:

- Fica bem mais complicado escrever JOINs etc, pq vc tem que ficar
checando quais são os campos-chave em cada tabela e lembrar de
colocá-los em cada JOIN;
- Se um determinado valor que faz parte de uma chave composta muda em
uma tabela, vc tem que propagar essa mudança em todas tabelas-filhas
(por exemplo, alguem por algum motivo muda de CPF);
- Com chaves naturais ou compostas vc pode acabar se amarrando, por
exemplo no sistema em que trabalhei a chave primaria para usuarios era
algo equivalente a CPF no Brasil. Aí um dia surgiu uma situação onde a
gente ia cadastrar crianças como usuários (era um plano familiar de
telefonia), e tais crianças não tinham CPF. Tivemos que gastar 1
semana só alterando o banco de dados e o sistema todo pra comportar
isso.

E no caso de sistemas web, acho que querer trabalhar com chaves
compostas seria um verdadeiro inferno, se é que funcionaria. Mas isso
não é problema do BD, eu sei.

Por outro lado, os argumentos que vejo em favor de chaves compostas e
naturais são em geral em nome da pureza estética do BD e do modelo ER
(lembro que meu prof de BD da faculdade era um deles). Mas posso estar
enganado.

Sobre a questão de sprocs, o grande problema a meu ver é
testabilidade e dificuldade de manter e debugar. Não sei na empresa de
vcs mas na minha nenhum programador fica feliz quando tem que
consertar bug em stored procedure! Mas dependendo do caso pode haver
vantagem em termos de desempenho (p. ex. um volume absurdo de dados),
então acho que não dá pra proibir o seu uso, apenas ser econômico
quanto a isso.

2009/6/17 Nilo Lima <nilo.a...@gmail.com>:

Juliano Oliveira

unread,
Jun 17, 2009, 7:26:00 AM6/17/09
to dotnetar...@googlegroups.com
Luiz,

Desculpa mas defender chaves primárias compostas hoje em dia não é uma boa prática.
Me diga uma um caso onde você indica chave composta como a melhor solução que eu lhe garanto, aparecerão outros 200 argumentos e soluções mais eficiêntes com chaves simples.

"As aplicações vem, as aplicações vão, linguagens, plataforma etc"

Os que são bons não! Os que são bons duram muuuuuiiiiittttoooo... é só olhar pro Cobol e tudo que há por trás dele.

Regras em banco?! 
Podem existir casos em que deva realmente ser necessário mas é uma minoria.

Nilo,

Você ainda não disso o porquê de o time querer usar chaves compostas.

[]´s

Juliano Oliveira
Analista Desenvolvedor
.Net, C#, Actionscript, Flex, NHibernate
http://programandoem.net
twitter: @juloliveira - skype: juloliveira


2009/6/17 Luiz Carlos Faria <luizcar...@gmail.com>

Desculpem a demora,

Nilo Lima

unread,
Jun 17, 2009, 8:01:34 AM6/17/09
to dotnetar...@googlegroups.com
O grupo acha que o banco fica mais "Normalizado" usando chaves compostas.

2009/6/17 Juliano Oliveira <jul.ol...@gmail.com>

Juliano Oliveira

unread,
Jun 17, 2009, 8:04:57 AM6/17/09
to dotnetar...@googlegroups.com
O que seria "Normalizado"?


[]´s

Juliano Oliveira
Analista Desenvolvedor
.Net, C#, Actionscript, Flex, NHibernate
http://programandoem.net
twitter: @juloliveira - skype: juloliveira


2009/6/17 Nilo Lima <nilo.a...@gmail.com>

Nilo Lima

unread,
Jun 17, 2009, 8:08:15 AM6/17/09
to dotnetar...@googlegroups.com
Para a equipe um banco com chaves candidatas transformadas na chaves reais do sistema.

Obrigado pela colaboração

2009/6/17 Juliano Oliveira <jul.ol...@gmail.com>

Rodrigo Vieira

unread,
Jun 17, 2009, 8:16:48 AM6/17/09
to dotnetar...@googlegroups.com
Talvez eles achem chaves compostas mais elegantes, esteticamente
agradáveis etc, mas a normalização não é afetada pelo uso de chaves
primárias simples (ID).

Dando uma relembrada nas formas normais
(http://pt.wikipedia.org/wiki/Normaliza%C3%A7%C3%A3o_em_banco_de_dados)
não vejo nada ali que contradiga isso.

Mas talvez a melhor abordagem seja vc checar nos sistemas atuais de
vcs quais problemas as chaves compostas tem trazido, em cima daquilo
que foi mencionado nessa discussao. Deve ser facil achar tais
problemas (por exemplo, maior complexidade do codigo que tem que ficar
lidando com varios valores pra identificar cada entidade). Se por
outro lado vc nao achar problema algum, talvez eles tenham razão...

- Rodrigo


2009/6/17 Nilo Lima <nilo.a...@gmail.com>:

André Carlucci

unread,
Jun 17, 2009, 8:48:03 AM6/17/09
to dotnetar...@googlegroups.com
Fala Nilo,
 
Na minha entrevista na Thoughtworks me perguntaram algo bem parecido com essa sua situação. Uma das respostas-chave que me deram o contrato foi justamente: depende do domínio e o tamanho da aplicação. Nenhuma tecnologia/framework/idéia serve pra tudo.
 
1 - Sobre chaves compostas: dependendo da tabela, faz muito mais sentido do que uma identity alien só pra ficar tudo com id. Tem coisa que não precisa de id. Na dúvida, o DBA é muito mais indicado pra decidir do que você.
 
2 - Sobre procedures: independência de banco de dados é muito bonito na teoria ou em "produtos" onde a base é meramente um repositório mesmo. Na prática, um sistema de grande porte NUNCA vai trocar de banco de dados, até porque as consultas são tão complexas que não há ORM que mapeie isso.
 
Não é por isso que não vamos usar um NHibernate da vida para fazer CRUD, mas usar o mesmo pra relatórios complexos é insano. Uma procedure feita cuidadosamente por alguém especialista em BD vai ser infinitamente mais rápida e efeciente do que um desenvolvedor com linq, hql ou mesmo sql puro. E vai ser mais simples pro desenvolvedor também! Stored Procedures são com certeza o melhor caminho em alguns casos, mas não pra todos também.
 
Nilo, tome cuidado com essa procura de bibliografias. A gente acaba se cegando querendo achar algo que nos agrade. Se tem 1 artigo obscuro ou um post do Mr. India dizendo o que a gente quer escutar, a gente toma aquilo como bíblia.
 
Tomar decisões baseadas em boas práticas é legal, mas nunca esqueçam da sua experiência. "Martin Fowler falou" não funciona como argumento, mesmo porque ele não é deus e muito menos está trabalhando no seu projeto.
 
André Carlucci
2009/6/17 Rodrigo Vieira <rodr...@gmail.com>



--
André Carlucci

Eduardo Miranda

unread,
Jun 17, 2009, 8:49:23 AM6/17/09
to dotnetar...@googlegroups.com
Rodrigo colocou bons argumentos práticos que podem te ajudar.
 
Outro ponto que acontece na prática é que muitas entidades não têm chave de negócios reais. Isto pode ser mostrado na prática em um simples ERM de 10 a 20 entidades.
 
Alguns exemplos:
- Endereços (não tem chave candidata)
- Produto, nem sempre eles têm um código e nem sempre este código é único
- Linhas de uma ordem de venda (alguém tem uma boa chave que não envolva "número da linha"?
 
Até coisas mais óbvias como cidade, qual a chave? Nome + Estado? Cidades mudam de nome ...
 
Ou seja, na prática, mesmo em um modelo que tenta utilizar chaves de negócio, utilizam muito mais chaves sintéticas do que imaginamos.

 
2009/6/17 Rodrigo Vieira <rodr...@gmail.com>

Emmanuel G. Brandão

unread,
Jun 17, 2009, 9:04:46 AM6/17/09
to dotnetar...@googlegroups.com
André,

Trocar de BD realmente é raro, mas para empresas que desenvolvem produtos de "caixinha" é essencial ser multi-banco.
Trabalhei em uma empresa que desenvolvia em Progress, o BD é nativo, então era bom! Mas chegavam em clientes que queriam Oracle, o cara não conseguia justificar, na maioria das vezes acho que era por conhecer, por ter um legado, ou por acreditar no "Unbreakable"... Mas até que o conector Progress com Oracle funcionava legal.
Daí quando saiu o SQL Server 2005, alguns gerentes de segurança começaram a acreditar na melhoria do produto, na segurança... e queriam SQL Server! Daí a coisa começou a pegar pro nosso lado... Hehehe não tínhamos ORM! Afinal, era Progress...

Mas eu dei muita risada agora com o que você disse: "Martin Fowler falou" não funciona como argumento, mesmo porque ele não é deus e muito menos está trabalhando no seu projeto. Imaginei virar a cadeira agora, depois de queimar a cabeça aqui, e perguntar: E aí Fowler, tu falei aquilo de SK, e ae? O que a gente faz? Resolve isso aí pra mim que eu vou tomar um café... Hahaha
 
Brandão, Emmanuel G.
CSM
msn: egomes...@hotmail.com
http://egomesbrandao.blogspot.com


2009/6/17 André Carlucci <andrec...@gmail.com>

Rodrigo Vieira

unread,
Jun 17, 2009, 9:19:12 AM6/17/09
to dotnetar...@googlegroups.com
André,

Concordo com muitos dos seus argumentos mas tb é preciso ver com
atenção essa idéia de que sproc é muito mais rápido do que comandos
SQL vindo do sistema. Tem muito estudo aí mostrando que isso é meio
lenda (assim como a lenda da maior segurança).

Claro, um especialista em BD vai saber escrever queries melhor do que
um programador que não sabe o que é um left outer join, mas em geral o
chapéu de especialista de BD e de programador fica na cabeça de uma
mesma pessoa, então essa pessoa que pode escrever uma boa sproc tb
pode transferir essa boa consulta para dentro do sistema, e evitar o
problema de ter lógica do sistema espalhado e mais difícil de testar.

O que tenho visto na prática nas empresas é o uso cada vez menor de
sprocs e user defined functions em código novo...vcs não?

- Rodrigo

2009/6/17 André Carlucci <andrec...@gmail.com>:

Daniel Moreira Yokoyama

unread,
Jun 17, 2009, 9:40:07 AM6/17/09
to dotnetar...@googlegroups.com
André,
 
Discordo.
 
"Depende do tamanho da aplicação" é o tipo de argumento que mais me deu trabalho. Pois foi justamente quando o tamanho da aplicação mudou que me chamaram pra resolver os problemas.
 
Um dos projetos que tenho atualmente era, inicialmente, apenas um controle de eventos onde os usuários poderiam visualizar uma agenda de eventos e obter informações como local e datas.
 
O cliente então resolveu pedir pra incluir um módulo administrativo onde um usuário administrador poderia colocar os dados como Budget e custo previsto e realizado afim de ter relatórios a respeito dos eventos (mais tarde ainda incluíram o número de PAX, e o gasto com cada ítem do evento: espaço, buffet, etc etc).
 
Logo após o cliente pediu pra incluir um novo módulo de pesquisa de satisfação a ser enviada para todos os convidados do evento. A pesquisa precisaria ser composta de acordo com o evento em questão.
 
E por aí foram as mudanças até que atualmente eu estou me vendo com algo muito mais abrangente e complexo do que era inicialmente. O escopo do projeto precisou ser reanalizado várias vezes.
 
Quando me chamaram a coisa já tinha crescido demais para o modelo que adotaram na primeira versão (que, achava-se, por tratar de coisa simples, não precisavam caprichar no modelo).
 
1. Ficar tudo com uma chave ID é bem útil pq no fim das contas ter um ID que vc possa esperar existir em todas as tabelas facilita muito o desenvolvimento e já faz com que ninguém precise se preocupar com chaves-compostas (por exemplo). Além disso ainda permite que seus objetos de negócio (sejam objetos master, objetos transacionais ou objetos organizacionais) compartilhem uma interface básica (possuem um ID).
 
2. Na prática existem sim, sistemas complexos que mudam o banco. Independência de banco de dados não é bonita só na teoria. Eu nunca usei o NHibernate mas já criei modelos de objetos complexos com dados distribuídos em N tabelas.
 
O máximo que precisei usar foi Join mas apenas para criar uma mesma Entidade (Médico, por exemplo, quer distribuía seus dados em várias tabelas relacionadas em 1-1).
 
Se o modelo é bem feito (como eu entendo por um modelo bem feito, e que alguns podem discordar) você não vai ter consultas complexas. Join faz parte por causa da normalização (eu só uso joins como no exemplo que eu dei... todos os meus joins no sistema são entre tabelas relacionadas 1-1).
 
"Martin Fowler falou" é o pior argumento a se adotar na hora de tentar convencer sua equipe. O que você precisa entender é o conceito. Se o conceito for bom e te convencer vc já tem o argumento necessário.
 
Atenciosamente,

Daniel Moreira Yokoyama.

"I am putting myself to the fullest possible use, which is all I think that any conscious entity can ever hope to do."
(HAL 9000)



2009/6/17 André Carlucci <andrec...@gmail.com>

André Carlucci

unread,
Jun 17, 2009, 10:08:53 AM6/17/09
to dotnetar...@googlegroups.com
Fala Brandão,
 
Concordo plenamente, produtos de caixinha tem que ser multi-banco. Qual banco é melhor é a mesma guerra religiosa de qual linguagem é melhor e no final das contas o cliente quer usar o que ele já tem na T.I. dele :)

2009/6/17 Emmanuel G. Brandão <egomes...@gmail.com>



--
André Carlucci

Luiz Carlos Faria

unread,
Jun 17, 2009, 10:13:30 AM6/17/09
to dotnetar...@googlegroups.com

Daniel,

 

Acho que a melhor forma de responder é usando seu texto e respondendo abaixo:

 

 

 

Existe uma diferença gritante entre um "Banco bem modelado" e um sistema "bem modelado" por que normalmente o modelo que se aplica a um não é o mesmo que se aplica ao outro. Então o que você disse a respeito da ferramenta não suportar uma boa prática de modelagem é um mal-entendido. Ela suporta, sim, as boas práticas de modelagem. Mas no modelo que ela implementa. Um banco de dados pode ser bem-modelado no relacional e o sistema que o consome pode ser bem modelado também, mas no modelo de objetos.

 

Neste caso não há mal-entendido, como eu disse:

Ao meu ver, as ferramentas deveriam suportar tal implementação de forma satisfatória. Não é meu o problema se uma ferramenta não suportar alguma boa prática de modelagem, é problema da ferramenta. Essa forma de modelar para mim é um workaround “politicamente não tão incorreto” porque já virou “jurisprudência”.

Reformulando a parte principal desse parágrafo:  “Não é meu o problema se uma ferramenta não suportar alguma boa prática de modelagem”.

Independente de ser boa ou ruim, é uma prática que ainda não foi e não será abolida. Se é boa ou ruim, vou voltar ao assunto no próximo email. Envio ainda hoje.

 

 

Mas o banco, independente de como foi modelado, acaba por fazer parte do sistema. Então lidar com a diferença entre os modelos acaba por fazer parte do nosso trabalho.

Concordo. Se eu mudar meu questionamento acho que vai ficar mais claro: E se meu modelo relacional for imutável? Sabemos que nunca é, mas e se fosse? Quem aparece com a pretensão de resolver o meu problema para o mapeamento é o ORM em questão. Eu tenho total ciência das minhas necessidades, alguns ORM’ que não satisfazem minhas necessidades. Este não é o caso do NHibernate, ele me atende razoavelmente bem.

 

 

Em meus sistemas não uso campos de negócio para chave-primária, e o uso de constraints pode até indicar uma certa aplicação de regra de negócio no DB, mas eu não enxergo assim, é somente "modelo" (no caso, relacional).

Agora temos um mal-entendido. Embora estivéssemos falando sobre chaves compostas como primary key, o que eu disse foi a mesma coisa, veja:

Lembrando do conceito de divisão de responsabilidades, encaro que  o banco é responsável pela sanidade dos dados armazenados nele. Portanto, para mim, existem regras que devem ser aplicadas a este contexto.

Não estou falando de processamento de negócio, entretanto se alguém encarar uma constraint (seja ela qual for) como uma regra de negócio, então eu sou a favor de regras de negócio no banco sim.

 

 

 Vê? Estou lidando com, no mínimo, dois modelos. (E podem haver outros, por exemplo, em outros sistemas consumindo o mesmo banco para contextos diferentes).

Sim, eu concordo.

 

 

Tabelas normalizam dados, Objetos normalizam comportamento, e se você quiser usar somente um deles como lead-model pra todo o resto, você vai ter problemas.

Concordo com ressalvas: Existem cenários em que não há problema algum.

 

 

Quanto a entender o contexto de uma aplicação apenas observando um banco de dados bem modelado... eu diria que aí você tá esquecendo de muita coisa. Nem tudo em um sistema é pura persistência de dados. Você tem componentes. Você tem Layers, Tiers... e, embora isso não mude o "contexto" do modelo dos seus dados, eu prefiro ver um sistema bem modelado (onde você pode ver um panorama bem mais abrangente de objetos, componentes e camadas - pra não falar dos recursos externos) do que ver um MER.

Lendo seu texto me lembrei de mais um item: A configuração. Pronto! Vendo um MER e a configuração de uma aplicação bem modelada daria para fazer um big picture da aplicação.

Eu não estava ignorando a modelagem da aplicação, apenas citando e reiterando a importância de um banco bem modelado.

O que eu queria dizer, em termos práticos é que um MER bem feito consegue por si só fazer dos dados informação.

 

 

O banco no fim das contas vai ser apenas um repositório deste  modelo, e como ele vai ser modelado normalmente não faz muito impacto no fim das contas.

Eu não concordo, se voltarmos à estória do terrorista, a resposta à pergunta final mostra a importância dos dados. Já vi e já tive muita dor de cabeça por conta de modelos relacionais equivocados e desnecessariamente complexos.

 

 

De: dotnetar...@googlegroups.com [mailto:dotnetar...@googlegroups.com] Em nome de Daniel Moreira Yokoyama
Enviada em: quarta-feira, 17 de junho de 2009 02:49
Para: dotnetar...@googlegroups.com
Assunto: [dotnetarchitects] Re: Chave primária única x Chave primária composta

 

Luiz,

Luiz Carlos Faria

unread,
Jun 17, 2009, 10:15:48 AM6/17/09
to dotnetar...@googlegroups.com

“Tomar decisões baseadas em boas práticas é legal, mas nunca esqueçam da sua experiência. "Martin Fowler falou" não funciona como argumento, mesmo porque ele não é deus e muito menos está trabalhando no seu projeto.”

 

Acaba de ganhar um amigo!!!

André Carlucci

unread,
Jun 17, 2009, 10:17:05 AM6/17/09
to dotnetar...@googlegroups.com
Fala Rodrigo,
 
Sim, aqui cada vez mais a gente substitui SPs por chamadas diretas (via ORM ou específicas para cada banco). Mas quando mexemos nos nossos relatórios que vão em tabelas com terabytes, deixamos as velhas e boas SPs.
 
O problema é que o SQL de cada banco muda muito, especialmente falando de Oracle x Microsoft SqlServer. Tem certas construções que você possui somente em um deles e no outro não, mas que ajudam muito na performance, como certos pacotes de sistema do oracle.
 
Outra coisa é quando você precisa de diversos round trips pra construir um resultado. Caso de relatórios que consultam inúmeras tabelas e que você não consegue juntar tudo em 1 SQL (ou se consegue, fica lento). Usando uma SP, você faz todos os passos dentro do banco, direto, sem um monte de dados ficar indo e vindo da aplicação <-> BD.
 
De novo, depende da aplicação!
 
[]'s
2009/6/17 Rodrigo Vieira <rodr...@gmail.com>
>
> >
>


--
André Carlucci

Luiz Carlos Faria

unread,
Jun 17, 2009, 10:18:41 AM6/17/09
to dotnetar...@googlegroups.com

Mt boa!!!!!

André Carlucci

unread,
Jun 17, 2009, 10:23:27 AM6/17/09
to dotnetar...@googlegroups.com
Daniel,
 
Eu adoro a palavra "depende".
 
Quando falei de grandes sistemas, estava falando de portais, ERPs customizados, sites de e-comerce e outras coisas com milhões de acessos por dia, normalmente enterprise applications e não produtos. Esses aí é bem raro mudar.
 
Concordo que é muito útil ter ID pra cada coisa, por mim a tabela já vinha com ID pronto (o Oracle vem!).
Sobre sua frase:
 
"Se o modelo é bem feito (como eu entendo por um modelo bem feito, e que alguns podem discordar) você não vai ter consultas complexas"
Cara, você com certeza não tem os clientes que eu tenho :)
 
 
2009/6/17 Daniel Moreira Yokoyama <moreira....@gmail.com>
2009/6/17 André Carlucci <andrec...@gmail.com>


--
André Carlucci

Luiz Carlos Faria

unread,
Jun 17, 2009, 10:31:33 AM6/17/09
to dotnetar...@googlegroups.com

O maior legado COBOL no Brasil ainda é das instituições financeiras.

O maior motivador para manterem essa estrutura é: custo.

 

Princípios básicos e plausíveis:

 

Uma instituição financeira existe para gerar lucro.

Se algo funciona, não há problema.

Se algo não funciona, é melhor corrigir ou refazer? O que trouxer menor custo, obvio.

 

Portanto não muda e nem vai mudar tão cedo.

 

Quando falo em custo falo em:

·         Projeto

·         Implantação

·         Manutenção

·         Risco

 

A primeira instituição que parar de funcionar em função de uma migração desse porte tem grande chance de afundar e ainda virar piada na mídia.

Luiz Carlos Faria

unread,
Jun 17, 2009, 10:33:03 AM6/17/09
to dotnetar...@googlegroups.com

Ops... esqueci do conteúdo relevante!! Hehehehe

 

Como disse antes, citei alguns aspectos que uso no banco e disse: Se consideram isso regra de negócio, eu gosto sim.

Basicamente foi isso.

Daniel Moreira Yokoyama

unread,
Jun 17, 2009, 10:39:56 AM6/17/09
to dotnetar...@googlegroups.com
Ok Luiz... acho que estamos nos entendendo.
 
Pra salientar:
 
* Se um framework ORM não satisfaz sua necessidade vc não precisa usá-lo, nem por isso significa que vc não pode implementar seu próprio ORM.
 
* Os dados são importantes... o repositório não é. Se o terrorista atacar não importa que tipo de importancia vc deu aos dados um ou ao sistema... se você não tiver back up não vai te servir de nada eleger algum dos lados como mais importante.

Daniel Moreira Yokoyama

unread,
Jun 17, 2009, 10:41:57 AM6/17/09
to dotnetar...@googlegroups.com

"Se o modelo é bem feito (como eu entendo por um modelo bem feito, e que alguns podem discordar) você não vai ter consultas complexas"

Cara, você com certeza não tem os clientes que eu tenho :)
 
Hehehe... daí o "Se o modelo é bem feito..."

Juliano Oliveira

unread,
Jun 17, 2009, 10:42:38 AM6/17/09
to dotnetar...@googlegroups.com
O Cobol foi um exemplo mais claro e óbvio.
Não é só banco de trabalha por lucros e sempre visando baixos custos.

Se uma empresa (qualquer que seja o ramo da empresa) tem uma história de "sistemas que vem e vão" ou é por que sempre teve um sistema é ruim ou por que a empresa necessita de mudanças e não tem mais essa possibilidade (independente do motivo).

Luiz Carlos Faria

unread,
Jun 17, 2009, 10:57:49 AM6/17/09
to dotnetar...@googlegroups.com

Quanto a criação de um ORM, acho completamente inviável bater chegar sequer próximo do que há no mercado hoje.

É difícil manter investimento nisto.

 

Claro que com uma visão minimalista se consegue um meio termo. Eu já tenho algo do gênero, mas baseado em geração de código.

 

Quanto à questão dos dados x aplicação.

 

A aplicação sempre é o elo fraco nessa história. Afinal, a aplicação é, no final das contas, um ator que engloba diversos papeis dentro de um fluxo de negócio. Portanto, se não existisse aplicação, alguém ou muitos realizariam a tarefa. Assim, é viável recriá-la, pois o conhecimento sobre o processo é algo rotineiro. Não perdendo pessoas, a maioria das aplicações poderiam ser recriadas, e já são.

<br

André Carlucci

unread,
Jun 17, 2009, 10:58:53 AM6/17/09
to dotnetar...@googlegroups.com
hahaha, droga, ok, ok, eu dei a deixa.
 
Vou reescrever assim nós 2 ficamos felizes :)
 
"Se o modelo é bem feito, você vai ter consultas menos complexas do que se o modelo é mal feito"
 
Cara, se você tirar umas frases que a gente joga aqui no mundo geek e trocar o contexto, viramos todos filósofos.
2009/6/17 André Carlucci <andrec...@gmail.com>
2009/6/17 André Carlucci <andrec...@gmail.com>


--
André Carlucci

--
André Carlucci

Daniel Moreira Yokoyama

unread,
Jun 17, 2009, 11:06:55 AM6/17/09
to dotnetar...@googlegroups.com
Hehehe.
 
Não se esqueça da mania que nós, desenvolvedores, temos de criar termos e mantras e tenets pra tudo o que criamos... hehehehehe
 
No fim das contas eu sei que não existe uma regra geral aplicável a tudo. Como você mesmo disse, a palavra "depende" deixa as coisas ainda mais divertidas (ou salgadas).

Daniel Moreira Yokoyama

unread,
Jun 17, 2009, 11:17:54 AM6/17/09
to dotnetar...@googlegroups.com
Ok... Luiz.
 
A importancia dos dados é indiscutível (embora eu continuo a dizer... a supervalorização dos dados não implica na valorização do repositório).
 
Mas ainda que se adote esta filosofia, não é mais fácil criar medidas de segurança que aumentem a tolerância a este tipo de coisas do que simplesmente eleger qual dos dois vc iria prefirir perder?
 
Você não precisa esperar um terrorista mandar uma carta (uma vez que terroristas só mandam cartas nos livros do Dan Brown) pra entender que a melhor forma de garantir a conservação tanto de dados quanto de aplicações é mantendo cópias em lugares separados.
 
Afinal, independente do valor dos dados ninguém quer pagar pra refazer um sistema que já havia sido pago (e, normalmente, caro).
 
Então no fundo sabemos que esta não é uma forma de justificar o uso excessivo dos recursos do Banco.
 
Outra coisa: "Load Balancing" de um servidor de aplicação é viável. De banco não é. (ou então eu estou muito atrasado nos meus estudos).
Fica muito mais fácil vc gerenciar threads, caching e n outros fatores, distribuídos em máquinas paralelas em uma implementação do que em um banco de dados.
Volto a dizer: Na medida do possível deixe o servidor de DB fazer o que ele faz melhor... Servir dados.

Fabio Margarito

unread,
Jun 17, 2009, 1:01:07 PM6/17/09