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

[Nilo Lima]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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:

 

Foreign Key Mapping: http://www.martinfowler.com/eaaCatalog/foreignKeyMapping.html

Identity Field: http://www.martinfowler.com/eaaCatalog/identityField.html

etc: http://www.martinfowler.com/eaaCatalog/

 

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

O grupo acha que o banco fica mais "Normalizado" usando chaves compostas.

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

[Juliano Oliveira]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

“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]

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]

Mt boa!!!!!

[André Carlucci]

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]

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]

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]

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]

"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]

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]

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]

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]

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]

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]

A discussão é interessante, cada profissional vai puxar para o seu
lado, e cada lado tem bons argumentos que fundamentam a sua opinião,
vejo assim:

Para quem modela o sistema usando boas práticas de OO, estes
defenderão a simplicidade das chaves para facilitarem o seu trabalho,
pois o banco é somente um repositório de dados.

Para o Analista de Dados de um banco relacional, onde o material mais
precioso é o dado, este defenderá sempre que possível, chaves que
façam sentido no negócio, nem que estas sejam compostas por outras.

O DBA irá focar no desempenho, segurança e integridade da informação.

Para o profissional de BI, o importante são as visões que possam ser
projetadas da informação armazenada e todo o processo ETL.

E o “coitado” do usuário, ao qual geralmente esquecemos, quer somente
um sistema que faça o que foi pedido e dentro do time to market(http://
en.wikipedia.org/wiki/Time_to_market), o como, geralmente ele não
quem nem saber, desde que atinja suas expectativas.

Acho complicado falar que um lado está errado ou não. Uma centena de
fatores precisam se ponderados(cultura da empresa, quadro de recursos,
tecnologias disponíveis, o legado,etc...), acredito que um meio termo
precisa ser atingindo. O melhor, ao invés de criticar um modelo, é
entender o motivo de ser desta ou daquela forma, e para resolver,
juntar todos e decidir em conjunto. Na última empresa que trabalhei,
fazíamos isso, as vezes não saia da maneira como queríamos, mas
entendíamos o motivo.

Um papel do arquiteto que vejo fundamental é a comunicação, com este
skill ele é capaz de entender todos os lados e montar uma
solução,talvez não a perfeita, mas que resolve da melhor forma o
problema e que todos estejam de acordo.

Infelizmente, quando trabalhamos em empresas, nem sempre teremos o
cenário ideal, temos que conviver com isso, ou mudar de empresa.

Em resumo, “Depende do cenário” :-).

[]’s
Fabio Margarito


On 17 jun, 12:17, Daniel Moreira Yokoyama <moreira.yokoy...@gmail.com>
wrote:

> 2009/6/17 Luiz Carlos Faria <luizcarlosfa...@gmail.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.
>

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

> > composta
>
> > 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.
>
> > 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 <luizcarlosfa...@gmail.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,
>
> > 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
>

> ...
>
> mais »- Ocultar texto das mensagens anteriores -
>
> - Mostrar texto das mensagens anteriores -

[Luiz Carlos Faria]

 

Com relação a estória só queria tirar o foco da questão em si para fazer com que repensasse. Nada demais. O cenário fictício esteve ali para mostrar o caos e gerar uma reflexão sobre a importância de um e de outro. Sem desqualificar nenhum, apenas “medindo forças”.

 

Quanto a ninguém pagar por algo que já havia sido pago: Já vi dois casos, grandes.

 

Quanto a banco, tem load balance sim, podendo escolher se é feito via software ou hardware.

 

Gostaria de lembrar que não sou profissional de banco de dados, Ok?

Só tenho minhas opiniões, um tanto críticas, mas nem tudo é perfeito.

<br

[Daniel Moreira Yokoyama]

Agora, independente do que for melhor nisso tudo, eu realmente fiquei muito curioso a respeito de load balancing entre servidores de banco de dados... gostaria de ver algo a respeito qualquer hora destas.

 

Pra você ver como sempre no meio de discussões como esta nós acabamos sempre aprendendo algo de bom (ainda q continuemos teimosos no assunto em si).

[Allan Clempe]

Daniel,

 

Uma empresa que eu presto serviço faz load balancing entre servidores oracle. Com certeza é possivel, mas não tenho a mínima ideia de como é feito : )

Abraços,

Allan Clempe

[André Carlucci]

Load balance é possível, cada banco se sincroniza com o outro, quase todos os grandes DBs podem fazer isso.

 

A complexidade aparece quando você tem transações distribuidas, ou seja, quando um request de um usuário pode cair em qualquer um dos servidores de banco de dados.

 

Neste caso o nível de complexidade é muito grande e o crescimento horizontal com mais de 2 torna-se inviável. Sobre o crescimento vertical, é a vida.

 

É por isso que o eBay não usa transações. Isso mesmo, não usa, não tem commit, não tem rollback e te garanto que funciona muito bem.

 

 

2009/6/17 Allan Clempe <allan....@gmail.com>

--
André Carlucci

[Luiz Carlos Faria]

Além disso, você tem pacotes que gerenciam e garantem afinidade entre servidores em um contexto transacional.

[Giovanni Bassi]

Qualquer desenvolvimento baseado em particionamento dos dados implica em alguma perda de consistência se quisermos manter a disponibilidade alta. Por isso que grandes bases distribuidas não usam transações, usam mecanismos para desfazer o que foi feito, ou utilizam filas para realizar tarefas, em algo conhecido como BASE.
É o caso em sistemas feitos para a nuvem, como no Azure.
Um pouco mais no assunto:
Base:
http://unplugged.giggio.net/post/Consistencia-na-Nuvem.aspx
Filas no Azure:
http://unplugged.giggio.net/post/Windows-Azure-O-que-sao-Queues-filas.aspx

[]'s

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

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

[Luiz Carlos Faria]

Eu conheço a existência, mas não trato com estes recursos diretamente.

 

Seguem alguns links com informações sobre SQL Server, Oracle e MySQL. Muito interessante.

 

 

Oracle

 

http://www.databasejournal.com/features/oracle/article.php/3666396/Oracle-10gR2-RAC-Load-Balancing-Features.htm

 

http://www.orafaq.com/node/1840

 

http://www.datadirect.com/developer/odbc/odbc_oracle_rac/index.ssp

 

Sql Server

 

http://msdn.microsoft.com/pt-br/library/ms189134.aspx

 

http://technet.microsoft.com/en-us/library/ms191309.aspx

 

MySQL

 

http://www.mysql.com/news-and-events/newsletter/2003-04/a0000000157.html

 

http://www.howtoforge.com/loadbalanced_mysql_cluster_debian (só para exemplificar, o link trata instalações debian)

<br

[Luiz Carlos Faria]

A Oracle tem diversas soluções não só para load balance como para segurança também.

 

Já faz algum tempo (uns 4 anos) que vi uma solução Oracle contendo autenticação integrada em aplicações web, fazendo controle de acesso sobre registros/colunas de uma tabela do banco.

Não estou a par do que há de novo em função das necessidades que tenho, mas com certeza existem muitas soluções interessantes.

Outra novidade, eu encontrei em um banner Oracle, o “HP Oracle Exadata Storage Server”. Pelo menos o marketing em cima deste produto está muito bom.

<BR<BR

[Régis Soares]

Indiquei referências de Martin Fowler e talvez tenha sido infeliz ao escrever que seriam para "convencê-los" (os demais membros da equipe que Nilo participa). Não quis dizer para ele argumentar "use isso, pois o MF falou", e sim para entender o contexto e, se concordar com o que o autor escreveu e achar pertinentes para o projeto, aplicar ou apresentar para a equipe.

 

Os padrões apresentados no livro P of EAA são muito úteis. Inclusive, os patterns O/R behavioral e structural me fizeram compreender muito melhor os frameworks ORM e não simplesmente o "how to" que encontramos na internet. Recomendo este livro como leitura obrigatória para qualquer desenvolvedor.

 

Quanto as chaves primárias (compostas ou não), lembro que um professor que tive na faculdade foi muito feliz em sua colocação dizendo (IMHO) que não devemos usar como chave primária valores externos que não temos controle sobre ele, como CPF, um código de um produto, CEP, etc. Vamos supor que temos um comércio eletrônico e o código de um produto de um fornecedor mude, vcs podem imaginar o impacto que isso teria em nossa aplicação.

[Luiz Carlos Faria]

Respondendo:

“Quanto as chaves primárias (compostas ou não), lembro que um professor que tive na faculdade foi muito feliz em sua colocação dizendo (IMHO) que não devemos usar como chave primária valores externos que não temos controle sobre ele, como CPF, um código de um produto, CEP, etc. Vamos supor que temos um comércio eletrônico e o código de um produto de um fornecedor mude, vcs podem imaginar o impacto que isso teria em nossa aplicação.”

Você está certo, esse cuidado é uma boa prática.

Mas... o assunto estava relacionado apenas a criação de chaves compostas como PK.

<br

[Régis Soares]

Luiz,

 

Então, para me adequar ao tema, darei minha humilde opinião: a prática de criar um "ID" como PK ao invés de uma PK composta me agrada, desde que seja criada uma unique constraint para os campos que "deveriam" ser a PK. Isso torna o meu desenvolvimento mais produtivo e acredito não sacrificar em nada o modelo ou desempenho do bd, pelo contrário, pois ao invés de pesquisar em dois ou mais campos pesquisará em apenas um. Além disso, não interfere em nada no que diz respeito à normalização do bd.

 

abs

[Luiz Carlos Faria]

Régis,

 

Se pareci, ou pareço arrogante pela forma como disserto, me perdoe, não era essa a intenção.

 

Entenda que quando digo “discordo” é porque penso diferente, apenas. Não gostaria de ser mal interpretado por ninguém do grupo.

 

Mas, vamos aos porquês:

 

Imagine uma relação NxN com duas tabelas com chave burra. Não sou contra chave burra, desde que faça sentido para os dados. Fruto desta relação NxN teríamos naturalmente uma tabela associativa.

Essa tabela associativa, ao meu ver, e não pretendo mudar o mundo com meus argumentos, não deveria possuir uma chave burra, apenas a composição de sua PK com base nas FK’s envolvidas no relacionamento.

 

Visualmente, não consigo lembrar de nenhuma ferramenta ou forma de modelar um banco que traga junto ao MER as informações sobre cada índice de uma tabela. Visualmente temos problemas para identificar a cardinalidade entre relações NxN, dificultando inclusive a validação do modelo relacional.

 

Do ponto de vista tecnológico, estou incorporando ao meu modelo de dados regras para atender a questões não relacionadas ao contexto dos dados. Não vejo sentido algum ter de adaptar meu modelo de dados a uma necessidade ou luxo de um ORM, por exemplo. Assim como não me familiarizo com a necessidade de adaptar meu design da aplicação em função de características relacionadas ao banco.

 

Ignorando a existência de um banco de dados, o relacionamento entre as duas classes teria um identificador? Não.

No banco, só existe uma tabela intermediária pois o modelo relacional não permite uma implementação diferente para esse relacionamento.

 

 

Atenciosamente

Luiz Carlos Faria

<br

[Eduardo Miranda]

Luiz Carlos,

 

O que você costuma fazer quando uma entidade não tem realmente uma chave primária, como por exemplo cliente (para simplificar vamos pensar em PF). Qual seriam as chaves candidatas de um cliente? CPF? Não sei.

 

Ou seja, o que fazer quando as chaves de negócio não são possíveis.

 

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

[Luiz Carlos Faria]

Então Régis,

 

Para estes casos e na verdade para a maioria eu coloco ID’s , simples ou compostos de acordo com a necessidade de versionamento do conteúdo. Eu não faria o mesmo para uma tabela simplismente associativa. Esse é o ponto da discussão.

 

Quanto a ser ou não uma boa prática, neste caso ainda existe uma forte discussão e até acredito que não mudará. Sempre terá duas linhas de raciocínio a respeito do assunto. Com base na discussão aqui, acredito que mesmo em tabelas associativas vamos acabar tendo duas linhas diferentes e eternas. Discordar faz parte e é bom para os dois lados.

<br

[Rodrigo Vieira]

Nao sei quanto aos outros, mas quando expressei minha preferência por
chaves primárias "burras" (ID) eu não estava me referindo ao caso de
tabelas associativas. Nesse tipo de tabela não há motivo para haver
uma chave própria mesmo, basta termos as chaves estrangeiras.

Acho que na discussão tá rolando uma confusão entre chaves compostas,
chaves estrangeiras e chaves naturais.

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

[Luiz Carlos Faria]

Então Régis,

 

Para estes casos e na verdade para a maioria eu coloco ID’s , simples ou compostos de acordo com a necessidade de versionamento do conteúdo. Eu não faria o mesmo para uma tabela simplesmente associativa. Esse é o ponto da discussão.

 

Quanto a ser ou não uma boa prática, neste caso ainda existe uma forte discussão e até acredito que não mudará. Sempre terá duas linhas de raciocínio a respeito do assunto. Com base na discussão aqui, acredito que mesmo em tabelas associativas vamos acabar tendo duas linhas diferentes e eternas. Discordar faz parte e é bom para os dois lados.

 

 

<br

[Luiz Carlos Faria]

A discussão começou por conta das chaves compostas.

A minha indignação estava relacionada à poluição do modelo de dados com
chaves burras onde não era necessário. E um caso muito comum é este, tabelas
associativas.

Acho que não fui claro o suficiente. Desculpem.


-----Mensagem original-----
De: dotnetar...@googlegroups.com
[mailto:dotnetar...@googlegroups.com] Em nome de Rodrigo Vieira
Enviada em: quinta-feira, 18 de junho de 2009 11:47

[Régis Soares]

"Se pareci, ou pareço arrogante pela forma como disserto, me perdoe, não era essa a intenção."

 

De forma alguma, estamos em uma discussão sadia. Gosto deste tema e de discutir sobre ele.

 
"Imagine uma relação NxN com duas tabelas com chave burra. Não sou contra chave burra, desde que faça sentido para os dados. Fruto desta relação NxN teríamos naturalmente uma tabela associativa.
Essa tabela associativa, ao meu ver, e não pretendo mudar o mundo com meus argumentos, não deveria possuir uma chave burra, apenas a composição de sua PK com base nas FK’s envolvidas no relacionamento."

 

Concordo com seus argumentos, desde que a tabela associativa não tenha outros campos, seja somente as PKsFKs

 

Por exemplo, relacao (pk_tb_1, pk_tb_2, outro_campo). Nesse caso, certamente eu adicionaria uma chave burra, resultando em relacao (id, pk_tb_1, pk_tb_2, outro_campo) (lembrando que para pk_tb_1, pk_tb_2 eu adicionaria uma unique constraint).

 

Em um modelo ORM, eu não preciso ter uma classe para representar uma relacao NxN (como no modelo ER) desde que ela não possua outros campos.

 

Essa com certeza é a minha forma preferida de trabalhar e, sempre que viável, implemento estes casos dessa maneira. Tendo a viabilidade como premissa, não acho que exista uma abordagem cera ou errada para solucionar essa questão.
 
"...Visualmente temos problemas para identificar a cardinalidade entre relações NxN, dificultando inclusive a validação do modelo relacional."
 
Concordo, e por isso sou a favor de ter um modelo lógico (sem representar as chaves burras) e outro físico (representando as chaves burras). A desvantagem disso é que teremos dois modelos para atualizar.

 

"Do ponto de vista tecnológico, estou incorporando ao meu modelo de dados regras para atender a questões não relacionadas ao contexto dos dados. Não vejo sentido algum ter de adaptar meu modelo de dados a uma necessidade ou luxo de um ORM, por exemplo. Assim como não me familiarizo com a necessidade de adaptar meu design da aplicação em função de características relacionadas ao banco."

 

Eu não penso na forma de ter que adaptar a um framework A ou B. Minha opção por este modelo é geralmente por me tornar mais produtivo, tanto no desenvolvimento quanto nas queries que preciso implementar. Ou seja, no caso da implementação das queries complexas ou com agregações dou preferência em criar views para elas, nesse caso não estou pensando em um framework ou na programação, pois estou trabalhando diretamente no banco de dados e, nesses casos, eu acho que isso também é mais produtivo para mim. Perceba que minhas decisões não são para adaptar um ao outro.