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?
Em 31/05/07, Walter Cruz<walter....@gmail.com> escreveu:
> 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?
> Em 31/05/07, Walter Cruz<walter....@gmail.com> escreveu: > > 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?
> O que nos leva à, inevitavelmente, a entropia sistêmcia geradora da seguda > pergunta:
> O Alchemy algum dia será o ORM 'oficial' do Django?
> Alguém sabe?
> []'s > - Walter
> On 5/31/07, Andrews Medina <andrewsmed...@gmail.com> wrote:
> > Em 31/05/07, Walter Cruz<walter....@gmail.com> escreveu: > > > 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?
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".
> 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.
> 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<andrewsmed...@gmail.com> escreveu:
> já o ORM do Django foi feito sob medida para a framework, está bem > adaptado à localização, contrib admin, new forms, validations, etc.
contrib, admin, forms e validations não deveria estar um pouco mais desacoplados do modelo?
(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 :)
> contrib, admin, forms e validations não deveria estar um pouco mais desacoplados do modelo?
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<walter....@gmail.com> escreveu:
> > já o ORM do Django foi feito sob medida para a framework, está bem > > adaptado à localização, contrib admin, new forms, validations, etc.
> contrib, admin, forms e validations não deveria estar um pouco mais > desacoplados do modelo?
> (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 :)
Acho que cabe uma pergunta interessante: Por que chaves múltiplas são 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 <mari...@gmail.com> wrote:
> > contrib, admin, forms e validations não deveria estar um pouco mais desacoplados do modelo?
> 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<walter....@gmail.com> escreveu:
> > > já o ORM do Django foi feito sob medida para a framework, está bem > > > adaptado à localização, contrib admin, new forms, validations, etc.
> > contrib, admin, forms e validations não deveria estar um pouco mais > > desacoplados do modelo?
> > (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 :)
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<rban...@gmail.com> escreveu:
> Acho que cabe uma pergunta interessante: Por que chaves múltiplas são > 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 <mari...@gmail.com> wrote:
> > > contrib, admin, forms e validations não deveria estar um pouco mais desacoplados do modelo?
> > 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<walter....@gmail.com> escreveu:
> > > > já o ORM do Django foi feito sob medida para a framework, está bem > > > > adaptado à localização, contrib admin, new forms, validations, etc.
> > > contrib, admin, forms e validations não deveria estar um pouco mais > > > desacoplados do modelo?
> > > (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 :)
On 6/1/07, Ricardo Bánffy <rban...@gmail.com> wrote:
> 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 ;)
> On 6/1/07, Ricardo Bánffy <rban...@gmail.com> wrote:
> > 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 ;)
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!
On 6/1/07, Ricardo Bánffy <rban...@gmail.com> wrote:
> 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.
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:
> On 6/1/07, Ricardo Bánffy <rban...@gmail.com> wrote:
> > 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.
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
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.
> 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<andrewsmed...@gmail.com> escreveu:
> 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 > ...
> 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.
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
Em compensação, todo o espaço que você ganhou no armazenamento dos 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:
> On 6/1/07, Ricardo Bánffy <rban...@gmail.com> wrote:
> > 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.
mesmo sendo "culpa" minha a criação desse tópico, acredito que é apenas uma questão de ponto de vista, ou seja, temos que nos acostumar com as "limitações" e "ganhos" do mvc
On 6/1/07, Ricardo Bánffy <rban...@gmail.com> wrote:
> Em compensação, todo o espaço que você ganhou no armazenamento dos > 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:
> > On 6/1/07, Ricardo Bánffy <rban...@gmail.com> wrote:
> > > 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:
> > 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.
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".
|
