Chaves primárias no Django

[Joao Mendes]

Caros colegas, boa tarde. Criei as seguintes tabelas no meu banco de
dados:

class Tbaaa(models.Model):
codigoaaa = models.IntegerField(primary_key=True)
descricaoaaa = models.CharField(max_length=100)

class Tbbbb(models.Model):
codigobbb = models.IntegerField(primary_key=True)
descricaobbb = models.CharField(max_length=100)

class Tbccc (models.Model):
codigoaaa = models.ForeignKey(Tbaaa, db_column='codigoaaa')
codigobbb = models.ForeignKey(Tbbbb, db_column='codigobbb')
percentual = models.DecimalField(max_digits=8, decimal_places=2)

Porém, pelas leituras realizadas em livros e listas, percebi que o
django não trabalha com chaves primárias compostas (como é o caso da
tabela Tbccc). Gostaria de saber como simular esse conceito no django.

Desde já agradeço pela atenção.

João Batista

[Rodrigo Pinheiro Matias]

Ele vai criar um campo chamado ID, caso queira inserir restrição use unique_togetter

--
Django Brasil em Google Groups <http://groups.google.com.br/group/django-brasil>
Associe-se à Python Brasil e suporte nossa comunidade! <http://associacao.python.org.br/>

--
Rodrigo Pinheiro Matias
Bacharel em Ciência da Computação

Celular
+55 (063) 8111.2080

Telefone em horário Comercial
+55 (063) 3216.7564

Blog
http://rodrigomatias.goware.com.br/blog/

Feed
http://rodrigomatias.goware.com.br/blog/feed/

Twitter
http://twitter.com/rodrigopmatias

[Diego Henrique Oliveira]

A sua class Tbccc representa uma tabela de ligação entra duas outras tabelas, ou seja, um relacionamento de muitos pra muitos. Da uma olhada aqui, acho que isso pode ajudar:

http://docs.djangoproject.com/en/1.2/topics/db/models/#extra-fields-on-many-to-many-relationships

[Daiana Marta Marasquin]

Na hora de criar as classes no models você utiliza a class Meta do Django.
Exemplo:

class Exe(models.Model):
    class Meta:
        unique_together = (('campo1','campo2', 'campo3'),)
    campo1 = models.CharField(max_length=128)
    campo2 = models.CharField(max_length=128)
    campo3 = models.CharField(max_length=128)
          
Deste modo ele diz que "juntos serão únicos" e não poderão repetir a mesma sequência como se fosse chaves compostas em sql.

Mais dúvidas dá uma olhada aqui: http://docs.djangobrasil.org/ref/models/options.html

Espero ter ajudado ;)
Att.
Daiana.

[David Kwast]

Aproveitando o tópico.

Na pós graduação de gestão de projetos um professor disse que chaves compostas ou chave primária diferente de ID nunca ajudam, só atrapalham. Pelo menos para 99% dos problemas. Deve ser por isso que o Django por padrão cuida da chave primária para a gente.

[]'s

David Kwast

2010/6/1 Daiana Marta Marasquin <dailoi...@gmail.com>

[Ezequiel Bertti]

olha... vou te dizer, depende!!! como tudo na analise de um sistema...  n tem uma regra 100%

id de usuario por exemplo realmente só atrapalha ser diferente disso...

agora quando vc esta falando de uma categoria de usuário, só para fazer um relatorio básico vc já tem q fazer um join só para saber o q aquele numero representa, ainda mais se vc tiver mais de 10 categorias diferentes e o relatório for para uma pessoa que n tem conhecimentos, é mais chato... nao é rotina, mas é uma rotina a gente ficar fazendo select para conferir os dados e tal...

PARA O BANCO é melhor ser somente ID com INT, para nos meros mortais, nem sempre é o mais performático...

não sei se todos sabem, mas uma das operações mais carregadas para um banco é a operação de JOIN...

2010/6/2 David Kwast <david...@gmail.com>

chaves compostas ou chave primária diferente de ID nunca ajudam, só atrapalham

--
Ezequiel Bertti
E-Mail: ebe...@gmail.com
MSN: ebe...@hotmail.com
Cel: (21) 9188-4860

VÁ PARA BÚZIOS!!!
http://www.agh.com.br/
Ane Guest House

[Marinho Brandao]

Ezequiel,

também creio que "depende", mas discordo do que diz.

Para o banco, teoricamente chaves primárias compostas, normalização, etc são melhores, dependendo da modelagem, mas isso só se torna uma vantagem em uns poucos casos, já que na maioria das vezes a normalização com chaves compostas acaba obrigando a criação de várias FKs e vários índices, e acaba neutralizando a vantagem.

A operação de JOIN sobre uma FK e na ordem correta é muito leve, com quase nenhum impacto. Ela se torna pesada quando usada sem uma FK ou na ordem incorreta, e a diferença é na casa de centenas de vezes mais peso.

Há situações onde uma SELECT de múltiplas tabelas também é mais vantagem do que usar JOIN, desde que seguindo a mesma regra usada com JOIN.

E outra coisa: a JOIN é tão leve, que dependendo do seu filtro, é mais rápido criar uma tabela temporária, popular essa tabela com os valores e usar JOIN sobre ela do que usar um BETWEEN, IN ou um conjunto de OR.

Exemplo:

select * from tabela where data between ('2010-06-02', '2010-07-02'); --- lento

select * from tabela join tabela_temporaria on tabela.data = tabela_temporaria.data; --- rapido

--
Django Brasil em Google Groups <http://groups.google.com.br/group/django-brasil>
Associe-se à Python Brasil e suporte nossa comunidade! <http://associacao.python.org.br/>

Marinho Brandão (José Mário)

http://www.marinhobrandao.com/

[Ezequiel Bertti]

marinho... vc está certo... mas mesmo assim, vamos pensar juntos aqui

JOIN é pesado, principalmente mais pesado que um select SEM JOIN, pois é feito uma comparação para cada linha... concordo que se tiver um index bem feito é bem melhor, fica quase imperceptível, mas se vc pode evitar um join, faça!!!

de maneira simples, vc tem para cada linha a carga dos elementos de comparação, depois vc tem a carga dos elemento de exibição da celula que foi feito o join, vc tem 2 IOs ao invez de 1 se vc n tiver o join de IDs... logo, pelo menos vc tem o dobro de operação para resolver 1 celula de exibição.

n eh atoa que um dos metodos de BI é desnomalizar o banco reduzindo joins bobos.... tb n eh atoa que vários bancos NoSql removem relações entre entidades para ganhar mais performance...

as consultas prontas do django ajudam muito o desenvolvimento, mas depois em produção e ainda em um servidor compartilhado, temos que tomar certos cuidados, tudo bem que fazer um join n vai fazer o banco cair, mas de maneira geral, ganhar tempo em pequenas coisas ajuda muito em servidores compartilhados...

2010/6/2 Marinho Brandao <mar...@marinhobrandao.com>

[Marinho Brandao]

Ezequiel, você está misturando coisas muito diferentes.

A questão aqui é se uma PK composta se justifica ou não. Eu não lembro de um caso sequer que ela se justificou de forma efetiva, porque todas as vezes em que ela oferecia ganho de desempenho na consulta (muito pequeno, por sinal), ela piorava o desempenho na persistência. Ou tornava o banco impossível de manter.

O que você está dizendo faz muito sentido sim... mas não como chave primária e sim como redundância controlada (um campo com o valor redundando e atualizado por uma trigger, uma rotina de callback ou um signal - no caso do Django).

BI normalmente trabalha só com consulta de dados processados, então não precisa preocupar com persistência, e os dados inclusive são tratados de forma a evitar processamento. É um outro caso.

A denormalização dos bancos NoSQL visa desempenho em escala. É muito diferente. Geralmente bancos relacionais ganham em desempenho dos não-relacionais quando se tem relacionamentos complexos e os dados não estão distribuídos - leia-se "processamento de cálculo de folha de pagamento".

:)

[Ezequiel Bertti]

eh.. fugi do assunto!!! sorry!!! hehehhe

[Marinho Brandao]

tranquilo :)