Primary Key Composta
Emanuell Faustino
Minha tabela possui chaves primaria composta.
Como espelho isto no Rails?
[]'s
--
Emanuell Faustino
Davis Cabral - Listas
--
Davis <davis...@gmail.com>
Impact Media
--
Buscarros - Classificados de veículos
http://www.buscarros.com.br/
--
C: +55 45 9928 0815
B: http://blog.impactmedia.com.br/
Julio Santos Monteiro
Se não for possível, eis uma página que pode te auxiliar:
http://wiki.rubyonrails.com/rails/pages/HowToUseLegacySchemas
Abraços!
On 20 jun, 15:50, "Emanuell Faustino" <emanuellfaust...@gmail.com>
wrote:
Emanuell Faustino
--
Emanuell Faustino
Mário Júnior
Verdade mesmo, resolve... mas não é o correto galera, isso seria uma forma de "legalizarmos as gambiarras".
Certo que o Padrão do Rails permite apenas um ID, e de fato essa é a maneira mais correta, mas acredito que ninguem aqui é da geração nascida em RoR, como eu vieram de outras linguagens e de outros paradigmas (levanta a mão quem já começou a desenhar uma aplicação pelo banco de dados, eu !!!!) em outros tempos pensávamos assim, e isso acabava em cagada.. eu mesmo adorava chaves compostas (no máximo duas, eu juro!).
Hj é diferente, mas ainda assim não dá pra jogar tudo fora e começar do zero. Eu mesmo estou desenvolvendo um módulo web de um sistema desktop que tem uma tabela no seu bd com 11, isso mesmo, 11 campos q formam a chave primária... e fazer oq, eu não posso me dar ao luxo de jogar isso fora (esse banco já tem 9 anos de idade) e tb não posso criar um ID lá (bem q resolveria, santa gambi) mas prefiro adotar a filosofia de "encare o problema: ou vc o mata, ou vc morre" doq adotar o "contorne o problema, fique agonizando e depois qnd der pau joga a culpa no mané q projetou o banco"
Embora eu não esteja desenvolvendo esse projeto com RoR (q pena...) eu já brinquei com chaves compostas no RoR (até 4 campos) e fiquei feliz com essa solução... então a indico aqui para galera:
http://compositekeys.rubyforge.org/
muito pratica e funcional, eu agarantio! hehehe
Abraços,
Júnior
--
Mário de Souza Júnior
Programador
(44) 4009-3550
Arthur Henrique Zapparoli
Então, ao invés de usarmos "gambiarras", simplesmente não usemos o
Rails! Muito mais simples.
Ele não foi criado para que todos projetos fossem escrito com ele!
Um bom programador sabe escolher certos frameworks/linguagens para
certos projetos, ao invés de querer usar um framework ou linguagem
para tudo.
É minha humilde opinião.
--
[]'s
Arthur Zapparoli
http://www.arthurgeek.net
Pedro Mariano Belo
trabalhando profissionalmente) temos que fazer coisas encaixarem nele,
faz parte. Mas depois que você aceita esta natureza tudo fica mais
fácil (ou, para mim ficou, hehe).
Por sinal acho que nenhum framework é bom em se adequar ao seu
problema. É sempre o caminho inverso, não é mesmo?
Emanuell Faustino
Desculpe a ignorância mas, ter chaves composta(atualmente) é errado?
[]'s
--
Emanuell Faustino
leandro n. camargo
> Mario,
>
> Desculpe a ignorância mas, ter chaves composta(atualmente) é errado?
>
> []'s
Não, não é errado e as vezes é o mair correto, acredite.
Não há o que se envergonhar em usar uma chave estrangeira composta, as
vezes é o mais correto e mais elegante. =]
Mário Júnior
qnd se desenvolve orientado a objetos desde o começo do projeto, presume-se já que seus objetos terão um id, apenas para identificá-lo como único.
Depois q comecei a usar OOP a fundo nunca mais fiz chaves compostas, e pra falar a verdade, banco de dados é minha ultima preocupação hj... depois q tenho tudo modelado daí sim parto para o banco.
Agora se vc tiver uma necessidade extremamente especial, então use chave composta... mas eu só recomendo em caso extremamente especial.
Abraços, precisando de ajuda tamo ae!
Mário Júnior
Ela é quem dá a identidade dele, e relacionamentos são para outra coisa, somente para criar vinculos ... essa é sua finalidade.
Entendeu.. finalidades diferentes.. objetivos diferentes.
Mas como tudo são "campos" os bancos de dados permitem a vinculação deles na chave primária, formando
assim as "chaves compostas"
Abraços!
Felipe Ribeiro
identificar algo, pelo menos na minha opinião, num sistema de login,
porque o login não poderia ser a chave primária? é único e é a melhor
representação daquela entidade.Ou não?
On 6/20/07, Mário Júnior <junin...@gmail.com> wrote:
--
Felipe Ribeiro
feli...@gmail.com
http://feliperibeiro.com
83 9979-3161
Weverton Gomes
Não acho tão elegante assim Leandro... chaves primárias foram feitas para identificar seu objeto.
--
Weverton Gomes de Morais
Tecnólogo em Redes de Comunicação
Desenvolvedor Delphi
Entusiasta Ruby/Rails
"Todos juntos somos fortes"
Ronaldo Ferraz
Ronaldo
On 6/20/07, Emanuell Faustino <emanuell...@gmail.com> wrote:
--
Take back the Web. Download Mozilla Firefox.
http://www.mozilla.org/
Nando Vieira
> E as vezes, nem sempre um número (id) é a melhor maneira de
> identificar algo, pelo menos na minha opinião, num sistema de login,
> porque o login não poderia ser a chave primária? é único e é a melhor
> representação daquela entidade.Ou não?
Acho que ID (integer) deve ser sempre o identificador. A informação
que hoje é única na empresa devido à regra de negócios atual não será
necessariamente a mesma daqui 3, 4 ou 5 anos.
--
Nando Vieira
bloggin' @ http://simplesideias.com.br
money @ http://spesa.com.br
Emanuell Faustino
Algumas delas são: Tempo(e como!), Facilidade, Servidor menos robusto, etc, etc.
Dei uma pesquisada e decidir escolher.
Emanuell Faustino
Algumas delas são: Tempo(e como!), Facilidade, Servidor menos robusto, etc, etc.
Dei uma pesquisada e decidir escolher.
On 6/20/07, Emanuell Faustino <emanuell...@gmail.com> wrote:
Ronaldo Ferraz
facilitar o mapeamento objeto-relacional na maioria dos frameworks
existentes. Do ponto de vista de um banco de dados, é uma chave
surrogada na maior parte dos casos não tem absolutamente nada a ver
com o modelo de dados. Chaves naturais (compostas ou não) são
apropriadas em qualquer caso.
No final das contas é um trade-off. O ID facilita a vida, mas introduz
problemas na maior parte dos modelos (validação, unicidade, etc) que
muitos programadores não tratam. So, here be dragons. :-)
Ronaldo
Emanuell Faustino
Filipe Coimbra
Por que o identificador de um objeto não pode ser dois campos
trabalhando em conjunto? Ou um campo não necessariamente
autoincrementável e chamado de alguma coisa que não seja 'id'?
Ora, continuam identificando o objeto. De maneiras diferentes, mas
identificam. :)
Eu não vejo problemas em ter um campo de CPF, login, whatever servindo
como chave primária, caso isso solucione meu problema.
Mas eu confesso que trabalho há muito tempo usando a mesma filosofia
do Rails por pura preguiça, já que não preciso me preocupar em criar
sequências para compor uma chave composta, testar a chave antes de
inserir ou testar a resposta do banco de dados para saber se houve um
erro (e descobrir qual o erro). O tal do 'id' torna tudo bem mais
simples.
On 6/20/07, Emanuell Faustino <emanuell...@gmail.com> wrote:
> Então,
>
> Cada um com sua preferência!
--
-------------------------------------------------------
Filipe Coimbra
filipe.grupos[at]gmail[dot]com
Davis Zanetti Cabral
Optamos por mudar agora para cada tabela ter um proprio identificador, até pq esse nosso projeto é como um laboratorio.
Até o momento está sendo uma opção muito adequada. A modelagem nova do banco foi feita toda assim.
Estou usando o Castle, que é um framework .NET com AR, Monorails e uma cara de Rails! :-)
Eu não tenho conhecimento de teorias, pq isso é assim e aquilo outro é daquele jeito. Mas na prática, até hoje o lance de um id único me pareceu muito eficaz.
Mas para bases replicadas, o lance de chave compostas realmente é importante.
Mas eu não tenho essa necessidade.
:)
meus 2 cents
--
att.,
Davis Zanetti Cabral
--
Impact Media Soluções para Web
http://www.impactmedia.com.br/
leandro n. camargo
> Mas para bases replicadas, o lance de chave compostas realmente é
> importante.
> Mas eu não tenho essa necessidade.
>
> :)
>
> meus 2 cents
As vezes usar chave primária composta ou não que não envolva puramente
o famoso 'id' é também uma questão de semântica. Ter um XHTML
semântico, um XML semântico ou um código server-side semântico e não
ter um modelo relacional semântico é meio, digamos... incoerente. Usar
PK para os campos que realmente merecem ser PK deixa inclusive o seu
modelo mais conciso, mesmo para aqueles que seguem o paradigma de
regras de negócio s com UML e tal. Pois mesmo que sua ferramente de
UML deixe-o despreocupado com o seu banco é importante você ter
conhecimento para lapidar o seu modelo conceitual de banco de dados,
não é verdade?
Em 20/06/07, Nando Vieira <fnando...@gmail.com> escreveu:
> Acho que ID (integer) deve ser sempre o identificador. A informação
> que hoje é única na empresa devido à regra de negócios atual não será
> necessariamente a mesma daqui 3, 4 ou 5 anos.
Então é simples: hora de mudar a estrutura do seu banco, mude tais campos.
ALTER TABLE e UPDATE estão aí pra isso, se necessários. Deixar as
coisas mais práticas não implica em deixar as coisas mais coerentes.
Contornar uma dor de cabeça mordendo o braço é substituir um dor por outra.
Nando Vieira
> ALTER TABLE e UPDATE estão aí pra isso, se necessários. Deixar as
> coisas mais práticas não implica em deixar as coisas mais coerentes.
> Contornar uma dor de cabeça mordendo o braço é substituir um dor por outra.
Não diria que é tão simples. Imagine mudar um sistema legado de anos,
sem que quebre todos os sistemas da empresa.
But whatever... nunca precisei usar chaves primárias compostas e,
provavelmente, não irei precisar.
Juan Maiz
Não o Rails não foi feito pra você, amigo, a não ser q você o faça. Cada parafuso tem sua porca.
Se você pegar a referencia do Rails (o livro) vai ver claramente: Na dúvida use id em suas tabelas.
Além disso rails foi desenvolvido com a filosofia de lógica fora do banco, o que, para o tipo de projeto "default" que eu trabalho (integração de vários sistemas legados, desenvolvimento de nossos projetos com uma base já existentte ou desenvolvimento de projetos cuja base deverá ser usada por N sistemas) isso é ruim.
Fui!
Juan Maiz Lulkin Flores da Cunha
http://en.wikipedia.org/wiki/User:Juanmaiz
Juan Maiz
O caso clássico é que você tem uma tabela intermediária enorme, e as consultas em geral são realidas sobre a perspecitiva de alguma das chaves compostas. Se você manter um id único nesta tabela, vai sempre ter de fazer joins com ela, e isso será um problema de performance...
Fui.
Juan Maiz
"A maioria dos clientes que dou consultoria criou um banco extremamente elegante, todo normalizado... Quando digo para eles que a solução é desnormalizar, a primeira reação que eles têm é querer me jogar pela janela."
Particularmente, uma coisa que adoro, são campos array no banco... Longa vida a eles!
Fui!
--
Julio Santos Monteiro
Particularmente eu acho o contrário. O desenvolvimento é rápido no
Rails exatamente porque, se aceitarmos padrões impostos pelo mesmo,
estaremos deixando o framework "desconbrir as coisas por sí só".
Portanto, nós é que nos devemos nos adequar aos padrões do Rails para
tirar benefício dele.
Obviamente, deve ter (tem) alguma maneira de utilizar chaves
compostas; mas até hoje nunca me deparei com um problema que tive de
utilizar uma chave composta. Sempre utilizo o velho feijão com arroz:
um para muitos, muitos para um, muitos para muitos (utilizando uma
tabela associativa), com as velhas e boas IDs para indexar tudo.
Só para deixar bem claro: eu sei que, em um sistema pesado, tem
problemas de performace, mas até hoje não montei um sistema que
exigisse tanta performace assim. O MySQL tweaked sempre deu conta do
recado :-).
Abraços!
On 20 jun, 17:29, "Emanuell Faustino" <emanuellfaust...@gmail.com>
wrote:
> O Rails não deveria se adequar a nós? ao invés de nós adequarmos a ele...
>
> Em 20/06/07, Julio Santos Monteiro <juliomonte...@gmail.com> escreveu:
Osvaldo TC Filho
Valeu.
--
Osvaldo TC Filho
e-mail enviado diretamente do gmail,
livre de virus!
Tássio Virgínio
Eu uso aqui no trabalho !
--
-+-+-+-+-+-+-+-\________________________
# NTI - FACAPE - Ciência da Computação #
# GUJPE - www.gujpe.com #
Tássio Guerreiro A. Virgínio - Petrolina - PE
Ruby on Rails + Struts + Hibernate +Firebird
__Usuário Linux: 415659__/++++++++++++
Rodrigo Ramalho
--
--
Rodrigo Ramalho Xavier (ro...@live.com, MSN)
--
Equipe SpeedCASE - TecnoSpeed TI
http://www.speedcase.com.br
--
