Re: [pgbr-geral] RES: Chave Primaria Composta

2016-08-26 Por tôpico Guimarães Faria Corcete DUTRA , Leandro 
2016-08-26 13:40 GMT-03:00 Silfar Goulart :
>
> Eu prefiro sempre criar uma chave primaria como ID que uso para 
> relacionamentos. E uso chaves Uniques para evitar duplicidade. Para mim é a 
> melhor maneira.

Melhor por quê, se teu modelo fica mais pesado (mais índices) e mais
difícil de usar (mais junções)?

Claro que tens todo o direito de ter opiniões, ainda mais para a tua
situação específica, mas ajuda os outros se as fundamentares.



-- 
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] RES: Chave Primaria Composta

2016-08-26 Por tôpico Silfar Goulart 
Eu prefiro sempre criar uma chave primaria como ID que uso para
relacionamentos. E uso chaves Uniques para evitar duplicidade. Para mim é a
melhor maneira.



Enviado com MailTrack


Silfar Goulart

Em 26 de agosto de 2016 13:03, Tiago José Adami 
escreveu:

> 2016-08-26 0:30 GMT-03:00 Euler Taveira :
> > On 25-08-2016 14:17, Tiago José Adami wrote:
> >>Também há 2 triggers um pouco mais complexos que não permitem
> >>horários conflitantes, algo impossível de tratar apenas com FKs.
> >>
> > Você tentou usar range types [1] e/ou restrições de exclusão [2] (ex.
> [3])?
> >
> > [1] https://www.postgresql.org/docs/9.6/static/rangetypes.html
> > [2]
> > https://www.postgresql.org/docs/9.6/static/sql-createtable.html#SQL-
> CREATETABLE-EXCLUDE
> > [3]
> > http://stackoverflow.com/questions/10759531/exclusion-
> constraint-with-overlapping-timestamp-range#10760028
>
> Inicialmente a implementação dos triggers foi feita ainda quando as
> chaves primárias eram compostas e era necessário validar junto as
> chaves realmente naturais (em campos fora das PKs) pelo código dos
> triggers. Depois de migrar as tabelas para usar chaves naturais
> simplesmente ajustei o código no tocante às chaves e tudo funcionou
> perfeitamente, portanto não procurei algo para substituir os triggers.
>
> Agora que as tabelas possuem chaves naturais adequadas e o projeto
> está quase homologado, vou me planejar para investir um tempo nisso.
>
> TIAGO J. ADAMI
> ___
> 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] RES: Chave Primaria Composta

2016-08-26 Por tôpico Tiago José Adami 
2016-08-26 0:30 GMT-03:00 Euler Taveira :
> On 25-08-2016 14:17, Tiago José Adami wrote:
>>Também há 2 triggers um pouco mais complexos que não permitem
>>horários conflitantes, algo impossível de tratar apenas com FKs.
>>
> Você tentou usar range types [1] e/ou restrições de exclusão [2] (ex. [3])?
>
> [1] https://www.postgresql.org/docs/9.6/static/rangetypes.html
> [2]
> https://www.postgresql.org/docs/9.6/static/sql-createtable.html#SQL-CREATETABLE-EXCLUDE
> [3]
> http://stackoverflow.com/questions/10759531/exclusion-constraint-with-overlapping-timestamp-range#10760028

Inicialmente a implementação dos triggers foi feita ainda quando as
chaves primárias eram compostas e era necessário validar junto as
chaves realmente naturais (em campos fora das PKs) pelo código dos
triggers. Depois de migrar as tabelas para usar chaves naturais
simplesmente ajustei o código no tocante às chaves e tudo funcionou
perfeitamente, portanto não procurei algo para substituir os triggers.

Agora que as tabelas possuem chaves naturais adequadas e o projeto
está quase homologado, vou me planejar para investir um tempo nisso.

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] RES: Chave Primaria Composta

2016-08-25 Por tôpico Euler Taveira 
On 25-08-2016 14:17, Tiago José Adami wrote:
>Também há 2 triggers um pouco mais complexos que não permitem
>horários conflitantes, algo impossível de tratar apenas com FKs.
> 
Você tentou usar range types [1] e/ou restrições de exclusão [2] (ex. [3])?

[1] https://www.postgresql.org/docs/9.6/static/rangetypes.html
[2]
https://www.postgresql.org/docs/9.6/static/sql-createtable.html#SQL-CREATETABLE-EXCLUDE
[3]
http://stackoverflow.com/questions/10759531/exclusion-constraint-with-overlapping-timestamp-range#10760028


-- 
   Euler Taveira   Timbira - http://www.timbira.com.br/
   PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] RES: Chave Primaria Composta

2016-08-25 Por tôpico Guimarães Faria Corcete DUTRA , Leandro 
Posso emoldurar?  ;-)


2016-08-25 15:08 GMT-03:00 Tiago José Adami :
> Em 25 de agosto de 2016 14:42, Guimarães Faria Corcete DUTRA, Leandro
>  escreveu:
>> E imagino que tanto desempenho quanto carga de máquina e de rede,
>> usabilidade e manutenção melhorem muito.
>
> Compreendi teu ponto de vista com a mensagem anterior. Aproveitei para
> lhe dar o crédito da minha implementação - considerando tuas
> incessantes reafirmações na lista para que usemos chaves naturais. Não
> é preciso dizer isso, mas, "Dutra, você sempre esteve certo" :)



-- 
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] RES: Chave Primaria Composta

2016-08-25 Por tôpico Fabiano Machado Dias 
> > 1 - A informação da chave, geralmente não é a que vc quer, então o join
> vai
> > acontecer igual
>
> Discordo. Se suas chaves naturais estão bem definidas, na grande
> maioria das vezes é suficiente. Por exemplo: a consulta mais
> recorrente sobre a tabela RESERVA é listar todas as reservas do campus
> 'DV' e do usuário logado no sistema pelo campo matricula_usuario. Não
> preciso de JOIN para fazer isso com o "modelo natural".
>
> Esta declaração só é verdadeira no caso de relatórios que busquem mais
> informações, mas neste caso você pode eliminar o JOIN com tabelas
> intermediárias, tornando o modelo com chaves naturais ainda mais
> eficiente.
>
>
Quando vc varre uma tabela de itens de uma nota, vc está buscando dados do
item né? E a programação de entrega desse item? Não está em outra tabela
ainda? Entende o que quero dizer?



> > 2 - Os índices ficam bem maiores
>
> Apenas "O" índice da chave primária fica maior. Você poderá ter
> índices auxiliares que terão o mesmo tamanho.
>

Mesmo exemplo acima. Nota/item/programacao_entrega - vejo o tamanho desses
índices em um caso real.



>
> > 3 - Vc tem uma redundância de informações e maior consumo de espaço
>
> Isto é fato. Na migração do banco o crescimento foi na ordem de cerca
> de 20% com os testes que fiz. Contrabalanceando, o desempenho das
> consultas ficou muito mais rápido.
>

Não sei o tamanho das bases que trabalha, mas pra mim é um problema em
vários clientes atualmente (bases na case de alguns teras)



>
> > 4 - A escrita (lembrando de modelos grandes) fica bem maior, supondo que
> > você precise unir 30 tabelas cada uma com 10 campos na sua chave, pense
> no
> > tamanha da instrução.
> >
>
> A escrita ou a união em um SQL?  Acredito que exista, sim, uma carga
> adicional na escrita, mas isso é irrelevante em relação aos benefícios
> obtidos, principalmente no desempenho das consultas.
>

Olha, hoje em dia eu vejo cada vez menos desenvolvedores com conhecimentos
de SQL, quando eu mostro uma consulta com vários join's vários arrepiam os
cabelos, mas sim é irrelevante quando se sabe o que está fazendo.


>
> Sobre "unir 30 tabelas cada uma com 10 campos na sua chave": Para isto
> existe o NATURAL JOIN. E repito, com o modelo feito com propagação de
> chaves naturais, pela minha experiência a necessidade de usar tabelas
> intermediárias diminui muito. Dificilmente uma consulta mais complexa
> do sistema hoje faz JOIN com mais de 2 tabelas, sendo que antes eram
> necessárias pelo menos 3 tabelas em JOIN em *todas* as consultas SQL.
>

Não estou sendo contra as chaves naturais, mas acho que vc pode obter o
melhor sabendo usar os 2 cenários


>
>
>
> TIAGO J. ADAMI
> ___
> 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] RES: Chave Primaria Composta

2016-08-25 Por tôpico Tiago José Adami 
Em 25 de agosto de 2016 15:10, Fabiano Machado Dias
 escreveu:

> Quando vc varre uma tabela de itens de uma nota, vc está buscando dados do
> item né? E a programação de entrega desse item? Não está em outra tabela
> ainda? Entende o que quero dizer?

Sim, entendo. Quando você envolve outras entidades certamente é
inevitável consultar outras tabelas. Neste caso provavelmente não
haveria ganho ou perda entre as duas abordagens (chaves compostas
naturais ou artificiais únicas).

>> Apenas "O" índice da chave primária fica maior. Você poderá ter
>> índices auxiliares que terão o mesmo tamanho.
>
> Mesmo exemplo acima. Nota/item/programacao_entrega - vejo o tamanho desses
> índices em um caso real.

Depende de cada caso. Ainda assim, um índice "grande" por tabela não
representa muito espaço adicional.

>> > 3 - Vc tem uma redundância de informações e maior consumo de espaço
>>
>> Isto é fato. Na migração do banco o crescimento foi na ordem de cerca
>> de 20% com os testes que fiz. Contrabalanceando, o desempenho das
>> consultas ficou muito mais rápido.
>
> Não sei o tamanho das bases que trabalha, mas pra mim é um problema em
> vários clientes atualmente (bases na case de alguns teras)

Este caso da UTFPR é um sistema pequeno, o banco de dados não chega a
2 GB hoje. Atendo clientes com bases da ordem de 1 TB ou mais, e lhe
garanto que quanto maior o tamanho, maior o tombo. As inconsistências
geradas pelo uso de chaves artificiais, muito semelhantes aos que
citei no caso do meu sistema, são constantes.

E tem mais: se desde o início o sistema for concebido da forma
correta, qual o problema para o cliente em se planejar?

>> > 4 - A escrita (lembrando de modelos grandes) fica bem maior, supondo que
>> > você precise unir 30 tabelas cada uma com 10 campos na sua chave, pense
>> > no
>> > tamanha da instrução.
>> >
>>
>> A escrita ou a união em um SQL?  Acredito que exista, sim, uma carga
>> adicional na escrita, mas isso é irrelevante em relação aos benefícios
>> obtidos, principalmente no desempenho das consultas.
>
>
> Olha, hoje em dia eu vejo cada vez menos desenvolvedores com conhecimentos
> de SQL, quando eu mostro uma consulta com vários join's vários arrepiam os
> cabelos, mas sim é irrelevante quando se sabe o que está fazendo.

Isso é verdade. Cada vez mais estão ficando preguiçosos e muito
"NoSQL". A resposta que sempre dou quando participo de um projeto
assim: ou o desenvolvedor/programador aprende SQL básico, ou está fora
do projeto. De qualquer forma pode haver alguém para criar as
consultas, a minha empresa mesmo trabalha em projetos prestando
consultoria e apoio aos desenvolvedores neste sentido.
Você tem que escolher entre um sistema bem feito para agradar os
clientes ou agradar os programadores. Eu prefiro a primeira opção :)


>> Sobre "unir 30 tabelas cada uma com 10 campos na sua chave": Para isto
>> existe o NATURAL JOIN. E repito, com o modelo feito com propagação de
>> chaves naturais, pela minha experiência a necessidade de usar tabelas
>> intermediárias diminui muito. Dificilmente uma consulta mais complexa
>> do sistema hoje faz JOIN com mais de 2 tabelas, sendo que antes eram
>> necessárias pelo menos 3 tabelas em JOIN em *todas* as consultas SQL.
>
>
> Não estou sendo contra as chaves naturais, mas acho que vc pode obter o
> melhor sabendo usar os 2 cenários

Sim, entendi. Concordo que muitas vezes há tantas "buchas" já pela
metade que não temos como mudar tudo. Mas a ideia central é começar já
fazendo certo, com chaves compostas naturais.


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] RES: Chave Primaria Composta

2016-08-25 Por tôpico Fabiano Machado Dias 
> intermediárias diminui muito. Dificilmente uma consulta mais complexa
> do sistema hoje faz JOIN com mais de 2 tabelas, sendo que antes eram
> necessárias pelo menos 3 tabelas em JOIN em *todas* as consultas SQL.
>
>
>

Uma pena eu não poder expor algumas consultas que usamos aqui, não sei se
já trabalhaste com SPED / Bloco K e outras obrigações fiscais, praticamente
vem informação desde a produção até o lançamento contábil do documento, os
SQL's são gigantescos e deixam qualquer DBA de cabelo em pé.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] RES: Chave Primaria Composta

2016-08-25 Por tôpico Tiago José Adami 
Em 25 de agosto de 2016 14:42, Guimarães Faria Corcete DUTRA, Leandro
 escreveu:
> E imagino que tanto desempenho quanto carga de máquina e de rede,
> usabilidade e manutenção melhorem muito.

Compreendi teu ponto de vista com a mensagem anterior. Aproveitei para
lhe dar o crédito da minha implementação - considerando tuas
incessantes reafirmações na lista para que usemos chaves naturais. Não
é preciso dizer isso, mas, "Dutra, você sempre esteve certo" :)

Quanto ao desempenho: as consultas SQL ficaram mais simples e mais
rápidas. E manutenção, no modelo novo, ainda não surgiu, mas todo o
projeto ficou mais "legível" e compreensível.

Se alguém tiver interesse em visualizar o projeto antigo (ogro com
chaves artificais) ele está sob domínio público no GitHUB [1]. Ainda
não subi o novo porque estou finalizando localmente e há uma
reformulação de repositórios e projetos da UTFPR em curso.

[1] https://github.com/utfpr-dv/derdi-dv

P.S: antes que me critiquem pela segurança, as senhas e geradores de
senha que estão ali não são mais usados :)


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] RES: Chave Primaria Composta

2016-08-25 Por tôpico Tiago José Adami 
Em 25 de agosto de 2016 14:46, Fabiano Machado Dias
 escreveu:
> Sim, eu entendo a "vantagem" de evitar join e você "ter" o dado já na filha
> ou "neta" da tabela.
>
> Mas assim, no que eu vi, na prática é o seguinte:
>
> 1 - A informação da chave, geralmente não é a que vc quer, então o join vai
> acontecer igual

Discordo. Se suas chaves naturais estão bem definidas, na grande
maioria das vezes é suficiente. Por exemplo: a consulta mais
recorrente sobre a tabela RESERVA é listar todas as reservas do campus
'DV' e do usuário logado no sistema pelo campo matricula_usuario. Não
preciso de JOIN para fazer isso com o "modelo natural".

Esta declaração só é verdadeira no caso de relatórios que busquem mais
informações, mas neste caso você pode eliminar o JOIN com tabelas
intermediárias, tornando o modelo com chaves naturais ainda mais
eficiente.

> 2 - Os índices ficam bem maiores

Apenas "O" índice da chave primária fica maior. Você poderá ter
índices auxiliares que terão o mesmo tamanho.

> 3 - Vc tem uma redundância de informações e maior consumo de espaço

Isto é fato. Na migração do banco o crescimento foi na ordem de cerca
de 20% com os testes que fiz. Contrabalanceando, o desempenho das
consultas ficou muito mais rápido.

> 4 - A escrita (lembrando de modelos grandes) fica bem maior, supondo que
> você precise unir 30 tabelas cada uma com 10 campos na sua chave, pense no
> tamanha da instrução.
>

A escrita ou a união em um SQL?  Acredito que exista, sim, uma carga
adicional na escrita, mas isso é irrelevante em relação aos benefícios
obtidos, principalmente no desempenho das consultas.

Sobre "unir 30 tabelas cada uma com 10 campos na sua chave": Para isto
existe o NATURAL JOIN. E repito, com o modelo feito com propagação de
chaves naturais, pela minha experiência a necessidade de usar tabelas
intermediárias diminui muito. Dificilmente uma consulta mais complexa
do sistema hoje faz JOIN com mais de 2 tabelas, sendo que antes eram
necessárias pelo menos 3 tabelas em JOIN em *todas* as consultas SQL.



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] RES: Chave Primaria Composta

2016-08-25 Por tôpico Fabiano Machado Dias 
Isso aí, chave primária é só uma chave, não precisa ser a "sua" principal
chave no modelo. No caso dos ORM's que gostam de usar os famigerados
"ID's", deixe que eles usem isso, vc usa as suas chaves e doutrina os seus
desenvolvedores.

Em 25 de agosto de 2016 14:54, Guimarães Faria Corcete DUTRA, Leandro <
l...@dutras.org> escreveu:

> 2016-08-25 14:41 GMT-03:00 Tiago José Adami :
> >
> > Mas o uso de UK's (você se refere a UNIQUE INDEXES, certo?)
>
> Na verdade, chaves alternativas.  Uma relação tem n chaves, onde n >=
> 1.  Assim, além da chave primária pode haver o outras chaves, onde o
> >= 0.  É irrelevante qual das chaves se escolhe como primária, esse
> conceito de chave primária está obsoleto e é vazio.
>
>
>
> > não
> > garante a integridade lógica entre as tabelas, apenas entre os
> > registros de uma só tabela.
>
> Não exatamente, a função das chaves alternativas, além de documentar o
> modelo, tornando-o mais transparente (de fácil compreensão), é
> justamente possibilitar a convivência de chaves naturais e artificial;
> nos raros casos em que há exagero de consumo de memória por uso de
> chaves naturais complexas se reproduzindo em tabelas filhas muito
> maiores que as pais, pode-se ‘exportar’ a chave artificial, garantindo
> a integridade referencial, enquanto as naturais seguem garantido a
> unicidade.  Mas há que se lembrar que cada chave artificial é um
> atributo e um índice a mais, custando não apenas memória mas também
> E/S.
>
> Creio que não é esse caso que exemplificaste abaixo, é?
>
>
> > Por exemplo, eu poderia ter a tabela de
> > reservas como antes:
> >
> > CREATE TABLE reserva (
> > /* PK artificial, única */
> > id_reserva SERIAL NOT NULL,
> >
> > /* FK tabela ITEM_RESERVA */
> > id_item_reserva INTEGER NOT NULL,
> >
> > /* FK tabela PESSOA */
> > id_pessoa INTEGER NOT NULL,
> >
> > (...)
> > )
> >
> > Uma das regras do sistema é que apenas servidores do próprio campus
> > possam fazer reservas dos itens do seu campus.
> >
> > Nesse modelo com chaves artificiais acima, mesmo que haja um índice
> > único não impede de fazer uma reserva de um item do campus A para uma
> > pessoa do campus B. Só se você implementar um TRIGGER que valide isso
> > e retorne uma exceção, mas aí já começa a complicar demais o modelo.
>
>
> --
> 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] RES: Chave Primaria Composta

2016-08-25 Por tôpico Guimarães Faria Corcete DUTRA , Leandro 
2016-08-25 14:46 GMT-03:00 Fabiano Machado Dias :
> Sim, eu entendo a "vantagem" de evitar join e você "ter" o dado já na filha
> ou "neta" da tabela.
>
> Mas assim, no que eu vi, na prática é o seguinte:
>
> 1 - A informação da chave, geralmente não é a que vc quer, então o join vai
> acontecer igual

‘Geralmente‘ é muito impreciso.  Pode significar que você economiza,
por exemplo, apenas 1% das junções ou 49% delas.  Mesmo 1% pode ser
significativo nalgumas circunstâncias, mas a verdade geralmente é bem
maior.


> 2 - Os índices ficam bem maiores

Sim, mas há menos índices.  Isso geralmente é muito importante, mais
do que haver índices menores.


> 3 - Vc tem uma redundância de informações e maior consumo de espaço

Isso geralmente não é importante, a menos que você tenha alguma
situação muito particular.


> 4 - A escrita (lembrando de modelos grandes) fica bem maior, supondo que
> você precise unir 30 tabelas cada uma com 10 campos na sua chave, pense no
> tamanha da instrução.

O tamanho da instrução é irrelevante.  Escrita, novamente, economiza a
quantidade de índices.


> O sistema em questão que eu citei anteriormente tem todos esses problemas e
> hoje é um verdadeiro elefante branco.

Sem mais informações é difícil afirmar qualquer coisa, mas eu
suspeitaria de outros problemas que não esse.  Eu chutaria falta de
normalização e de restrições declarativas de integridade (consistência
feita via código aplicativo procedural).


-- 
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] RES: Chave Primaria Composta

2016-08-25 Por tôpico Guimarães Faria Corcete DUTRA , Leandro 
2016-08-25 14:41 GMT-03:00 Tiago José Adami :
>
> Mas o uso de UK's (você se refere a UNIQUE INDEXES, certo?)

Na verdade, chaves alternativas.  Uma relação tem n chaves, onde n >=
1.  Assim, além da chave primária pode haver o outras chaves, onde o
>= 0.  É irrelevante qual das chaves se escolhe como primária, esse
conceito de chave primária está obsoleto e é vazio.



> não
> garante a integridade lógica entre as tabelas, apenas entre os
> registros de uma só tabela.

Não exatamente, a função das chaves alternativas, além de documentar o
modelo, tornando-o mais transparente (de fácil compreensão), é
justamente possibilitar a convivência de chaves naturais e artificial;
nos raros casos em que há exagero de consumo de memória por uso de
chaves naturais complexas se reproduzindo em tabelas filhas muito
maiores que as pais, pode-se ‘exportar’ a chave artificial, garantindo
a integridade referencial, enquanto as naturais seguem garantido a
unicidade.  Mas há que se lembrar que cada chave artificial é um
atributo e um índice a mais, custando não apenas memória mas também
E/S.

Creio que não é esse caso que exemplificaste abaixo, é?


> Por exemplo, eu poderia ter a tabela de
> reservas como antes:
>
> CREATE TABLE reserva (
> /* PK artificial, única */
> id_reserva SERIAL NOT NULL,
>
> /* FK tabela ITEM_RESERVA */
> id_item_reserva INTEGER NOT NULL,
>
> /* FK tabela PESSOA */
> id_pessoa INTEGER NOT NULL,
>
> (...)
> )
>
> Uma das regras do sistema é que apenas servidores do próprio campus
> possam fazer reservas dos itens do seu campus.
>
> Nesse modelo com chaves artificiais acima, mesmo que haja um índice
> único não impede de fazer uma reserva de um item do campus A para uma
> pessoa do campus B. Só se você implementar um TRIGGER que valide isso
> e retorne uma exceção, mas aí já começa a complicar demais o modelo.


-- 
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] RES: Chave Primaria Composta

2016-08-25 Por tôpico Fabiano Machado Dias 
Sim, eu entendo a "vantagem" de evitar join e você "ter" o dado já na filha
ou "neta" da tabela.

Mas assim, no que eu vi, na prática é o seguinte:

1 - A informação da chave, geralmente não é a que vc quer, então o join vai
acontecer igual
2 - Os índices ficam bem maiores
3 - Vc tem uma redundância de informações e maior consumo de espaço
4 - A escrita (lembrando de modelos grandes) fica bem maior, supondo que
você precise unir 30 tabelas cada uma com 10 campos na sua chave, pense no
tamanha da instrução.

O sistema em questão que eu citei anteriormente tem todos esses problemas e
hoje é um verdadeiro elefante branco.



Em 25 de agosto de 2016 14:41, Tiago José Adami 
escreveu:

> Em 25 de agosto de 2016 14:29, Fabiano Machado Dias
>  escreveu:
> > Legal, você poderia usar UK's e ainda assim manter a suas chaves
> > artificiais, muitas vezes a preocupação com a chave primária faz com que
> as
> > pessoas esqueçam que podemos ter N UK's para manter a integridade nos
> > trilhos e no banco!
> >
> > Hoje tenho diversos projetos onde o uso de ORM é constante, para conviver
> > com ele faço isso, o fato é que tabela sem chave natural é o inferno de
> > qualquer modelo.
>
> Mas o uso de UK's (você se refere a UNIQUE INDEXES, certo?) não
> garante a integridade lógica entre as tabelas, apenas entre os
> registros de uma só tabela. Por exemplo, eu poderia ter a tabela de
> reservas como antes:
>
> CREATE TABLE reserva (
> /* PK artificial, única */
> id_reserva SERIAL NOT NULL,
>
> /* FK tabela ITEM_RESERVA */
> id_item_reserva INTEGER NOT NULL,
>
> /* FK tabela PESSOA */
> id_pessoa INTEGER NOT NULL,
>
> (...)
> )
>
> Uma das regras do sistema é que apenas servidores do próprio campus
> possam fazer reservas dos itens do seu campus.
>
> Nesse modelo com chaves artificiais acima, mesmo que haja um índice
> único não impede de fazer uma reserva de um item do campus A para uma
> pessoa do campus B. Só se você implementar um TRIGGER que valide isso
> e retorne uma exceção, mas aí já começa a complicar demais o modelo.
>
> Outra vantagem das chaves naturais é saber pela tabela "filha" quem
> são os "pais". Neste exemplo com chaves artificiais, eu precisava
> fazer JOIN com mais 3 tabelas para saber qual o campus.
>
> TIAGO J. ADAMI
> ___
> 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] RES: Chave Primaria Composta

2016-08-25 Por tôpico Guimarães Faria Corcete DUTRA , Leandro 
Muito obrigado por tua mensagem, Adami!  Gostei muito do exemplo e de
como o explanaste.

Só algumas pequenas observações, que nada deslustram:


2016-08-25 14:17 GMT-03:00 Tiago José Adami :
>
> E eu avalizo totalmente esta declaração. E ainda quero citar um
> exemplo do porquê chaves naturais compostas DEVEM ser utilizadas
> sempre que possível.

Eu diria que *sempre* _têm_ de ser utilizadas.  Se não for possível, é
erro de modelagem, provavelmente de compreensão ou do modelo
relacional.  Especificamente, se for necessário pode-se definir uma
chave artificial *além* das naturais.


> Como exemplo à declaração do Dutra, a tabela RESERVA_ITEM_AUTORIZACAO
> possui 7 campos em sua chave primária, todos naturais que são todos os
> campos da tabela. Ou seja, é uma tabela onde todos os campos são parte
> da chave primária, sendo uma tabela "clássica" de relacionamento N*N.

Sim, no n:n por definição todos os atributos participam da chave, que
no caso é sempre composta e única (não há chaves alternativas).

Mas referi-me a uma situação um pouco diferente: há casos em que há
dificuldades de se obter uma chave natural que realmente garanta
unicidade. Por exemplo, o RG, para as SSPs, é uma chave artificial; a
natural é nome completo, filiação, data e local de nascimento… e há
casos de duplicação dos atributos que acabo de listar, por incrível
que pareça: por exemplo, dois homens, se não me engano nascidos no
interior da BA, que tinham o mesmo nome, que nasceram no mesmo dia e
cidade, e cujos mãe e pais também tinham nomes idênticos.

Num caso desses, a saída é incorporar mais informações ao modelo.  Não
sei o que a SSP/BA fez nesse caso, nem o que as SSPs em geral fazem,
mas o óbvio seria incorporar alguma informação adicional: como
exemplos meio idiotas, só mesmo a título de exemplo, identificação da
certidão de nascimento, ou hora de nascimento, ou nomes dos avós…

Outro exemplo é uma tabela armazenando um registro de atividades
(trilha de auditoria).  Pode ser necessário colocar todos os atributos
do /log/ como chave, e no limite até incorporar um contador para o
caso em que no mesmo momento a mesmíssima mensagem apareceu várias
vezes.  Mas, geralmente, um TIMESTAMP resolve um caso desses.


> Finalizando minha "história", com exceção de um índice único e 2
> TRIGGERs para tratar horários conflitantes, toda a integridade lógica
> ficou GARANTIDA apenas pelo uso das FK's e PK's com atributos
> naturais, mesmo que com vários campos. E o número de FK's foi reduzido
> para 1 terço do que havia antes, pois a propagação das chaves
> compostas garante a integridade com a tabela "pai" de todos os níveis
> superiores.

E imagino que tanto desempenho quanto carga de máquina e de rede,
usabilidade e manutenção melhorem muito.


-- 
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] RES: Chave Primaria Composta

2016-08-25 Por tôpico Tiago José Adami 
Em 25 de agosto de 2016 14:29, Fabiano Machado Dias
 escreveu:
> Legal, você poderia usar UK's e ainda assim manter a suas chaves
> artificiais, muitas vezes a preocupação com a chave primária faz com que as
> pessoas esqueçam que podemos ter N UK's para manter a integridade nos
> trilhos e no banco!
>
> Hoje tenho diversos projetos onde o uso de ORM é constante, para conviver
> com ele faço isso, o fato é que tabela sem chave natural é o inferno de
> qualquer modelo.

Mas o uso de UK's (você se refere a UNIQUE INDEXES, certo?) não
garante a integridade lógica entre as tabelas, apenas entre os
registros de uma só tabela. Por exemplo, eu poderia ter a tabela de
reservas como antes:

CREATE TABLE reserva (
/* PK artificial, única */
id_reserva SERIAL NOT NULL,

/* FK tabela ITEM_RESERVA */
id_item_reserva INTEGER NOT NULL,

/* FK tabela PESSOA */
id_pessoa INTEGER NOT NULL,

(...)
)

Uma das regras do sistema é que apenas servidores do próprio campus
possam fazer reservas dos itens do seu campus.

Nesse modelo com chaves artificiais acima, mesmo que haja um índice
único não impede de fazer uma reserva de um item do campus A para uma
pessoa do campus B. Só se você implementar um TRIGGER que valide isso
e retorne uma exceção, mas aí já começa a complicar demais o modelo.

Outra vantagem das chaves naturais é saber pela tabela "filha" quem
são os "pais". Neste exemplo com chaves artificiais, eu precisava
fazer JOIN com mais 3 tabelas para saber qual o campus.

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] RES: Chave Primaria Composta

2016-08-25 Por tôpico Fabiano Machado Dias 
Legal, você poderia usar UK's e ainda assim manter a suas chaves
artificiais, muitas vezes a preocupação com a chave primária faz com que as
pessoas esqueçam que podemos ter N UK's para manter a integridade nos
trilhos e no banco!

Hoje tenho diversos projetos onde o uso de ORM é constante, para conviver
com ele faço isso, o fato é que tabela sem chave natural é o inferno de
qualquer modelo.



Em 25 de agosto de 2016 14:22, Tiago José Adami 
escreveu:

> Em 25 de agosto de 2016 14:17, Tiago José Adami 
> escreveu:
> > CREATE TABLE reserva_item_autorizacao (
>
> Corrigindo os comentários
>
> Tabela RESERVA_ITEM só possui 2 FKs:
> - codigo_patrimonio é FK da tabela ITEM_RESERVA;
> - demais campos são FK da tabela RESERVA
>
> Tabela RESERVA_ITEM_AUTORIZACAO só possui 2 FKs:
> - matricula_autorizacao é FK da tabela PESSOA;
> - demais campos são FK da tabela RESERVA_ITEM
>
> TIAGO J. ADAMI
> ___
> 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] RES: Chave Primaria Composta

2016-08-25 Por tôpico Tiago José Adami 
Em 25 de agosto de 2016 14:17, Tiago José Adami  escreveu:
> CREATE TABLE reserva_item_autorizacao (

Corrigindo os comentários

Tabela RESERVA_ITEM só possui 2 FKs:
- codigo_patrimonio é FK da tabela ITEM_RESERVA;
- demais campos são FK da tabela RESERVA

Tabela RESERVA_ITEM_AUTORIZACAO só possui 2 FKs:
- matricula_autorizacao é FK da tabela PESSOA;
- demais campos são FK da tabela RESERVA_ITEM

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] RES: Chave Primaria Composta

2016-08-25 Por tôpico Tiago José Adami 
Em 25 de agosto de 2016 13:44, Guimarães Faria Corcete DUTRA, Leandro
 escreveu:
> Mas de fato há situações em que uma chave pode chegar a cobrir todos
> os atributos (naturais) de uma relação (não confundir com
> relacionamento).

E eu avalizo totalmente esta declaração. E ainda quero citar um
exemplo do porquê chaves naturais compostas DEVEM ser utilizadas
sempre que possível.

Vou citar um exemplo de um software de reservas desenvolvido para a
UTFPR campus DV e que está em uso agora em 2 campus. Inicialmente toda
a camada de acesso a dados utilizava Hibernate (JSF + Hibernate +C3P0)
com PostgreSQL 9.4 usando os famigerados "IDs" e chaves artificiais
autoincremento para tudo, para facilitar a integração com Hibernate.

Enquanto o software esteve rodando para 1 campus apenas (Dois
Vizinhos), não houveram muitos problemas.

Para encurtar o papo, quando começou a importação de dados de um tal
aSc TimeTables que define reservas de salas e horários por disciplinas
e turmas, começou a dor de cabeça. Os usuários importavam 2x o mesmo
XML e os "ID's" por não serem chaves naturais permitiam a duplicação
dos dados.

Pior ficou quando fiz testes para inclusão de um outro campus...

Um item que estava cadastrado para o campus DV (uma sala de aula, por
exemplo) poderia ser reservado em outro campus (erro de lógica). As
FK's e PK's não garantiam integridade lógica, apenas integridade
referencial (filho sem pai). A ideia central do sistema que era ficar
hospedado em um servidor apenas caiu por terra, foi necessário então
solicitar ao outro campus que hospedasse uma nova instância do
aplicativo.

Comecei a trabalhar no projeto com afinco. Refiz todo o modelo usando
chaves naturais e abandonei o Hibernate pelo sql2o. Deu um pouco mais
de trabalho no começo, mas depois tudo fluiu com uma naturalidade
fantástica. Ainda estou testando a nova versão e logo farei a migração
dos dados.

Como exemplo à declaração do Dutra, a tabela RESERVA_ITEM_AUTORIZACAO
possui 7 campos em sua chave primária, todos naturais que são todos os
campos da tabela. Ou seja, é uma tabela onde todos os campos são parte
da chave primária, sendo uma tabela "clássica" de relacionamento N*N.

Finalizando minha "história", com exceção de um índice único e 2
TRIGGERs para tratar horários conflitantes, toda a integridade lógica
ficou GARANTIDA apenas pelo uso das FK's e PK's com atributos
naturais, mesmo que com vários campos. E o número de FK's foi reduzido
para 1 terço do que havia antes, pois a propagação das chaves
compostas garante a integridade com a tabela "pai" de todos os níveis
superiores.

Abaixo segue o modelo atual no qual estou trabalhando (omiti demais
campos que não são chave):

CREATE TABLE pessoa(
/* PK - chave natural - código de cada servidor público */
matriculaVARCHAR(20) NOT NULL,
(...)
);

CREATE TABLE instituicao (
/* PK - chave natural - código do MEC */
sigla VARCHAR(20) NOT NULL,
(...)
);


CREATE TABLE campus (
/* PK e FK tabela INSTITUICAO */
sigla_instituicao VARCHAR(20) NOT NULL,

/* PK - chave natural - código do MEC */
sigla_campus VARCHAR(20) NOT NULL,
(...)
);

/* "Cadastro" de itens */
CREATE TABLE item_reserva (
/* PK e FK tabela CAMPUS */
sigla_instituicao VARCHAR(20) NOT NULL,

/* PK e FK tabela CAMPUS */
sigla_campus VARCHAR(20) NOT NULL,

/* PK - chave natural - código de patrimonio interno do campus */
codigo_patrimonio VARCHAR(20) NOT NULL,
(...)
);

CREATE TABLE reserva (
/* PK e FK tabela ITEM_RESERVA */
sigla_instituicao VARCHAR(20) NOT NULL,
/* PK e FK tabela ITEM_RESERVA */
sigla_campus VARCHAR(20) NOT NULL,
/* PK - chave natural */
data_reserva_inicioTIMESTAMP NOT NULL,
/* PK - chave natural */
data_reserva_fimTIMESTAMP NOT NULL,
/* PK e FK tabela PESSOA */
matricula_usuarioVARCHAR(20) NOT NULL,
(...)
);


/* Cada reserva pode incluir mais de um item, portanto aqui fica
   separado da tabela reserva

   Há aqui um indice único entre os campos
sigla_instituicao,
sigla_campus,
data_reserva_inicio,
codigo_patrimonio

   Também há 2 triggers um pouco mais complexos que não permitem
   horários conflitantes, algo impossível de tratar apenas com FKs.

   Motivo: um mesmo item não pode ser reservado 2x na mesma
   data e hora, ou enquanto uma reserva ainda está ativa */
CREATE TABLE reserva_item (
/* PK e FK tabela ITEM_RESERVA */
sigla_instituicao VARCHAR(20) NOT NULL,
/* PK e FK tabela ITEM_RESERVA */
sigla_campus VARCHAR(20) NOT NULL,
/* PK - chave natural */
data_reserva_inicioTIMESTAMP NOT NULL,
/* PK - chave natural */
data_reserva_fimTIMESTAMP NOT NULL,
/* PK e FK tabela PESSOA */
matricula_usuarioVARCHAR(20) NOT NULL,
/* PK e FK tabela ITEM_RESERVA */
codigo_patrimonio VARCHAR(20) NOT NULL,
(...)
);

/* Alguns itens possuem u

Re: [pgbr-geral] RES: Chave Primaria Composta

2016-08-25 Por tôpico Guimarães Faria Corcete DUTRA , Leandro 
2016-08-25 13:30 GMT-03:00 Márcio A. Sepp :
>
> Depende, lá como eu disse as chaves compostas foram usadas de forma errada

[…]

Márcio, quando for citar algo que alguém mais escreveu, marque para
evitar confusão.



> Vou dar uma pitada aqui, embora não sou bem um conhecedor da área. A meu ver, 
> justamente vc colocando mais atributos na chave primária deveria deixar as 
> consultas mais rápidas (se vc utilizar os campos da chave no where) e, como 
> consequencia, talvez iria utilizar mais o disco para
> armazenamento (falando a grosso modo).

Não.

Os atributos de uma chave por definição já existem no disco.  A rigor,
é a chave artificial, apesar de poder ser simples, que representa
desperdício, visto que tem de ser definida (incluindo índice) além das
chaves naturais (nunca as substituindo!), sejam estas compostas ou
simples.

A eventual economia de armazenamento seria para o caso de tabelas
‘pai’, que ‘exportariam’ apenas um atributo para as ‘filhas’.  Mas
essa economia geralmente é mais que contrabalançada por haver índice e
atributo adicional nas tabelas pais, e pelo fato de que chaves
artificiais quase sempre exigem mais junções, visto que as chaves
estrangeiras nas tabelas filhas não contém informações úteis; e pelo
fato de que geralmente as pessoas acabam não definindo chaves naturais
quando definem as artificiais, o que gera, além de inconsistências,
necessidade de tratar integridade na aplicação, o que é muito
ineficiente.


> Este assunto eu já havia levantado aqui na lista um tempo atrás e eu tbm 
> tenho dúvidas em relação a quantidade de campos na chave. Justamente nesta 
> parte mais baixa da contabilidade eu cheguei a 9 campos na chave da tabela de 
> movimentação por projeto. Tbm achei estranho isso, pois nunca havia visto uma 
> chave primária tão grande...
>
> No meu caso a chave está assim:
>   character varying(10)
>   bigint
>   smallint
>   smallint
>   smallint
>   integer
>   character(1)
>   integer
>   integer
>
> Não coloquei os nomes dos campos pq eles seguem um propósito próprio e teria 
> de colocar uma legenda pra eles e não é o propósito.

Não entendi, comentar o quê?  Sem os significados, e o resto da
estrutura e explicações, é impossível dizer qualquer coisa.  Modelagem
de dados é o tipo de coisa muito difícil de fazer remotamente
justamente pela quantidade de informações necessárias.

Em termos gerais, amiúde uma chave composta grande pode indicar falta
de normalização, e portanto ou desatenção de quem modelou, ou
desconhecimento — geralmente as pessoas entendem mal as formas
normais, e até desconhecem qualquer coisa além da 3NF.  Só para
lembrar, há sete formas normais (as 5NFs originais, a Boyce-Codd e a
temporal, esta de difícil aplicação), mas geralmente o bom senso e uma
análise atenta dá bons resultados mesmo conhecendo apenas as três
primeiras formas normais.

Mas de fato há situações em que uma chave pode chegar a cobrir todos
os atributos (naturais) de uma relação (não confundir com
relacionamento).


-- 
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] RES: Chave Primaria Composta

2016-08-25 Por tôpico Márcio A . Sepp 

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.



Boa tarde,

Vou dar uma pitada aqui, embora não sou bem um conhecedor da área. A meu ver, 
justamente vc colocando mais atributos na chave primária deveria deixar as 
consultas mais rápidas (se vc utilizar os campos da chave no where) e, como 
consequencia, talvez iria utilizar mais o disco para 
armazenamento (falando a grosso modo).

Este assunto eu já havia levantado aqui na lista um tempo atrás e eu tbm tenho 
dúvidas em relação a quantidade de campos na chave. Justamente nesta parte mais 
baixa da contabilidade eu cheguei a 9 campos na chave da tabela de movimentação 
por projeto. Tbm achei estranho isso, pois nunca havia visto uma chave primária 
tão grande...  

No meu caso a chave está assim:
  character varying(10)
  bigint 
  smallint 
  smallint 
  smallint 
  integer 
  character(1)
  integer 
  integer 

Não coloquei os nomes dos campos pq eles seguem um propósito próprio e teria de 
colocar uma legenda pra eles e não é o propósito.

Por favor, comentem. 


___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral