Art. O que é noSQL? JavaMagazine 86

Concordo com o autor do artigo. Prefiro usar chaves artificiais a chaves naturais. Chaves compostas, então, de jeito nenhum!

Humm. Poderia explicar a diferença entre chave composta / chave artificial / chave natural. Acho que o meu entendimento sobre elas não é muito correto.

fala emannuel…

lembre que o artigo trata de noSQL…

noSQL tem um nicho de mercado focado e bem diferente do que estamos acostumados, as idéias são totalmente outras e de repente, o contexto do que ele falow está voltado para soluções noSQL.

Lembre Hibernate é uma ferramenta ORM… o R é de RELACIONAL, se você tem um Banco não-Relacional, usá-lo seria desnecessário. Não discorde do que ele falou, jogando o que ele falou para sua realidade, use a realidade noSQL que pede performance e escalabilidade altas.

Abs [] e bopns estudos.

adriano_si:

fala emannuel…

lembre que o artigo trata de noSQL…

noSQL tem um nicho de mercado focado e bem diferente do que estamos acostumados, as idéias são totalmente outras e de repente, o contexto do que ele falow está voltado para soluções noSQL.

Lembre Hibernate é uma ferramenta ORM… o R é de RELACIONAL, se você tem um Banco não-Relacional, usá-lo seria desnecessário. Não discorde do que ele falou, jogando o que ele falou para sua realidade, use a realidade noSQL que pede performance e escalabilidade altas.

Abs [] e bopns estudos.

Então, antes de mais nada obrigado pelo comentário…

Enquanto ao artigo, entendo o que você quis dizer, estou estudando um pocuo de noSQL.
Porém o contexto desse trexo ele realmente se refere banco de dados comum, cujo objetivo era mostrar como mesmo utilizando um banco relacional, hoje em dia fugimos de algumas caracteristicas de bancos relacionais, que são essas que citei no trexo.
Acho que o motivo de eu ter dicordado dele vem do fato de eu não entender muito a diferenças entre chave composta / chave artificial / chave natural.

Poderia justificar o porque não usar chaves compostas de jeito nenhum?
Trabalho em um sistema utilizando hibernate em um banco legado que tem em torno de 600 tabelas, sendo que quase todas tem chave composta (devido a quase todas tabelas terem código da rede e da filial).

Não consigo enxergar o problema que as chaves compostas trazem… Quem sabe você possa me fazer entender…

valeu!

Quando se trabalha com chave natural é comum ter 4, 5 chaves primarias por tabela. A tendência é sempre ir aumentando.
Não quer dizer que isso é ruim, pelo contrário. Se a empresa trabalha muito gerando relatórios direto da base, fica até mais performático. Não precisa fazer centenas de JOIN’s para buscar informações de pk’s de outras tabelas.

O problema é que alguns dos mais famosos ORM’s do java exigem um esforço a mais para trabalhar com varias pk’s em uma tabela. Outras linguagens possuem ORM’s muito mais prático onde esse problema não existe.
Apesar dessa ser uma revista Java, acho que foi infeliz ao dizer que As tecnologias de ORM trouxeram desvantagens como a citada. Essa desvantagem é exclusiva dos mais utilizados ORM’s Java. Um exemplo do contrário é esse daqui: http://www.sqlalchemy.org

Pessoalmente eu acho um absurdo adaptar o modelo de dados da empresa pela exigência de uma aplicação qualquer.Principalmente em tabelas corporativas, que serão utilizadas por n sistemas em n linguagens.
Então o mais correto é avaliar a real necessidade de usar chave natural ou chave artificial.
Uma das vantagens de utilizar chaves artificiais é na migração de sistemas, ou qnd é necessário alterar com frequência o valor de uma chave primária (chave primária nao deveria ser atualizada nunca).

immortalSoul:

Quando se trabalha com chave natural é comum ter 4, 5 chaves primarias por tabela. A tendência é sempre ir aumentando.
Não quer dizer que isso é ruim, pelo contrário. Se a empresa trabalha muito gerando relatórios direto da base, fica até mais performático. Não precisa fazer centenas de JOIN’s para buscar informações de pk’s de outras tabelas.

O problema é que alguns dos mais famosos ORM’s do java exigem um esforço a mais para trabalhar com varias pk’s em uma tabela. Outras linguagens possuem ORM’s muito mais prático onde esse problema não existe.
Apesar dessa ser uma revista Java, acho que foi infeliz ao dizer que As tecnologias de ORM trouxeram desvantagens como a citada. Essa desvantagem é exclusiva dos mais utilizados ORM’s Java. Um exemplo do contrário é esse daqui: http://www.sqlalchemy.org

Pessoalmente eu acho um absurdo adaptar o modelo de dados da empresa pela exigência de uma aplicação qualquer.Principalmente em tabelas corporativas, que serão utilizadas por n sistemas em n linguagens.
Então o mais correto é avaliar a real necessidade de usar chave natural ou chave artificial.
Uma das vantagens de utilizar chaves artificiais é na migração de sistemas, ou qnd é necessário alterar com frequência o valor de uma chave primária (chave primária nao deveria ser atualizada nunca).

Quanto as vantagens de chaves artificiais que você citou, abriu um pouco mais a minha visão. Porém até onde vejo, trabalhar com chave composta com hibernate não é tão complicado assim. Não sei se tenho essa mentalidade devido a ter inciado a trabalhar com java em um sistema que faz bastante uso de chave composta com o hibernate(Não vejo como chave artificiai iria facilitar tanto)…

emannuel:

immortalSoul:

Quando se trabalha com chave natural é comum ter 4, 5 chaves primarias por tabela. A tendência é sempre ir aumentando.
Não quer dizer que isso é ruim, pelo contrário. Se a empresa trabalha muito gerando relatórios direto da base, fica até mais performático. Não precisa fazer centenas de JOIN’s para buscar informações de pk’s de outras tabelas.

O problema é que alguns dos mais famosos ORM’s do java exigem um esforço a mais para trabalhar com varias pk’s em uma tabela. Outras linguagens possuem ORM’s muito mais prático onde esse problema não existe.
Apesar dessa ser uma revista Java, acho que foi infeliz ao dizer que As tecnologias de ORM trouxeram desvantagens como a citada. Essa desvantagem é exclusiva dos mais utilizados ORM’s Java. Um exemplo do contrário é esse daqui: http://www.sqlalchemy.org

Pessoalmente eu acho um absurdo adaptar o modelo de dados da empresa pela exigência de uma aplicação qualquer.Principalmente em tabelas corporativas, que serão utilizadas por n sistemas em n linguagens.
Então o mais correto é avaliar a real necessidade de usar chave natural ou chave artificial.
Uma das vantagens de utilizar chaves artificiais é na migração de sistemas, ou qnd é necessário alterar com frequência o valor de uma chave primária (chave primária nao deveria ser atualizada nunca).

Quanto as vantagens de chaves artificiais que você citou, abriu um pouco mais a minha visão. Porém até onde vejo, trabalhar com chave composta com hibernate não é tão complicado assim. Não sei se tenho essa mentalidade devido a ter inciado a trabalhar com java em um sistema que faz bastante uso de chave composta com o hibernate…

Quanto a chave composta,
não sei como está agora, mas antes exigia uma mão de obra a mais.

Eu sou mais um partidario do uso de chaves artificiais.

Uma das questões, é o que o colega ja disse acima, PK’s não deveriam mudar.

E outra, pra que serve uma PK senão apenas fazer os relacionamentos as tabelas? Se queres que outros campos sejam únicos então crie Unique Contraints. Se quer performance, crie índices para os campos de suas consultas.

E tambem não gosto de chaves compostas, aff ja vi tabelas com 10 ou mais campos formando a PK, ja pensou que filé pra fazer os relacionamentos disto e depois fazer joins. Mas como sempre uso o famoso id integer primary key, pelo menos em meus sistema nunca terei chaves compostas.

Acho que aí estava a confusão que fiz em minha cabeça. Para mim, uma primary key contendo 2 campos: um código sequencial e um código de relacionamento com outra tabela, era considerada uma chave composta. Mas pelo post do nosso último amigo ali, acho que eu estava enganado!

Se for isso, agora acabo entendendo melhor o que o autor do artigo quis dizer.

emannuel:

Acho que aí estava a confusão que fiz em minha cabeça. Para mim, uma primary key contendo 2 campos: um código sequencial e um código de relacionamento com outra tabela, era considerada uma chave composta. Mas pelo post do nosso último amigo ali, acho que eu estava enganado!

Se for isso, agora acabo entendendo melhor o que o autor do artigo quis dizer.

Não sei se entendi direito, mas vamos aos exemplos.

//chave primaria artificial
create table pessoa (
id integer primary key,
nome varchar(50),
cpf char(11),
)


//chave natural
create table pessoa (
cpf char(11) primary key,
nome varchar(50),
)

//chave composta
create table pessoa (
nome varchar(50),
dataNasc date,
cpf char(11),
primary key(nome, dataNasc)
)

Acho que é isto.

fredferrao:

Eu sou mais um partidario do uso de chaves artificiais.

Uma das questões, é o que o colega ja disse acima, PK’s não deveriam mudar.

E outra, pra que serve uma PK senão apenas fazer os relacionamentos as tabelas? Se queres que outros campos sejam únicos então crie Unique Contraints. Se quer performance, crie índices para os campos de suas consultas.

E tambem não gosto de chaves compostas, aff ja vi tabelas com 10 ou mais campos formando a PK, ja pensou que filé pra fazer os relacionamentos disto e depois fazer joins. Mas como sempre uso o famoso id integer primary key, pelo menos em meus sistema nunca terei chaves compostas.

em minha opinião, um exemplo de uma boa chave natural é a sigla do estado. Nese caso não vejo a menor necessidade de usar chave artificial. Vou criar mais um campo, inventar mais um join, pq? pq meu ORM não faz o serviço dele direito? . Melhor trocar de ORM, ou de linguagem =P

fredferrao:

emannuel:

Acho que aí estava a confusão que fiz em minha cabeça. Para mim, uma primary key contendo 2 campos: um código sequencial e um código de relacionamento com outra tabela, era considerada uma chave composta. Mas pelo post do nosso último amigo ali, acho que eu estava enganado!

Se for isso, agora acabo entendendo melhor o que o autor do artigo quis dizer.

Não sei se entendi direito, mas vamos aos exemplos.

//chave primaria artificial
create table pessoa (
id integer primary key,
nome varchar(50),
cpf char(11),
)


//chave natural
create table pessoa (
cpf char(11) primary key,
nome varchar(50),
)

//chave composta
create table pessoa (
nome varchar(50),
dataNasc date,
cpf char(11),
primary key(nome, dataNasc)
)

Acho que é isto.

Exato! Mas antes dos comentários aqui, eu imaginava que o exemplo do wellington.nogueira seria um exemplo de chave composta que estariam sendo ““banidas””, porém lendo o que você falou, creio que esse exemplo dele não tem porquê ser evitada, certo? (Chave composta apenas com o intuito de fazer relacionamento).

OBS.: Sendo dessa forma, ainda não acho um problema grande trabalhar com esse tipo de chave composta que citei Ok, chave simples é mais tranquilo, mas não acho complicado trabalhar com chave composta. E mesmo que fosse um problema, também concordo que existem casos que esse tipo de escolha não pode se deixar influenciar por uma “SUPOSTA” limitação de um framework ORM. Não?

wellington.nogueira:

Hm... lendo o que alguns escreveram, estou entendendo que as tabelas com chaves compostas que foram "banidas" seriam as com chaves naturais visto que não haveria motivos para haver mais de uma chave artificial exceto no caso de chaves compostas artificiais em tabelas que relacionam outras duas. Ou mesmo nesse caso, não seria muito aceitável?

tabelaPessoa {
  idPessoa integer Primary key,
  nomePessoa string
}

tabelaCarro {
  idCarro integer Primary key,
  marcaCarro string,
  modeloCarro string
}

//Tabela n-n com chave composta.
tabelaLocacao {
  idPessoa integer,
  idCarro integer,
  primary key (idPessoa, idCarro)
}

(não quis me ater a instruções SQL :P )

Exato, apenas nos relacionamentos N:N teremos dois id artificiais como PK.

immortalSoul:

fredferrao:

Eu sou mais um partidario do uso de chaves artificiais.

Uma das questões, é o que o colega ja disse acima, PK’s não deveriam mudar.

E outra, pra que serve uma PK senão apenas fazer os relacionamentos as tabelas? Se queres que outros campos sejam únicos então crie Unique Contraints. Se quer performance, crie índices para os campos de suas consultas.

E tambem não gosto de chaves compostas, aff ja vi tabelas com 10 ou mais campos formando a PK, ja pensou que filé pra fazer os relacionamentos disto e depois fazer joins. Mas como sempre uso o famoso id integer primary key, pelo menos em meus sistema nunca terei chaves compostas.

Existem situações e situações. Não da pra generalizar e dizer que chave artificial é melhor que natural. Nem sempre isso ocorre!
Muitas vezes chave natural é muito mais interessante por vários motivos e a simples criação de indice pode não garantir performance em um campo.
O fato do java não trabalhar bem com chave composta não deve ser uma limitação imposta ao modelo de dados. Deve-se avaliar a necessidade de chave artificial ou natural com base em outros aspectos e não na limitação dos ORM’s java.

em minha opinião, um exemplo de uma boa chave natural é a sigla do estado. Nese caso não vejo a menor necessidade de usar chave artificial. Vou criar mais um campo, inventar mais um join, pq? pq meu ORM não faz o serviço dele direito? . Melhor trocar de ORM, ou de linguagem =P

No meu caso, eu não disse usar desta maneira devido a limitação de framework/linguagem. É gosto pessoal mesmo, uso assim desde minhas épocas de Delphi.

Realmente faz sentido no caso da UF, seria um join a menos, ja que a propria FK ja é o dado que se precisa.

Outra coisa é que usando chaves naturais, inevitavelmente teremos mais ocorrencias de chaves compostas, pois nem sempre os dados naturais por si só conseguem tornar a entidade única. E é ai que aparecem as PK’s formadas por 10 ou mais campos. :shock:

muito arquiteto novato gosta de ficar se baseando nessas publicações sem valor academico nenhum. a maioria dessas coisas que eles publicam é pra encher a revista dando a ideia que é algo de vanguarda. por isso que eu confio muito mais em blogs de profissionais realmente de peso do cenário internacional.
não há problema nenhum no paradigma ORM atual mas ele é ineficiente em outros tipos de arquiteturas.
Tem coisa bem melhor dependendo do contexto.

No contexto em que ele escreveu o trexo que citei, foi isso que ele quis dizer.

Eu não vi nada errado no que o autor escreveu, simplesmente ele descreveu um dos impactos resultante do uso de ORM e só.

Alguns produtores de ORM aconcelham a utilizar chaves artificiais (surrogates) ao invés de chaves resultantes da normalização das estrutura de dados porque será menos trabalhoso pra você (irá codificar menos) e para o componente (irá envolver mais código para gerar os relacionamentos ao construir os sqls).

Se colocar esta questão apenas na estrutura de dados (MER) as chaves compostas geram certos incomodos, por exemplo:

1. Imagine uma chave composta por 7 colunas em um relacionamento 1:n sendo que o lado n tem apenas 2 colunas dados pertencente a própria entidade. Teremos como resultado 9 colunas sendo que 7 serão resultante do relacionamento, se a chave fosse uma única coluna teriamos apenas 3 colunas como resultante. Neste caso o fenomeno esta na propagação das chaves.

2. Quando geramos entidades associativas. Imagine uma relação de n:n onde envolve 5 colunas como chave composta de cada lado, teremos como resultado uma entidade associativa com 10 colunas ao passo que se fosse 1 coluna como chave de cada lado teriamos apenas 2 colunas.

Este é mais um caso clássico onde cabe a frase esquisita que diz o seguinte: A teoria na prática é outra. Quer dizer o seguinte: Se vc montar sua estrutura de dados baseado nas teorias que embasam a modelagem de entidades e relacionamentos vc podera ter como resultante várias chaves compostas; vai existir a excecão dos casos onde nenhuma chave foi detectada por uma formula normal, neste caso é indicado a criação de uma chave artificial.

Perceba que em uma entidade com uma chave natural (negócio) constituida por apenas UMA coluna não vale a pena criar uma chave artificial.

Resumindo…em legados não há o que fazer, que aliás é onde mais aparece entidades com chaves compostas. Em sistemas novos prevalece o velho bom senso, tente aplicar o remédio apenas onde dói.

flws

fantomas:

Eu não vi nada errado no que o autor escreveu, simplesmente ele descreveu um dos impactos resultante do uso de ORM e só.

Alguns produtores de ORM aconcelham a utilizar chaves artificiais (surrogates) ao invés de chaves resultantes da normalização das estrutura de dados porque será menos trabalhoso pra você (irá codificar menos) e para o componente (irá envolver mais código para gerar os relacionamentos ao construir os sqls).

Se colocar esta questão apenas na estrutura de dados (MER) as chaves compostas geram certos incomodos, por exemplo:

1. Imagine uma chave composta por 7 colunas em um relacionamento 1:n sendo que o lado n tem apenas 2 colunas dados pertencente a própria entidade. Teremos como resultado 9 colunas sendo que 7 serão resultante do relacionamento, se a chave fosse uma única coluna teriamos apenas 3 colunas como resultante. Neste caso o fenomeno esta na propagação das chaves.

2. Quando geramos entidades associativas. Imagine uma relação de n:n onde envolve 5 colunas como chave composta de cada lado, teremos como resultado uma entidade associativa com 10 colunas ao passo que se fosse 1 coluna como chave de cada lado teriamos apenas 2 colunas.

Este é mais um caso clássico onde cabe a frase esquisita que diz o seguinte: A teoria na prática é outra. Quer dizer o seguinte: Se vc montar sua estrutura de dados baseado nas teorias que embasam a modelagem de entidades e relacionamentos vc podera ter como resultante várias chaves compostas; vai existir a excecão dos casos onde nenhuma chave foi detectada por uma formula normal, neste caso é indicado a criação de uma chave artificial.

Perceba que em uma entidade com uma chave natural (negócio) constituida por apenas UMA coluna não vale a pena criar uma chave artificial.

Resumindo…em legados não há o que fazer, que aliás é onde mais aparece entidades com chaves compostas. Em sistemas novos prevalece o velho bom senso, tente aplicar o remédio apenas onde dói.

flws

Excelente. Explicou muito bem as complicações das chaves compostas, que eu queria dizer, mas nao disse.

Eu ja vi chaves compostas de 10+ colunas, imaginem os relacionamentos disto :shock:

Quanto a chaves naturais serem trocadas por chaves artificiais, concordo, mesmo porque, o que hoje é uma chave natural (e por definição, não deveria ser alterável) amanhã pode ser trocada, mas não dispenso uso de controles de unicidade nessas mesmas chaves naturais (e/ou até mesmo o uso de indexação nas mesmas pois é provável uma pesquisa por elas).

Mas não usar chaves compostas é unica e exclusivamente por questões de implementação utilizando frameworks ORM? Não há uma outra motivação para isso?

Hm... lendo o que alguns escreveram, estou entendendo que as tabelas com chaves compostas que foram "banidas" seriam as com chaves naturais visto que não haveria motivos para haver mais de uma chave artificial exceto no caso de chaves compostas artificiais em tabelas que relacionam outras duas. Ou mesmo nesse caso, não seria muito aceitável?

tabelaPessoa {
  idPessoa integer Primary key,
  nomePessoa string
}

tabelaCarro {
  idCarro integer Primary key,
  marcaCarro string,
  modeloCarro string
}

//Tabela n-n com chave composta.
tabelaLocacao {
  idPessoa integer,
  idCarro integer,
  primary key (idPessoa, idCarro)
}

(não quis me ater a instruções SQL :P )

O melhor seria a chave natural ser a chave primaria, mas quando é necessária uma chave composta, por que não utilizar uma artificial (?)

Pode até não ser tão performático, mas deveria ser mais performático do que se não fosse nem indexado, senão, pra que indexar.

Concordo.