Art. O que é noSQL? JavaMagazine 86
Salve galera,
Estava lendo o artigo citado no título do post e achei muito curioso esse trexo:
"... As tecnologias de ORM trouxeram um ganho significativo de produtividade, contudo, para utilizar da melhor forma essa tecnologia, tivemos que abrir mão de algumas características do modelo relacional. Um exemplo disso é o banimento das chaves compostas (ou até mesmo as chaves naturais) em favor do uso de chaves artificiais. ..."
Onde eu trabalho, utilizamos sem problemas (ou não) hibernate em um banco de dados legado que é cheio de chaves compostas, por isso não concordei muito com o que ele disse aqui. Entretanto, como nunca utilizei o um framework ORM em uma base de dados não-legada, gostaria de saber a opinião de mais pessoas sobre essa afirmação do autor do artigo.
Abraço e espero que comentem!
Estava lendo o artigo citado no título do post e achei muito curioso esse trexo:
"... As tecnologias de ORM trouxeram um ganho significativo de produtividade, contudo, para utilizar da melhor forma essa tecnologia, tivemos que abrir mão de algumas características do modelo relacional. Um exemplo disso é o banimento das chaves compostas (ou até mesmo as chaves naturais) em favor do uso de chaves artificiais. ..."
Onde eu trabalho, utilizamos sem problemas (ou não) hibernate em um banco de dados legado que é cheio de chaves compostas, por isso não concordei muito com o que ele disse aqui. Entretanto, como nunca utilizei o um framework ORM em uma base de dados não-legada, gostaria de saber a opinião de mais pessoas sobre essa afirmação do autor do artigo.
Abraço e espero que comentem!
Emannuel Silveira
Curtidas 0
Respostas
Anthony Accioly
02/05/2011
Acho que banimento é uma palavra forte. Dá sim para trabalhar com objetos composto como Primary Key (apesar de eu concordar que o Hibernate e JPA são mais práticos para chaves simples, @Embeddable sempre me complica a vida).
Mas é verdade que, de uns tempos para cá, quando desenvolvo modelos novos para trabalhar com Hibernate tenho dado preferência para chaves simples (geralmente numéricas, auto-incrementáveis / populadas por Sequences). Nesse ponto, posso dizer que de uns tempos para cá eu substitui sim chaves naturais por chaves artificiais.Outro exemplo seriam atributos de relacionamentos (por exemplo, aqueles atributos extras em uma tabela de relacionamento n para m), eles simplesmente não mapeiam de forma natural no modelo orientado a objeto (criar um objeto separado para a relação me parece errado por n motivos). Em síntese, apesar do ORM permitir esse tipo de coisa, eu concordo que na fase de modelagem de bancos pensados para interagir com ORMs eu tenha abdicado de algumas coisas que simplesmente não mapeiam de forma tão natural. Eu pelo menos posso dizer que estou modelando bancos para novos projetos de forma bem diferente do que faria a uns anos atrás (de maneira pensada para trabalhar com JDBC).
Mas é verdade que, de uns tempos para cá, quando desenvolvo modelos novos para trabalhar com Hibernate tenho dado preferência para chaves simples (geralmente numéricas, auto-incrementáveis / populadas por Sequences). Nesse ponto, posso dizer que de uns tempos para cá eu substitui sim chaves naturais por chaves artificiais.Outro exemplo seriam atributos de relacionamentos (por exemplo, aqueles atributos extras em uma tabela de relacionamento n para m), eles simplesmente não mapeiam de forma natural no modelo orientado a objeto (criar um objeto separado para a relação me parece errado por n motivos). Em síntese, apesar do ORM permitir esse tipo de coisa, eu concordo que na fase de modelagem de bancos pensados para interagir com ORMs eu tenha abdicado de algumas coisas que simplesmente não mapeiam de forma tão natural. Eu pelo menos posso dizer que estou modelando bancos para novos projetos de forma bem diferente do que faria a uns anos atrás (de maneira pensada para trabalhar com JDBC).
GOSTEI 0
Emannuel Silveira
02/05/2011
Acho que banimento é uma palavra forte. Dá sim para trabalhar com objetos composto como Primary Key (apesar de eu concordar que o Hibernate e JPA são mais práticos para chaves simples, @Embeddable sempre me complica a vida).
Mas é verdade que, de uns tempos para cá, quando desenvolvo modelos novos para trabalhar com Hibernate tenho dado preferência para chaves simples (geralmente numéricas, auto-incrementáveis / populadas por Sequences). Nesse ponto, posso dizer que de uns tempos para cá eu substitui sim chaves naturais por chaves artificiais.Outro exemplo seriam atributos de relacionamentos (por exemplo, aqueles atributos extras em uma tabela de relacionamento n para m), eles simplesmente não mapeiam de forma natural no modelo orientado a objeto (criar um objeto separado para a relação me parece errado por n motivos). Em síntese, apesar do ORM permitir esse tipo de coisa, eu concordo que na fase de modelagem de bancos pensados para interagir com ORMs eu tenha abdicado de algumas coisas que simplesmente não mapeiam de forma tão natural. Eu pelo menos posso dizer que estou modelando bancos para novos projetos de forma bem diferente do que faria a uns anos atrás (de maneira pensada para trabalhar com JDBC).
Mas é verdade que, de uns tempos para cá, quando desenvolvo modelos novos para trabalhar com Hibernate tenho dado preferência para chaves simples (geralmente numéricas, auto-incrementáveis / populadas por Sequences). Nesse ponto, posso dizer que de uns tempos para cá eu substitui sim chaves naturais por chaves artificiais.Outro exemplo seriam atributos de relacionamentos (por exemplo, aqueles atributos extras em uma tabela de relacionamento n para m), eles simplesmente não mapeiam de forma natural no modelo orientado a objeto (criar um objeto separado para a relação me parece errado por n motivos). Em síntese, apesar do ORM permitir esse tipo de coisa, eu concordo que na fase de modelagem de bancos pensados para interagir com ORMs eu tenha abdicado de algumas coisas que simplesmente não mapeiam de forma tão natural. Eu pelo menos posso dizer que estou modelando bancos para novos projetos de forma bem diferente do que faria a uns anos atrás (de maneira pensada para trabalhar com JDBC).
Obrigado pelo comentário!
Ainda sim não consigo enxergar o problema de chaves compostas. Volto a dizer que trabalho em um sistema grande em Java (600 tabelas) em que todas as chaves são compostas (devido a quase todas tabelas ter um código de rede e filial). Vejo alguns problemas em relação ao mapeamento devido ao banco ser legado de um sistema em DataFlex.
Entretando ainda não consegui enxergar problema nas chaves compostas (@Embeddable). Vejo alguns falarem que chaves compostas resulta em muitos JOINS, porém não consigo enxergar o porquê disso. Nâo vejo outro jeito de conseguir algumas informações em um só select sem usar JOINS (no máximo as chaves compostas atrapalham um pouco na quantidade de campos na clausula ON, porém um framework ORM abstrai isso).
Se você poder argumentar mais um pouco sobre isso seria bem bacana!
valeu!
GOSTEI 0
Anthony Accioly
02/05/2011
Eu não iria tanto pelo lado da Performance e problemas (como se fossem coisas incontornáveis, no pior dos casos você sempre pode escrever uma consulta nativa se a solução via JPQL / HQL não for satisfatória), e sim pelo lado da simplicidade.
Eu quero dizer, quando você têm um sistema legado vai ter que conviver com ele. Isso significa várias tabelas com PK Compostas, objetos representando relacionamentos com parâmetros e assim por diante. Acho que todo mundo já teve que conviver com isso (e já esbarrou em problemas ainda maiores com tabelas sem PK e coisas do gênero).
A questão é, durante o desenvolvendo um sistema novo, você pode tanta modelar suas tabelas com PKS compostas quando abstrair uma chave artificial. Vamos pensar no caso mais simples possível, uma query por ID sem joins.
No primeiro caso você: 1) Cria um objeto representando a primary key 2) Seta os dois ou mais parâmetros da PK 3) Dispara a consulta
No segundo caso você já pula para o terceiro passo usando um Id numérico artificial.
A mesma coisa se repete para deletes e updates.
Por simplicidade eu pessoalmente iria com a segunda solução (é mais fácil criar um chave artificial no banco do que repetir os três passos do primeiro caso em cada consulta).
Isso não significa que eu estou disposto a deixar meu banco inconsistente ou algo do gênero (a chave composta poderia ser transformada em uma constraint unique devidamente indexada). O fato dos joins serem mais rápidos pode ser um bônus, mas a razão número um de usar chaves artificiais no modelo, para mim, é a facilidade de implementação e manutenção.
Então, eu levaria o que o autor disse para um lado como: "Mesmo usando bancos relacionais, ferramentas ORM estão levando desenvolvedores a aos poucos adotarem novas práticas de modelagem para facilitar o mapeamento do modelo relacional para o orientado a objetos". Entenda essa frase como um ponte teórica para os princípios de Web Scale e ferramentas NoSQL. Essas ferramentas costumam seguir modelos de repositórios de documentos / par-valor / grafos que muitas vezes sacrificam o que seria considerado "correto" do ponto de vista relacional em nome da simplicidade e escalabilidade.
Ps: Esse é um assunto meio "religioso". Veja esse video parodiando uma conversa entre um fanboy de MySQL e outro de MongoDB: http://www.youtube.com/watch?v=b2F-DItXtZs
Abraços,
Eu quero dizer, quando você têm um sistema legado vai ter que conviver com ele. Isso significa várias tabelas com PK Compostas, objetos representando relacionamentos com parâmetros e assim por diante. Acho que todo mundo já teve que conviver com isso (e já esbarrou em problemas ainda maiores com tabelas sem PK e coisas do gênero).
A questão é, durante o desenvolvendo um sistema novo, você pode tanta modelar suas tabelas com PKS compostas quando abstrair uma chave artificial. Vamos pensar no caso mais simples possível, uma query por ID sem joins.
No primeiro caso você: 1) Cria um objeto representando a primary key 2) Seta os dois ou mais parâmetros da PK 3) Dispara a consulta
No segundo caso você já pula para o terceiro passo usando um Id numérico artificial.
A mesma coisa se repete para deletes e updates.
Por simplicidade eu pessoalmente iria com a segunda solução (é mais fácil criar um chave artificial no banco do que repetir os três passos do primeiro caso em cada consulta).
Isso não significa que eu estou disposto a deixar meu banco inconsistente ou algo do gênero (a chave composta poderia ser transformada em uma constraint unique devidamente indexada). O fato dos joins serem mais rápidos pode ser um bônus, mas a razão número um de usar chaves artificiais no modelo, para mim, é a facilidade de implementação e manutenção.
Então, eu levaria o que o autor disse para um lado como: "Mesmo usando bancos relacionais, ferramentas ORM estão levando desenvolvedores a aos poucos adotarem novas práticas de modelagem para facilitar o mapeamento do modelo relacional para o orientado a objetos". Entenda essa frase como um ponte teórica para os princípios de Web Scale e ferramentas NoSQL. Essas ferramentas costumam seguir modelos de repositórios de documentos / par-valor / grafos que muitas vezes sacrificam o que seria considerado "correto" do ponto de vista relacional em nome da simplicidade e escalabilidade.
Ps: Esse é um assunto meio "religioso". Veja esse video parodiando uma conversa entre um fanboy de MySQL e outro de MongoDB: http://www.youtube.com/watch?v=b2F-DItXtZs
Abraços,
GOSTEI 0
Emannuel Silveira
02/05/2011
Realmente pesnando por esse lado de sempre ter que criar um objeto representando o id, parece meio burocratico.
Nunca tinha pensado na abordagem que você citou :"... constraint unique devidamente indexada..."
Realmente me ajudou bastante a entender o ponto de vista do autor agora.
Verei o video quando chegar em casa...
valeu mesmo, ajudou muito!!!
Nunca tinha pensado na abordagem que você citou :"... constraint unique devidamente indexada..."
Realmente me ajudou bastante a entender o ponto de vista do autor agora.
Verei o video quando chegar em casa...
valeu mesmo, ajudou muito!!!
GOSTEI 0
Anthony Accioly
02/05/2011
Opa,
Estamos aí.
Se você acha que isso encerra o caso por favor atualize o status do chamado para resolvido.
Abraços,
Estamos aí.
Se você acha que isso encerra o caso por favor atualize o status do chamado para resolvido.
Abraços,
GOSTEI 0