Re: [pgbr-geral] Chave Primaria Composta
Em meu sistema a parte de controle devusuarios é composta nunca tive problemas Em 25/08/2016 11:06, "Gustavo" escreveu: > > mais um detalhe, com a chave composta > evita um monte de triggers para ajuste de algumas informações também, > erros de programação > e menos manutenção > ᐧ > > Em 25 de agosto de 2016 10:56, Guimarães Faria Corcete DUTRA, Leandro < > l...@dutras.org> escreveu: > >> 2016-08-25 10:49 GMT-03:00 Gustavo : >> > >> > Razão, seria as lendas urbanas que sempre eu via sobre isso... >> >> Boa definição. >> >> >> > agora você me dizendo que é uma otima ideia ja até pensei em uma chave >> primaria com 3 campos >> >> Não há limite, exceto praticidade. E mesmo assim, às vezes deixa-se >> de usar por ‘otimização precoce’: teme-se o efeito da propagação duma >> chave com, digamos, quatro ou cinco atributos por tabelas filhas >> (chaves estrangeiras), mas deixa-se de levar em conta todas as junções >> e índices que uma chave natural economiza. >> >> >> > vamos analisar da seguinte maneira. se não fosse uma boa prática não >> teria essa opção para ser usada no banco de dados... >> >> Infelizmente essa lógica nem sempre se aplica. Por exemplo, herança >> geralmente não é boa idéia, pelo menos não no modelo lógico; no modelo >> físico, foi útil para gambiarrar particionamento de tabelas. >> >> >> -- >> skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra >> +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org >> +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 >> BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm >> ___ >> pgbr-geral mailing list >> pgbr-geral@listas.postgresql.org.br >> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral >> > > > ___ > pgbr-geral mailing list > pgbr-geral@listas.postgresql.org.br > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Chave Primaria Composta
Em 25 de agosto de 2016 11:33, Gustavo escreveu: > > (lembro que eram quase 4 mil tabelas), ouch ! > > o meu só tem 1.000 tabelas... será que terei problemas com performance O número de tabelas não é preponderante no impacto de desempenho. Alguns softwares/sistemas muito bem escritos conseguem ter uma quantidade imensa de tabelas mas aplicando no mínimo a 3FN, com cada tabela/entidade servindo a um propósito específico com poucas colunas/atributos - muito bem indexadas, claro. TIAGO J. ADAMI ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Chave Primaria Composta
Depende, lá como eu disse as chaves compostas foram usadas de forma errada, era uma estrutura de grupo, empresa, filial, unidade + chave_negocio_tabela, então de cara qualquer PK já tinha no mínimo 5 campos! Sem contas outras gambiarras que não vem ao caso aqui. Em 25 de agosto de 2016 11:33, Gustavo escreveu: > (lembro que eram quase 4 mil tabelas), ouch ! > > o meu só tem 1.000 tabelas... será que terei problemas com performance > > ᐧ > > Em 25 de agosto de 2016 11:26, Fabiano Machado Dias < > fabi...@wolaksistemas.com.br> escreveu: > >> O maior problema era o inchaço do banco (lembro que eram quase 4 mil >> tabelas), além da escrita de consultas, um join básico ficava gigante, >> imagina então algo maior como um SPED! >> >> Não tenho mais contato com esse sistema, mas sei que até hoje sofre com >> problemas de performance nos clientes que usam. >> >> >> >> Em 25 de agosto de 2016 11:20, Guimarães Faria Corcete DUTRA, Leandro < >> l...@dutras.org> escreveu: >> >>> 2016-08-25 11:12 GMT-03:00 Fabiano Machado Dias < >>> fabi...@wolaksistemas.com.br>: >>> > >>> >> Não há limite, exceto praticidade. E mesmo assim, às vezes deixa-se >>> >> de usar por ‘otimização precoce’: teme-se o efeito da propagação duma >>> >> chave com, digamos, quatro ou cinco atributos por tabelas filhas >>> >> (chaves estrangeiras), mas deixa-se de levar em conta todas as junções >>> >> e índices que uma chave natural economiza. >>> > >>> > Este é o ponto onde se deve ter cuidado, eu já vi um ERP onde no nível >>> mais >>> > baixo da contabilidade (rateio de centro de custo) a chave primária da >>> > tabela tipo por volta de 15 campos!!! >>> >>> Para isso que se criam chaves artificiais, que nem precisam ser >>> primárias. Na verdade, o ideal é que não sejam, para que o modelo >>> fique mais claro e para que nunca se esqueça de definir ao menos uma >>> chave natural. >>> >>> >>> > Imagine como era trabalhar com uma modelagem desta! >>> >>> Com um ferramental adequado, não devia ser problema algum. Eu fazia >>> isso com COPYs Cobol, sem dramas. Vi muito javeiro reclamando, e >>> questionava-os por que o Java seria tão inferior ao Cobol para fazer >>> algo tão básico. >>> >>> O que tem de ver é se essa propagação de chaves compostas não seria um >>> problema de armazenamento ou consumo de memória. Poderia em tese ser, >>> e geralmente não é, até por evitar criar campos e índices adicionais >>> para as chaves artificiais. >>> >>> Agora, se o ferramental é ruim ou mal usado… infelizmente, uma >>> situação comum. Espere problemas com usuários mais ingênuos de ORM, >>> por exemplo. >>> >>> >>> -- >>> skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra >>> +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org >>> +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 >>> BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm >>> ___ >>> pgbr-geral mailing list >>> pgbr-geral@listas.postgresql.org.br >>> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral >>> >> >> >> ___ >> pgbr-geral mailing list >> pgbr-geral@listas.postgresql.org.br >> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral >> > > > ___ > pgbr-geral mailing list > pgbr-geral@listas.postgresql.org.br > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Chave Primaria Composta
(lembro que eram quase 4 mil tabelas), ouch ! o meu só tem 1.000 tabelas... será que terei problemas com performance ᐧ Em 25 de agosto de 2016 11:26, Fabiano Machado Dias < fabi...@wolaksistemas.com.br> escreveu: > O maior problema era o inchaço do banco (lembro que eram quase 4 mil > tabelas), além da escrita de consultas, um join básico ficava gigante, > imagina então algo maior como um SPED! > > Não tenho mais contato com esse sistema, mas sei que até hoje sofre com > problemas de performance nos clientes que usam. > > > > Em 25 de agosto de 2016 11:20, Guimarães Faria Corcete DUTRA, Leandro < > l...@dutras.org> escreveu: > >> 2016-08-25 11:12 GMT-03:00 Fabiano Machado Dias < >> fabi...@wolaksistemas.com.br>: >> > >> >> Não há limite, exceto praticidade. E mesmo assim, às vezes deixa-se >> >> de usar por ‘otimização precoce’: teme-se o efeito da propagação duma >> >> chave com, digamos, quatro ou cinco atributos por tabelas filhas >> >> (chaves estrangeiras), mas deixa-se de levar em conta todas as junções >> >> e índices que uma chave natural economiza. >> > >> > Este é o ponto onde se deve ter cuidado, eu já vi um ERP onde no nível >> mais >> > baixo da contabilidade (rateio de centro de custo) a chave primária da >> > tabela tipo por volta de 15 campos!!! >> >> Para isso que se criam chaves artificiais, que nem precisam ser >> primárias. Na verdade, o ideal é que não sejam, para que o modelo >> fique mais claro e para que nunca se esqueça de definir ao menos uma >> chave natural. >> >> >> > Imagine como era trabalhar com uma modelagem desta! >> >> Com um ferramental adequado, não devia ser problema algum. Eu fazia >> isso com COPYs Cobol, sem dramas. Vi muito javeiro reclamando, e >> questionava-os por que o Java seria tão inferior ao Cobol para fazer >> algo tão básico. >> >> O que tem de ver é se essa propagação de chaves compostas não seria um >> problema de armazenamento ou consumo de memória. Poderia em tese ser, >> e geralmente não é, até por evitar criar campos e índices adicionais >> para as chaves artificiais. >> >> Agora, se o ferramental é ruim ou mal usado… infelizmente, uma >> situação comum. Espere problemas com usuários mais ingênuos de ORM, >> por exemplo. >> >> >> -- >> skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra >> +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org >> +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 >> BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm >> ___ >> pgbr-geral mailing list >> pgbr-geral@listas.postgresql.org.br >> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral >> > > > ___ > pgbr-geral mailing list > pgbr-geral@listas.postgresql.org.br > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Chave Primaria Composta
2016-08-25 11:12 GMT-03:00 Fabiano Machado Dias : > >> Não há limite, exceto praticidade. E mesmo assim, às vezes deixa-se >> de usar por ‘otimização precoce’: teme-se o efeito da propagação duma >> chave com, digamos, quatro ou cinco atributos por tabelas filhas >> (chaves estrangeiras), mas deixa-se de levar em conta todas as junções >> e índices que uma chave natural economiza. > > Este é o ponto onde se deve ter cuidado, eu já vi um ERP onde no nível mais > baixo da contabilidade (rateio de centro de custo) a chave primária da > tabela tipo por volta de 15 campos!!! Para isso que se criam chaves artificiais, que nem precisam ser primárias. Na verdade, o ideal é que não sejam, para que o modelo fique mais claro e para que nunca se esqueça de definir ao menos uma chave natural. > Imagine como era trabalhar com uma modelagem desta! Com um ferramental adequado, não devia ser problema algum. Eu fazia isso com COPYs Cobol, sem dramas. Vi muito javeiro reclamando, e questionava-os por que o Java seria tão inferior ao Cobol para fazer algo tão básico. O que tem de ver é se essa propagação de chaves compostas não seria um problema de armazenamento ou consumo de memória. Poderia em tese ser, e geralmente não é, até por evitar criar campos e índices adicionais para as chaves artificiais. Agora, se o ferramental é ruim ou mal usado… infelizmente, uma situação comum. Espere problemas com usuários mais ingênuos de ORM, por exemplo. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Chave Primaria Composta
O maior problema era o inchaço do banco (lembro que eram quase 4 mil tabelas), além da escrita de consultas, um join básico ficava gigante, imagina então algo maior como um SPED! Não tenho mais contato com esse sistema, mas sei que até hoje sofre com problemas de performance nos clientes que usam. Em 25 de agosto de 2016 11:20, Guimarães Faria Corcete DUTRA, Leandro < l...@dutras.org> escreveu: > 2016-08-25 11:12 GMT-03:00 Fabiano Machado Dias < > fabi...@wolaksistemas.com.br>: > > > >> Não há limite, exceto praticidade. E mesmo assim, às vezes deixa-se > >> de usar por ‘otimização precoce’: teme-se o efeito da propagação duma > >> chave com, digamos, quatro ou cinco atributos por tabelas filhas > >> (chaves estrangeiras), mas deixa-se de levar em conta todas as junções > >> e índices que uma chave natural economiza. > > > > Este é o ponto onde se deve ter cuidado, eu já vi um ERP onde no nível > mais > > baixo da contabilidade (rateio de centro de custo) a chave primária da > > tabela tipo por volta de 15 campos!!! > > Para isso que se criam chaves artificiais, que nem precisam ser > primárias. Na verdade, o ideal é que não sejam, para que o modelo > fique mais claro e para que nunca se esqueça de definir ao menos uma > chave natural. > > > > Imagine como era trabalhar com uma modelagem desta! > > Com um ferramental adequado, não devia ser problema algum. Eu fazia > isso com COPYs Cobol, sem dramas. Vi muito javeiro reclamando, e > questionava-os por que o Java seria tão inferior ao Cobol para fazer > algo tão básico. > > O que tem de ver é se essa propagação de chaves compostas não seria um > problema de armazenamento ou consumo de memória. Poderia em tese ser, > e geralmente não é, até por evitar criar campos e índices adicionais > para as chaves artificiais. > > Agora, se o ferramental é ruim ou mal usado… infelizmente, uma > situação comum. Espere problemas com usuários mais ingênuos de ORM, > por exemplo. > > > -- > skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra > +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org > +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 > BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm > ___ > pgbr-geral mailing list > pgbr-geral@listas.postgresql.org.br > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Chave Primaria Composta
2016-08-25 11:05 GMT-03:00 Gustavo : > > mais um detalhe, com a chave composta > evita um monte de triggers para ajuste de algumas informações também, > erros de programação > e menos manutenção Vero. Só um detalhe: isso não é exatamente função de chaves compostas, mas de chaves naturais (que podem precisar ser compostas). Na verdade, o pior problema em termos de modelagem é colocar chaves artificiais e não colocar as chaves naturais correspondentes. Qual é primária ou não, não tem a mesma importância para para consistência (integridade) — embora seja importante para evitar junções, por exemplo. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Chave Primaria Composta
> Não há limite, exceto praticidade. E mesmo assim, às vezes deixa-se > de usar por ‘otimização precoce’: teme-se o efeito da propagação duma > chave com, digamos, quatro ou cinco atributos por tabelas filhas > (chaves estrangeiras), mas deixa-se de levar em conta todas as junções > e índices que uma chave natural economiza. > Este é o ponto onde se deve ter cuidado, eu já vi um ERP onde no nível mais baixo da contabilidade (rateio de centro de custo) a chave primária da tabela tipo por volta de 15 campos!!! Imagine como era trabalhar com uma modelagem desta! Att, Fabiano Machado Dias ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Chave Primaria Composta
mais um detalhe, com a chave composta evita um monte de triggers para ajuste de algumas informações também, erros de programação e menos manutenção ᐧ Em 25 de agosto de 2016 10:56, Guimarães Faria Corcete DUTRA, Leandro < l...@dutras.org> escreveu: > 2016-08-25 10:49 GMT-03:00 Gustavo : > > > > Razão, seria as lendas urbanas que sempre eu via sobre isso... > > Boa definição. > > > > agora você me dizendo que é uma otima ideia ja até pensei em uma chave > primaria com 3 campos > > Não há limite, exceto praticidade. E mesmo assim, às vezes deixa-se > de usar por ‘otimização precoce’: teme-se o efeito da propagação duma > chave com, digamos, quatro ou cinco atributos por tabelas filhas > (chaves estrangeiras), mas deixa-se de levar em conta todas as junções > e índices que uma chave natural economiza. > > > > vamos analisar da seguinte maneira. se não fosse uma boa prática não > teria essa opção para ser usada no banco de dados... > > Infelizmente essa lógica nem sempre se aplica. Por exemplo, herança > geralmente não é boa idéia, pelo menos não no modelo lógico; no modelo > físico, foi útil para gambiarrar particionamento de tabelas. > > > -- > skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra > +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org > +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 > BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm > ___ > pgbr-geral mailing list > pgbr-geral@listas.postgresql.org.br > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Chave Primaria Composta
2016-08-25 10:49 GMT-03:00 Gustavo : > > Razão, seria as lendas urbanas que sempre eu via sobre isso... Boa definição. > agora você me dizendo que é uma otima ideia ja até pensei em uma chave > primaria com 3 campos Não há limite, exceto praticidade. E mesmo assim, às vezes deixa-se de usar por ‘otimização precoce’: teme-se o efeito da propagação duma chave com, digamos, quatro ou cinco atributos por tabelas filhas (chaves estrangeiras), mas deixa-se de levar em conta todas as junções e índices que uma chave natural economiza. > vamos analisar da seguinte maneira. se não fosse uma boa prática não teria > essa opção para ser usada no banco de dados... Infelizmente essa lógica nem sempre se aplica. Por exemplo, herança geralmente não é boa idéia, pelo menos não no modelo lógico; no modelo físico, foi útil para gambiarrar particionamento de tabelas. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Chave Primaria Composta
Razão, seria as lendas urbanas que sempre eu via sobre isso... agora você me dizendo que é uma *otima* ideia 😀 ja até pensei em uma chave primaria com 3 campos vamos analisar da seguinte maneira. se não fosse uma boa prática não teria essa opção para ser usada no banco de dados... ᐧ Em 25 de agosto de 2016 10:30, Guimarães Faria Corcete DUTRA, Leandro < l...@dutras.org> escreveu: > 2016-08-25 10:22 GMT-03:00 Gustavo : > > > > eu nunca utilizei uma chave primaria com 2 campos em 12 anos > > Alguma razão para isso? > > > > a pergunta é, seria uma boa pratica utilizar chave primaria composta > > Ótima! > > > > eu terei problemas com isso ? > > Só em situações-limite, muito específicas mesmo. Ou seja, certeza > quase absoluta que não. > > > -- > skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra > +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org > +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 > BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm > ___ > pgbr-geral mailing list > pgbr-geral@listas.postgresql.org.br > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Chave Primaria Composta
2016-08-25 10:22 GMT-03:00 Gustavo : > > eu nunca utilizei uma chave primaria com 2 campos em 12 anos Alguma razão para isso? > a pergunta é, seria uma boa pratica utilizar chave primaria composta Ótima! > eu terei problemas com isso ? Só em situações-limite, muito específicas mesmo. Ou seja, certeza quase absoluta que não. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Chave Primaria Composta
Ola a todos... Uma duvida cruel eu nunca utilizei uma* chave primaria com 2 campos* em 12 anos programando em banco de dados, mais fazendo um projeto novo vejo a possibilidade de usa-los e me ajudaria muito em algumas coisas que quero fazer *a pergunta é, seria uma boa pratica utilizar chave primaria composta, eu terei problemas com isso ?* Agradeço a opinião de vocês sobre esse tema... Gustavo ᐧ ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral