chaves compostas no Django
Walter Cruz
[]'s
- Walter
Andrews Medina
> Oi pessoal. Eu estava conversando com o meu amigo Sebastian aqui sobre
> chaves compostas. Pelo que eu vi o Django não suporta. Alguém sabe de Django
> + Alchemy suporta?
Tem um ticket no django falando sobre isso!
http://code.djangoproject.com/wiki/MultipleColumnPrimaryKeys
http://code.djangoproject.com/ticket/373
Ele estava fechado mas eles reabriram pra melhorar isso!
Agora django + alchemy suporta sim!
--
Andrews Medina
http://pyman.blogspot.com/
www.andrewsmedina.com.br
Walter Cruz
O Alchemy algum dia será o ORM 'oficial' do Django?
Alguém sabe?
[]'s
- Walter
Sebastian SWC
o que ser alchemy?
Atenciosamente,
Sebastian Selau Webber Colombo
Acessem e participem: http://postgresql.blog.br/forum/
Sl 67.1-2: "Ó Deus, tem misericórdia de nós e abençoa-nos! Trata-nos com bondade.
Assim o mundo inteiro conhecerá a tua vontade, e a tua salvação será conhecida por todos os povos".
Guilherme M. Gondim (semente)
> pergunto eu.... o que ser alchemy?
Respondo a ti: ser um ORM e algo mais - http://www.sqlalchemy.org/
Marinho Brandao
isso teria lá suas vantagens, mas eu gostaria que não. Prefiro o ORM
do Django mesmo.
Em 31/05/07, Guilherme M. Gondim (semente)<sem...@gmail.com> escreveu:
>
> On 5/31/07, Sebastian SWC <sebast...@gmail.com> wrote:
> > pergunto eu.... o que ser alchemy?
>
> Respondo a ti: ser um ORM e algo mais - http://www.sqlalchemy.org/
>
> >
>
--
José Mário, Mário ou Marinho
http://del.icio.us/marinho
http://www.flickr.com/photos/marinho/
http://marinho.wordpress.com
Andrews Medina
> O Alchemy algum dia será o ORM 'oficial' do Django?
>
Esse dia nunca chegará! Ou se chegar vai demorar!
O ORM do Django tem evoluído muito, falta poucas coisas para ele ser
ideal para web por exemplo:
* multiple primary keys
* herança
As duas estão sendo tratadas e desenvolvidas e a questão de herança do
django ficará bem melhor do que a maneira que é tratada no Alchemy,
que alias ele não faz herança de models e sim simula isso, mas simular
heranca como o ALchemy faz o ORM do Django também faz.
A real vantagem do Alchemy ao Django é suporte a mais banco de dados,
mias maturidade e idade, e suporte a várias conexões ao mesmo tempo,
mas acho que o django tem um ticket para isso ( tenho que pesquisar).
Vantagens em usar o ORM do Django ao Alchemy é a integração com a
geração de forms, templates, generic views, serializadores e etc.
Mas quem quer que o django use Alchemy, acho que até a versão 1.0 do
Django, sai´ra o Django + Alchemy, mesmo não sendo oficial, funcionará
( se tudo correr bem ) normalmente, acho que até suportará as
integrações.
Walter Cruz
Eu brinquei um fim de semana com o SQLObject, não conheço nada de SQL Alchemy, brinquei outro fim de semana com o Django.
Qual as diferenças entre esses ORMS? Alguém tem algum artigo?
Marinho, pq vc prefere o ORM do Django?
[]'s
- Walter
Andrews Medina
>
> Qual as diferenças entre esses ORMS? Alguém tem algum artigo?
Quando você fala esses, se refere a SQLObject, Django ORM ou Alchemy ou os 3?
Acho que esse final de semana vou fazer um post sobre isso ( se der
tempo =] ), mas para usar com django o ORM do django é o mais
indicado!
=]
Marinho Brandao
> Qual as diferenças entre esses ORMS? Alguém tem algum artigo?
hummm.. pergunta dificil de ser respondida, já que a minha experiencia
é maior com o ORM do Django.
no meu entender, o SQLObject é o mais antigo, porém, como foi um
trabalho de faculdade, não teve a devida atenção para ser continuado e
parou no tempo.
aí veio o SQLAlchemy, melhor projetado e antes de ser disponibilizado
já tinha virado notícia. Ele tem a vantagem de ter o modelo separado
da definição, pode ser utilizado em qualquer lugar (exemplo: migrar de
TurboGears para Django), etc.
já o ORM do Django foi feito sob medida para a framework, está bem
adaptado à localização, contrib admin, new forms, validations, etc.
> Marinho, pq vc prefere o ORM do Django?
o Andrews já respondeu. o maior motivo de eu ter escolhido o Django a
outras alternativas é sua coesão. eu estaria andando pra trás se
escolhesse um ORM ou um templating diferente do q ele oferece. Além do
mais, o ORM é quase tão poderoso quanto os outros e pode ser
melhorado, então não tenho motivos pra aprender outra alternativa se a
que tenho em mãos é eficaz :) mas isso vai de cada um, obviamente.
o q eu mais gosto no ORM (e não sei dizer se os outros têm o mesmo
recurso) é o encadeamento que pode fazer entre métodos de QuerySet
antes que seja feita a chamada ao SGBD, assim (se tiver algum erro de
sintaxe, é por causa da pressa):
# o inicio do encadeamento é aqui
if doc:
lista = Documento.objects.filter(tipo='A')
else:
lista = Planilha.objects.filter(tipo='A')
lista = lista.filter(imagem__isnull=False).exclude(pasta='/') | \
lista.filter(imagem__isnull=True, pasta='/')
lista = lista.distinct().order_by('-titulo')
start = None
max = 50
lista = lista[start:max]
# somente aqui um unico comando SQL (se possível)
# com a combinação dos filtros, é executado
print ''.join([i.nome+", " for i in lista])
Em 31/05/07, Andrews Medina<andrew...@gmail.com> escreveu:
Walter Cruz
já o ORM do Django foi feito sob medida para a framework, está bem
adaptado à localização, contrib admin, new forms, validations, etc.
(De repente o validation não tanto, mas acho que a admin e os forms sim) .
Bom - não estou reclamando. Sou um Djangueiro de primeira viagem. E que eu saiba nunca ninguém tentou botar outra coisa que não seja o ActiveRecord no Rails :)
(Apenas pra não parecer que eu estou de birra, http://nxsy.org/blog/archives/2007/05/22/using-postgresql-schemas-with-sqlalchemy-and-elixir :) falando de como usar schemas do PostgreSQL com o sqlalchemy no dejango)
[]'s
- Walter
Marinho Brandao
hummm... acho que eu não me expressei direito. o ORM não é de fato
acoplado a estes.
Só está melhor adaptado, exemplos: pre_populate_from, do SlugField,
verbose_name, help_text, js, etc. O acoplamento que existe - se for da
vontade do desenvolvedor, é a classe Admin. Na verdade são os módulos
que estão bem adaptados a ele, e não o contrário. Mas de qualquer
forma, o ORM do Django se comporta um pouco como dicionário de
classes, o que facilita a localização e outras questões da camada de
Visão.
@ validations:
por definição do MVC, as validações são de obrigação do Model, a menos
que sejam validações de processamento. E os modulos supracitados
também estão bem adaptados a ele.
> E que eu saiba nunca ninguém tentou botar outra coisa que não seja o ActiveRecord no Rails :)
uma grande diferença do RoR é justamente esta. O Python tem um
universo muito maior do que o Django, enquanto q o Ruby só se
popularizou por causa do Rails.
A alternativa ao Rails em Ruby é o Nitro, que ainda está engatinhando,
já o Python possui muitas frameworks maduras, e isso acaba
pulverizando os esforços, mas eu vejo isso como vantagem.
Em 31/05/07, Walter Cruz<walte...@gmail.com> escreveu:
>
Ricardo Bánffy
importantes?
Há toda uma corrente de pensamento que considera chaves primárias
múltiplas uma má idéia. Eu, no fundo, começo a me alinhar a essa idéia
- poder referenciar qualquer objeto no banco de dados por um
identificador de um tipo pré-determinado resolve um número enorme de
problemas sem criar muitos efeitos colaterais.
On 5/31/07, Marinho Brandao <mar...@gmail.com> wrote:
>
Marinho Brandao
salvo em algumas situações específicas, eu não conheço evidências de
que fidelidade ao relacional seja uma vantagem. O MySQL e o SQLite são
provas disso.
Em 01/06/07, Ricardo Bánffy<rba...@gmail.com> escreveu:
Julio Nobrega
>
> Acho que cabe uma pergunta interessante: Por que chaves múltiplas são
> importantes?
Eu não sei :p
Nunca usei, nunca quis usar. Talvez datacenters gigantes, tipo os
tais de "Storage XXX" da vida, vejam vantagem em salvar bytes ao não
definir uma coluna extra... e os modeladores/DBA puristas se recusem
em ter uma coluna a mais quando poderia não ter, é uma informação
desnecessária...
Mas sinceramente, até já passei por situações em que eu poderia ter
usado, mas preferi não. Gosto da simplicidade: Se tem uma coluna id, é
int, é chave primária, então eu sei o que é. Não preciso ficar
voltando à documentação do design, às definições da tabela... Não tem
enrolação, view, suporte ou não de aplicativos, pra mim fica mais
claro. Sou do tipo que faz as coisas pensando na manutenabilidade do
código, mas claro, sou programador e não admin de servidor ou DBA,
então eu puxo a sardinha para o meu lado ;)
--
Julio Nobrega - http://www.inerciasensorial.com.br
Ricardo Bánffy
"livrarmos da bagagem"?
Excetuando sistemas legados em que isso seja obrigatório por questóes
histéricas, as razões para isso me escapam totalmente.
Sério: quem precisa disso? Há bons motivos?
André Duarte
> Nunca usei, nunca quis usar.
Recentemente em um projeto para portar uma app em Delphi para Django
me deparei com o problemas das chaves múltiplas. Como a base de dados
já existia, não tive dúvida, criei mais uma coluna id e pronto, ainda
durmo tranqüilo!
Julio Nobrega
>
> Mas volto a pergunta: Isso é mesmo necessário ou é tempo de nos
> "livrarmos da bagagem"?
>
> Excetuando sistemas legados em que isso seja obrigatório por questóes
> histéricas, as razões para isso me escapam totalmente.
>
> Sério: quem precisa disso? Há bons motivos?
Há sim... aquele do espaço ocupado é um bom motivo. O custo por giga
de datacenters é muito mais alto que apenas comprar um HD. Digamos que
você compre um HD de 120 GB por 150 reais. Um datacenter vai gastar
muito mais.. primeiro porquê precisa ser SCSI/SATA, ter RPM alto, vão
ter que ser dois ou mais disco para fazer RAID, tem que fazer o backup
(mais discos), todo o espaço, rack, suporte, equipe, refrigeração... e
assim vai.
Agora imagine uma instituição tipo um supermercado guardando as
transações indefinitivamente para auditoria e motivos fiscais. Aquela
coluna ID, mesmo sendo apenas números, que isoladamente ocuparia uns
poucos kbytes, de repente multiplica-se e vira Gigabytes! Sem falar
que a mera presença de mais uma coluna (aumentando o tamanho da tabela
no disco e o trabalho do RDBMS) pode tornar as consultas mais lentas!
Essas simples colunas em várias tabelas vão custar muito dinheiro em
alguns anos.
Eu sou da opinião que o tempo gasto por desenvolvedor se preocupando
com chave primária múltipla é mais caro que tudo isso junto, mas
também... eu nunca administrei datacenters ;)
Outro motivo é que é _estranho_ em termos de modelagem. Um exemplo
com múltiplas, e um sem:
tabela jogo:
time_casa_id
time_visitante_id
Põe os dois como chave primário e pronto. Agora sem múltiplo:
tabela jogo:
id
time_casa_id
time_visitante_id
E aí você vai ter que colocar a primária no id e um UNIQUE nos
outros dois (tem que proteger a integridade). É estranho porquê na
teoria não faz sentido isso, você olha e fala: Mas que diabos, pra quê
essa coluna id? Trabalho a mais, chave a mais, dados a mais, modelo a
mais... e assim vai.
Esses são os motivos que eu consigo imaginar. Eu não mudaria meu
jeito de fazer as coisas por eles, mas é batata que tem gente aí no
mundo que o ganha-pão dele depende disso.
Marinho Brandao
eu não só concordo como agradeço sua disposição em explanar um pouco
melhor. Mas uma observaçãozinha básica sobre uma frase:
> (tem que proteger a integridade)
é exatamente isso que o *pessoal do relacional* precisa entender: no
MVC, quem protege a integridade é o >Model<, então o coerente é usar
do banco apenas aquilo que ele oferece como vantagem real, ou seja, se
uma ForeignKey está ali porque oferece maior performance, perfeito,
mas se ela o está por motivos de integridade, passa fogo nela.
pra quê redundar validação se o MVC está aí exatamente para melhorar isso?
e eu repito: pegue o MySQL 3 e o SQLite. Quer performance melhor? E
eles não "ferem" um número muito grande de definições do relacional.
Porque será?
PS: obviamente não estou aqui considerando casos específicos como
cálculo de folha de pagamento, etc. Meu foco são aplicações onde o
resgate de informação é maior que a persistência.
Em 01/06/07, Julio Nobrega<ine...@gmail.com> escreveu:
Andrews Medina
Chaves primárias compostas podem serem substituídas sim por uniques
mas vamos a um exemplo:
Vai que eu tenho um sistema multi empresas, e nesse sistema eu tenho
os funcionários e cada empresa conta o código de funcionário de forma
distinta ou seja, a empresa 1 tem um funcionário com o código 15 e a
empresa 2 tem outro funcionário que o código tam´bem é 15
Um modelo usando chaves compostas:
Tabela: Empresas
CodigoEmpresa (PK)
Nome
...
Tabela Funcionário
CodigoFuncionario (PK)
CodigoEmpresa (PK)
Eu prefiro da forma acima, (se o banco permitir)...
Se não permitir pode ser usado assim:
Tabela: Empresas
CodigoEmpresa (PK)
Nome
...
Tabela Funcionário
ID (PK)
CodigoFuncionario (UK)
CodigoEmpresa (UK)
A diferença que além de uma chave primária, é necessário a criação de
uma chave única. E seguindo as leis de normalização de dados e as leis
relacionais o ideal seria o ´codigo do funcionário ser chave.
Muitos podem não gostar de chaves compostas, todos podemos viver sem
elas, ma ela também são úteis e por isso existem.
Os SGDB's mais maduros como o ORACLE, PostGreSQL, FIreBird trabalham
normalmente com chaves compostas.
Repetindo: chaves compostas podem serem uteis, mas relacionalmente
falando são ideais.
Se seu problema exigir e seu banco, ORM, tiver suporte, não vejo o
porque de não usá-las.
Marinho Brandao
> e eu repito: pegue o MySQL 3 e o SQLite. Quer performance melhor? E
> eles não "ferem" um número muito grande de definições do relacional.
> Porque será?
deveria estar assim:
e eu repito: pegue o MySQL 3 e o SQLite. Quer performance melhor? E
eles FEREM um número muito grande de definições do relacional.
Porque será?
:)
Em 01/06/07, Andrews Medina<andrew...@gmail.com> escreveu:
Gustavo Gonçalves
Chaves compostas podem ser úteis...
Uma chave primária tem que ter seu valor único na tabela. Já chaves compostas por dois campos por exemplo, nestes campos valores podem ser repetidos, mas nunca a combinação dos dois valores. Este pode ser um comportamento interessante em um projeto.
Vejamos: Em uma tabela denominada ALUNO temos duas colunas: USUÁRIO e TURMA.
A coluna USUÁRIO e TURMA formam uma chave composta. Podemos ter valores repetidos nestas colunas, mas nunca poderemos ter registros onde o valor de USUÁRIO e TURMA sejam iguais.
Muitos podem dizer "mas isso eu faço no código", e caímos naquela discussão sobre usar os recursos que os bancos de dados oferecem ou fazer tudo na mão para não haver problema de incompatibilidade em um caso de migração.
A meu ver, chaves compostas são amplamente implementadas nos sistemas de banco de dados, e seria legal termos a implementação no Django também.
Abraços!
--
Gustavo H. de A. Gonçalves
Fundação Aprender
Centro de Estudos, Pesquisa e Tecnologia
www.fundacaoaprender.org.br
(35)3471-4181
Andrews Medina
> Prezados,
>
concordo conigo, seu exemplo foi equivalente ao meu
Ricardo Bánffy
dados da tabela jogo você vai perder em cada registro que
referenciá-lo como chave estrangeira. O argumento de armazenagem não
cola.
O segundo ponto, o do modelo, pede que se entenda a coluna id não como
dado, mas como uma referência.
On 6/1/07, Julio Nobrega <ine...@gmail.com> wrote:
>
Sebastian SWC
Acessem e participem do fórum de postgresql brazuca: http://postgresql.blog.br/forum/
Rodrigo Senra
-----------------------------------------------
|
|Mas volto a pergunta: Isso é mesmo necessário ou é tempo de nos
|"livrarmos da bagagem"?
|
|Excetuando sistemas legados em que isso seja obrigatório por questóes
|histéricas, as razões para isso me escapam totalmente.
|
|Sério: quem precisa disso? Há bons motivos?
Oi Bánffy,
Já rolaram dois bons exemplos concretos do uso de chaves compostas,
vou tentar dar um exemplo abstrato. ;o)
Suponha a existência de duas relações A e B. Agora suponha que exista
um relacionamento entre A e B cuja cardinalidade se um-para-um.
Ao mapear este MER para tabelas concretas, o relacionamento A-B_1-1
vai virar uma tabela com chave composta.
Este não é o único padrão que torna chaves compostas úteis, mas é
simples e frequente o suficiente ;o)
Abração
Senra