subject:"\[pgbr\-geral\] Qual estrutura utilizar\?"

2010/1/4 Alexsander Rosa alexsander.r...@gmail.com:
 Isso me lembra aquela velha discussão sobre usar CPF/CNPJ como chave
 natural, o que é impossível porque inúmeros órgãos públicos compartilham o
 mesmo CNPJ.

Há vários motivos pelos quais CNPF ou CNPJ podem não ser chave natural
— a questão que se coloca é, justamente, de qual entidade?

Acho que eu mesmo já citei o caso de correntista de banco.  Há, por
exemplo, mulheres casadas que não têm CNPF, porque nunca tiveram vida
economicamente ativa, mas têm conta conjunta com o marido.  São
correntistas sem CNPF.

No teu caso, já poderíamos pensar numa entidade órgão público, que
certamente tem outra chave.  Talvez, várias entidades.  Se é prático
ou não separá-los numa base de dados, vai depender de muitas
variáveis, como dialeto SQL, implementação física, volume de dados,
tráfego de transações, ferramental de programação… mas, se não
analisarmos as entidades — e para isso chaves naturais são
indispensáveis, mesmo que acabem não sendo implementadas nalgum caso
extremo —, nunca entenderemos os problemas.


 Aqui no RS, por exemplo, simplesmente TODAS as escolas estaduais
 usam o CNPJ da Secretaria da Educação, não apenas a raiz, o CNPJ inteiro.
 Para o pagamento de empenhos os nomes das escolas precisam estar corretos
 até a última vírgula, não dá pra emitir a NF em nome da Secretaria e depois
 mandar entregar na escola.

No mínimo, há uma entidade escola estadual cuja chave não é o CNPJ.
Talvez o nome da escola, por exemplo (sei, sei, nome dificilmente é
boa chave, só para provocar a pensar), ou até o nome e o endereço.


 É muito mais simples usar um SERIAL para código
 de cliente do que tentar achar uma chave natural viável.

Sim, mas incorreto.

Sendo mais preciso, pode ser necessária uma chave artificial; mas não
tentar uma chave natural, mesmo que não seja declarada como a
primária, seria convidar problemas pela porta da frente.


 Sou totalmente a favor de chaves naturais, uso sempre que possível, mas há
 casos em que simplesmente não dá.

Não dá o quê?

Não dá para usar como chave primária, não estou preocupado.

Não dá para declarar, estou para ver um caso.


-- 
skype:leandro.gfc.dutra?chat  Yahoo!: ymsgr:sendIM?lgcdutra
+55 (11) 3854 7191  gTalk: xmpp:leand...@jabber.org
+55 (11) 9406 7191ICQ/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] Qual estrutura utilizar?

2010/1/4 Mozart Hasse mozart.ha...@usa.net:

 Bancos de dados que usam SQL assumem que a chave exportada é a chave
 primária a não ser que se explicite o contrário

Uai, e quem está preocupado com isso?

Na maioria dos casos, não faz diferença a chave primária ser natural,
seja porque não será exportada, seja porque os volumes são
irrelevantes para aquela implementação física.  Nesses casos, não há o
menor problema em exportar a chave primária.

Para a minoria (geralmente) dos casos em que é necessária, em SQL, uma
chave artificial (e explicitada ao usuário), ela pode tranqüilamente
ser a primária, não faz a menor diferença que a natural seja declarada
sem ser primária.


 Expus casos em que uma chave artifical exportada tem
 vantagens sobre as chaves compostas naturais correspondentes.

Perfeito, há casos, mas são minoritários e não excluem as chaves
naturais, compostas ou não.


 Você defendeu e reafirma que geralmente chave artificial é desnecessária. 
 Não me culpe
 por não adivinhar que está se referindo à exceção usando termos como
 geralmente.

Pelo contrário, a exceção é precisar de chave artificial.  Talvez
prestemos muita atenção nas exceções em termos de quantidade de
tabelas, porque as exceções acabam representando o maior volume de
dados.

Aliás, não o culpo de nada… só me surpreendo de como não consigo me
fazer entender.


 Nunca falei em *sempre* usar chaves artificiais. Novamente se o seu problema
 é inclusão desnecessária de campos numa tabela, critique o mau hábito,
 não o uso de chaves artificiais, que não tem nada a ver com isso.

Como não tem, se uma chave artificial é um atributo a mais?  E se é
freqüentemente abusado?


 1. Tamanho dos índices que incluem os campos da chave primária. Tamanho
 menor implica em uso mais frequente;

Sim, onde há volume que faça diferença.


 2. Tamanho do comando SQL em consultas com várias junções, facilitando a
 vida do compilador e do otimizador;

Irrelevante… tokenizado.


 3. Melhor estimativa de quantos registros cada condição irá retornar,
 melhorando o desempenho.

Estou para ver alguma diferença prática.  Muito me surpreenderia se
houvesse alguma nas tabelas menores, que são a maioria.


  Se quer ler e entender o modelo, use a representação conceitual (modelo
  lógico).

 Que, normalmente, não é mantido e, quando é, geralmente é apenas uma
 reversa do físico, ocultando mais do que explicando.

 Novamente: se o seu problema é má documentação, critique o mau hábito,
 não as chaves artificias, que não tem nada a ver com isso.

Na verdade, a questão aí nem é documentação em si… é o próprio SQL que
não suporta a divisão entre conceitual e físico, e o ferramental em
torno não ajuda tanto quanto deveria.


 Lendo o que está escrito, não achei o que a maioria está fazendo de
 errado

Chaves artificiais à exclusão das naturais, essencialmente.  E além
delas, em muitos casos.

Perdão por não me explicar mais clara e precisamente.


 nem seus critérios para medir quem é maioria e quem é minoria.

Só a minha experiência, e a de muitos colegas.


 Falando sério, é só ver a inconsistência dos nomes de atributos?

 Brincou com a pergunta que mais deveria ser levada a sério. :-/

Pelo contrário.


 Não podemos esquecer que os sistemas servem para resolver *problemas*, não
 para gerar diagramas conceitualmente perfeitos.

E qual problema exige os nomes inconsistentes dos atributos nas
relações do dicionário de dados do Oracle?


 Agora, não tente me convencer de que a maioria não coloca
 desempenho na lista de prioridades.

Nem tentarei.  Coloca, mas equivocadamente.  Não faz sequer um teste
para verificar se as regrinhas que aprendeu de ouvido se aplicam a seu
caso.


 Não, não concordaria.

Não estivesses tão quente com a polêmica… ;-)

Gostaria de escrever a respeito, também.  O número talvez seja
absurdo, mas o fato de que há imensos desperdícios não é.


 De novo usando como regra geral (geralmente) o oposto ao praticado por
 vários bancos de dados, que oferecem a opção de escolher o nível de 
 isolamento exatamente
 por causa do desempenho.

Não oposto, criastes um espantalho.

A opção existir não significa que se aplica tão geralmente.

Aliás, geralmente o valor por omissão é um nível de isolamento abaixo
do serializável.  O que é ótimo para prototipar um aplicativo ou para
dados isolados, mas nem tanto para sistemas maiores.  Suspeito de que
a razão seja fazer bonito em testes de desempenho e evitar afugentar
programadores, mas gostaria de saber a razão exata.


 Se ganho de desempenho pelo nível de isolamento não fosse relevante,
 não seria uma opção mantida em tanto bancos de dados diferentes, incluindo
 o Postges.

Relevante, sim, mas em que casos?

Na minha experiência, e de vários colegas, o uso de níveis de
isolamento inferior ao serializável dá um ganho geralmente
insignificante, mas gera perdas significativas ao acabar levanto
desenvolvedores a colocarem conferências de


 Claro? mas qual a proporção de tabelas que têm filhas, e que são

Re: [pgbr-geral] Qual estrutura utilizar?

2010/1/4 Andre Fernandes fernandes.an...@gmail.com:
 Isso não
 significa que a chave artificial precise estar desprovida de significado.

André, pelo contrário, uma chave artificial _por definição_ é
desprovida de significado.

Por definição, chave natural é dada pela natureza do que se quer
modelar, enquanto a artificial é criada na própria base, sem ter
relação com o mundo real.

Por exemplo, o CNPJ é uma chave artificial para o sistema que a gera;
para todo mundo fora da Receita, é natural.  E deve ser natural para
todos os sistemas da Receita além daquele que o gera.


 Uma chave primária tem de ser a forma de buscar na tabela usada
 primariamente e que identifica o registro.

Não exatamente.  Pode haver várias formas de buscar, muitas podem nem
ser chaves, nem sequer indexadas.  E uma tupla pode ser identificada
por n chaves, sem que uma seja mais correta, melhor ou mais importante
que as outras.

A necessidade duma chave entre outras ser escolhida como primária não
tem mais sentido.  Foi herdada pelo SQL de modelos pré-relacionais.


 Isso significa que criar uma
 chave artificial numa tabela de pedidos pode ter um sentido, é a
 identificação de qual o pedido do cliente e quando o mesmo ligar, será
 solicitada essa chave (número do pedido) para achar o mesmo.

Ou seja, já virou uma chave natural, ao menos para o cliente.

Veja de outra maneira: imagine que o cliente perdeu o número do
pedido.  O que se faz, perde-se o pedido?  Não, há outras informações,
que o cliente talvez nem precise decorar ou anotar, que identificarão
o pedido.  Cada conjunto de informações que sirva para isso será uma
chave.


 Antes que mencionem que podemos ter alguma alteração em chaves primárias
 naturais (mudanças de regras de negócio, por exemplo), essa não seria uma
 boa justificativa para não usá-las visto a teoria Relacional não proibir
 alterações de chaves primárias.

O argumento é prático, não conceitual.  E cai com a possibilidade de
ON UPDATE CASCADE.


-- 
skype:leandro.gfc.dutra?chat  Yahoo!: ymsgr:sendIM?lgcdutra
+55 (11) 3854 7191  gTalk: xmpp:leand...@jabber.org
+55 (11) 9406 7191ICQ/AIM: aim:GoIM?screenname=61287803
BRAZIL GMT-3  MSN: msnim:chat?contact=lean...@dutra.fastmail.fm
Sent from Sao Paulo, SP, Brésil
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Qual estrutura utilizar?

2010/1/4 Alexsander Rosa alexsander.r...@gmail.com:
 Então devo fazer uma chave composta com CNPJ+INEP e deixar NULL no campo
 codigo_inep em 99% dos registros?

Não, você terá duas entidades diferentes: empresas de um lado, escolas
do outro, no exemplo.


-- 
skype:leandro.gfc.dutra?chat  Yahoo!: ymsgr:sendIM?lgcdutra
+55 (11) 3854 7191  gTalk: xmpp:leand...@jabber.org
+55 (11) 9406 7191ICQ/AIM: aim:GoIM?screenname=61287803
BRAZIL GMT-3  MSN: msnim:chat?contact=lean...@dutra.fastmail.fm
Sent from Sao Paulo, SP, Brésil
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Qual estrutura utilizar?

2010-01-07 Por tôpico Mozart Hasse

Leandro,

 Para a minoria (geralmente) dos casos em que é necessária, em SQL, uma
 chave artificial (e explicitada ao usuário), ela pode tranqüilamente
 ser a primária, não faz a menor diferença que a natural seja declarada
 sem ser primária.

E ainda diz que sou em que crio espantalhos.
Estou falando disso aqui:

http://en.wikipedia.org/wiki/Surrogate_key

Usando a definição mais moderna da minoria que ouviu falar do Wieringa e
De Jonge (última moda, 1991)


 Como não tem, se uma chave artificial é um atributo a mais?  E se é
 freqüentemente abusado?

Já expliquei por que esse atributo a mais melhora o desempenho e a estrutura
da 
aplicação, consulte o histórico. Recomendo que poste suas lamentações
sobre os 
abusos que só você sabe e viu onde aconteceram na lista pertinente, que
até 
onde eu saiba não é esta.

 
  2. Tamanho do comando SQL em consultas com várias junções, facilitando
a
  vida do compilador e do otimizador;
 
 Irrelevante? tokenizado.

Relevante, pois influi no número de tokens e no número de árvores que o 
otimizador precisa analisar para escolher o plano de execução.


  3. Melhor estimativa de quantos registros cada condição irá retornar,
  melhorando o desempenho.
 
 Estou para ver alguma diferença prática.  Muito me surpreenderia se
 houvesse alguma nas tabelas menores, que são a maioria.

Pode ser uma senhora diferença quando juntar tabelas menores (menos de 
1 registros) com tabelas maiores e o otimizador decidir usar o índice 
ao invés de percorrer todos os registros da pequena tabela filha. No meu 
planeta a gente precisa disso com frequência.
Siga meu conselho e experimente, especialmente num projeto com volume de 
dados em que desempenho seja um dos requisitos e o hardware não seja 
ilimitado para esconder más decisões de modelagem.

 
  Novamente: se o seu problema é má documentação, critique o mau
hábito,
  não as chaves artificias, que não tem nada a ver com isso.
 
 Na verdade, a questão aí nem é documentação em si? é o próprio SQL
que
 não suporta a divisão entre conceitual e físico, e o ferramental em
 torno não ajuda tanto quanto deveria.

Novamente: se o seu problema é o ferramental que não ajuda a documentar,
critique-o na lista apropriada. Poupe as chaves artificias, que não tem nada
a ver com isso.

 
  Não podemos esquecer que os sistemas servem para resolver *problemas*,
não
  para gerar diagramas conceitualmente perfeitos.
 
 E qual problema exige os nomes inconsistentes dos atributos nas
 relações do dicionário de dados do Oracle?

Se eles te parecem inconsistentes, consulte os especialistas da área (ORACLE)
na lista pertinente ou pergunte pro Tom (asktom.oracle.com).
 

 Claro que tem!  A má modelagem se traduz no abuso das chaves artificiais.

Só falta saber identificar quando ocorre o abuso, justificar por quê te
parece um abuso e citá-lo no momento e local apropriados. 


 Pelo contrário, a exceção é precisar de chave artificial.
(...)
 Só a minha experiência, e a de muitos colegas.
(...)
 Coloca, mas equivocadamente.  Não faz sequer um teste
 para verificar se as regrinhas que aprendeu de ouvido se aplicam a seu
 caso.
(...)
 A opção existir não significa que se aplica tão geralmente.
(...)
 Relevante, sim, mas em que casos?
(...) 
 o uso de níveis de
 isolamento inferior ao serializável dá um ganho geralmente
 insignificante, mas gera perdas significativas ...
(...)
 Isso seria meio absurdo.  Como 70% das tabelas terão filhas de
 tamanhos significativos, e maiores que o de suas mães?  
(...)
 Altere, mas não estrague o resto do modelo.

(depois de muitas caras de espanto com cada trecho)
Depende da aplicação. Pelo visto nos últimos 15 anos vivemos em mundos
distintos, 
com colegas distintos e requisitos mais distintos ainda.


Mozart Hasse


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

Re: [pgbr-geral] Qual estrutura utilizar?

Desculpem duas respostas, mas não dava para deixar passar:


2010/1/4 Andre Fernandes fernandes.an...@gmail.com:
 PS: a teoria relacional não trata de chaves artificiais ou naturais, não
 especifica nenhuma delas, trata de normalizações e relações entre conjuntos.

Não, normalização não é parte do modelo relacional.  É uma
conseqüência dele.  E o modelo não trata de relações entre conjuntos:
as relações *são* os conjuntos com os quais o modelo lida.  A idéia de
relacionamento vem não do modelo relacional, mas dos diagramas
entidade-relacionamento.


 Aliás, nem trata de banco de dados, banco de dados apenas usam a mesma, mas
 não são as únicas coisas que usam essa teoria matemática.

Pelo contrário, estou aqui com o livro do Codd, _The Relational Model
for Database Management: Version 2_.  Não existe outro modelo
relacional, nem aplicação fora de bases de dados.  Aliás, a teoria não
é somente matemática: fundamenta-se na lógica dos predicados /e/ na
teoria dos conjuntos.


-- 
skype:leandro.gfc.dutra?chat  Yahoo!: ymsgr:sendIM?lgcdutra
+55 (11) 3854 7191  gTalk: xmpp:leand...@jabber.org
+55 (11) 9406 7191ICQ/AIM: aim:GoIM?screenname=61287803
BRAZIL GMT-3  MSN: msnim:chat?contact=lean...@dutra.fastmail.fm
Sent from Sao Paulo, SP, Brésil
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Qual estrutura utilizar?

2010/1/4 Eduardo Andrade Bahiense edua...@escolavianet.com.br:
 Exceto que algumas escolas públicas compartilham este código com outras por
 serem, fisicamente independentes, mas, formalmente, partes de uma outra
 escola.

Ou seja, o endereço é parte de uma chave natural.


 algumas
 informações como códigos de pessoas, alunos, escolas, clintes, entre outros,
 atribuídos de forma serial, já faziam parte das rotinas de instituições
 antes de alguém pensar em energia elétrica, e que, por regra de negócio, são
 chaves naturais e não artificiais

Perfeito.


 os sistemas devem continuar gerando
 esses números para satisfazer requisitos do próprio negócio. Então, não dá
 para ir contra a própria ordem natural das coisas. O que concordo em grau,
 gênero e número é que muitos usam chaves artificiais como uma regra
 absoluta, alegando, em análise reversa, que o fazem por questão de
 performance, quando deveriam elaborar melhor o modelo e se valer das chaves
 naturais, sempre que, pelo menos, não fosse tão penoso utilizá-las.

Como você mesmo mencionou, são chaves naturais.  Não há problema
nenhum com elas.  A menos que se descubra que alguma é inútil, como
creio ser o caso do RG, mas aí o negócio é político.


-- 
skype:leandro.gfc.dutra?chat  Yahoo!: ymsgr:sendIM?lgcdutra
+55 (11) 3854 7191  gTalk: xmpp:leand...@jabber.org
+55 (11) 9406 7191ICQ/AIM: aim:GoIM?screenname=61287803
BRAZIL GMT-3  MSN: msnim:chat?contact=lean...@dutra.fastmail.fm
Sent from Sao Paulo, SP, Brésil
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Qual estrutura utilizar?

2010-01-07 Por tôpico Alexsander Rosa

Comentários no texto.

2010/1/7 Leandro DUTRA leandro.gfc.du...@gmail.com

 2010/1/4 Alexsander Rosa alexsander.r...@gmail.com:
  Isso me lembra aquela velha discussão sobre usar CPF/CNPJ como chave
  natural, o que é impossível porque inúmeros órgãos públicos compartilham
 o
  mesmo CNPJ.

 Há vários motivos pelos quais CNPF ou CNPJ podem não ser chave natural
 — a questão que se coloca é, justamente, de qual entidade?

 A entidade cliente, por exemplo. Ou quem sabe, fornecedor. Talvez
exista uma entidade pessoa que contém apenas os dados básicos (nome,
cpf/cnpj, etc) e as demais, como cliente, fornecedor, funcionário, etc
sejam especializações. De qualquer forma, não é prático usar, digamos, o
nome completo (+ nome da mãe para o caso dos homônimos): imagine um setor da
empresa conversando com outro, por telefone, sobre um cliente específico.
Além do tempo perdido ditando nomes potencialmente extensos, podem haver
clientes homônimos ou mesmo com grafia ou sonoridade similar. Um código
numérico faz muito mais sentido.


 Acho que eu mesmo já citei o caso de correntista de banco.  Há, por
 exemplo, mulheres casadas que não têm CNPF, porque nunca tiveram vida
 economicamente ativa, mas têm conta conjunta com o marido.  São
 correntistas sem CNPF.

 No teu caso, já poderíamos pensar numa entidade órgão público, que
 certamente tem outra chave.  Talvez, várias entidades.  Se é prático
 ou não separá-los numa base de dados, vai depender de muitas
 variáveis, como dialeto SQL, implementação física, volume de dados,
 tráfego de transações, ferramental de programação… mas, se não
 analisarmos as entidades — e para isso chaves naturais são
 indispensáveis, mesmo que acabem não sendo implementadas nalgum caso
 extremo —, nunca entenderemos os problemas.

 Tradicionalmente as empresas criam um código de cliente para cada cliente
mas permitem que eles cheguem no balcão munidos apenas com o CPF e localizem
seu registro. A chave natural não deixa de existir, apenas não é primária.


  Aqui no RS, por exemplo, simplesmente TODAS as escolas estaduais
  usam o CNPJ da Secretaria da Educação, não apenas a raiz, o CNPJ inteiro.
  Para o pagamento de empenhos os nomes das escolas precisam estar corretos
  até a última vírgula, não dá pra emitir a NF em nome da Secretaria e
 depois
  mandar entregar na escola.

 No mínimo, há uma entidade escola estadual cuja chave não é o CNPJ.
 Talvez o nome da escola, por exemplo (sei, sei, nome dificilmente é
 boa chave, só para provocar a pensar), ou até o nome e o endereço.

 Indo por este caminho acabaríamos criando entidades para escolas (cuja
chave primária pode ser o código INEP, como foi dito aqui), agências dos
correios (cada agência tem seu número), agências de alguns bancos públicos
(nº do banco + nº da agência), sedes do SESC (deve haver algum código que
eles usam) e assim por diante.


  É muito mais simples usar um SERIAL para código
  de cliente do que tentar achar uma chave natural viável.

 Sim, mas incorreto.

 Sendo mais preciso, pode ser necessária uma chave artificial; mas não
 tentar uma chave natural, mesmo que não seja declarada como a
 primária, seria convidar problemas pela porta da frente.

 Mas este é o processo: tentar em primeiro lugar uma chave natural como
chave primária. Mantenho o uso de chaves artificiais dentro do mínimo
necessário. Outro exemplo é o de código de produto: há quem use código de
barras como chave primária, mas nem todo produto tem código de barras.
Alguns são tão pequenos que é impossível sequer colocar uma etiqueta ou
similar, e outros ainda são adquiridos do mesmo fornecedor com códigos de
barras diferentes, por motivos que vão desde erro de impressão da embalagem
até origens diferentes.


  Sou totalmente a favor de chaves naturais, uso sempre que possível, mas
 há
  casos em que simplesmente não dá.

 Não dá o quê?

 Não dá para usar como chave primária, não estou preocupado.

 Não dá para declarar, estou para ver um caso.

 Eu me refiro a usar como chave primária.

-- 
Atenciosamente,
Alexsander da Rosa
Linux User #113925

Extremismo na defesa da liberdade não é defeito.
Moderação na busca por justiça não é virtude.
-- Barry Goldwater
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Qual estrutura utilizar?

2010/1/7 Mozart Hasse mozart.ha...@usa.net:
 Para a minoria (geralmente) dos casos em que é necessária, em SQL, uma
 chave artificial (e explicitada ao usuário), ela pode tranqüilamente
 ser a primária, não faz a menor diferença que a natural seja declarada
 sem ser primária.

 E ainda diz que sou em que crio espantalhos.
 Estou falando disso aqui:

 http://en.wikipedia.org/wiki/Surrogate_key

Eu também.

Veja que o artigo não identifica a chave primária com uma eventual
chave artificial.  E inclui a proposta de que o valor não deve ser
manipulável, talvez nem visível, para usuários e aplicações.

Ou seja, não entendi qual meu espantalho, nem o que há de errado na
minha frase supracitada.


 Usando a definição mais moderna da minoria que ouviu falar do Wieringa e
 De Jonge (última moda, 1991)

Que, segundo o artigo da Wikipedia supracitado, não deveria sequer
aparecer para o usuário.


 Como não tem, se uma chave artificial é um atributo a mais?  E se é
 freqüentemente abusado?

 Já expliquei por que esse atributo a mais melhora o desempenho e a estrutura
 da aplicação, consulte o histórico.

Em alguns casos… ou seja, seu uso só se justifica nas exceções.


 Recomendo que poste suas lamentações sobre os
 abusos que só você sabe e viu onde aconteceram na lista pertinente

Ah… acho que você não deve estar trabalhando com os sistemas que se
têm feito só com chaves artificiais, por causa de ORMs e coisas tais.
Se tiveres pachorra, pesquisa sobre Ruby on Rails, Hibernate et alli.


  2. Tamanho do comando SQL em consultas com várias junções, facilitando
  a vida do compilador e do otimizador;

 Irrelevante? tokenizado.

 Relevante, pois influi no número de tokens

Que é irrelavante.


 e no número de árvores

Que não é afetado.


 que o otimizador precisa analisar para escolher o plano de execução.

Que será escolhido apenas uma vez para cada consulta, portanto não é
relevante para a grande maioria dos sistemas.


 Estou para ver alguma diferença prática.  Muito me surpreenderia se
 houvesse alguma nas tabelas menores, que são a maioria.

 Pode ser uma senhora diferença quando juntar tabelas menores (menos de
 1 registros) com tabelas maiores e o otimizador decidir usar o índice
 ao invés de percorrer todos os registros da pequena tabela filha. No meu
 planeta a gente precisa disso com frequência.

Essa junção existe, mas é minoria.  Otimização precoce é a raiz de
toda sorte de males.


 Siga meu conselho e experimente, especialmente num projeto com volume de
 dados em que desempenho seja um dos requisitos e o hardware não seja
 ilimitado para esconder más decisões de modelagem.

Precisamente minha experiência.  E nesses projetos, só uma minoria das
tabelas precisa de chaves artificiais.  A maioria vai melhor com
chaves naturais, inclusive aquelas que incluem chaves artificiais
herdadas de tabelas-mãe.


 Novamente: se o seu problema é o ferramental que não ajuda a documentar,
 critique-o na lista apropriada. Poupe as chaves artificias, que não tem nada
 a ver com isso.

Desde quando estou falando mal de chaves artificiais?  Estou dizendo
que são abusadas, e como.


 E qual problema exige os nomes inconsistentes dos atributos nas
 relações do dicionário de dados do Oracle?

 Se eles te parecem inconsistentes, consulte os especialistas da área (ORACLE)
 na lista pertinente ou pergunte pro Tom (asktom.oracle.com).

Por acaso sou especialista na área, e perguntar ao Tom não vai
torná-los mais consistentes.  Isso é consenso, entre quem repara
nessas coisas.


 Só falta saber identificar quando ocorre o abuso, justificar por quê te
 parece um abuso e citá-lo no momento e local apropriados.

O que tentei fazer, mas pelo jeito não falo a mesma língua que tu.


-- 
skype:leandro.gfc.dutra?chat  Yahoo!: ymsgr:sendIM?lgcdutra
+55 (11) 3854 7191  gTalk: xmpp:leand...@jabber.org
+55 (11) 9406 7191ICQ/AIM: aim:GoIM?screenname=61287803
BRAZIL GMT-3  MSN: msnim:chat?contact=lean...@dutra.fastmail.fm
Sent from Sao Paulo, SP, Brésil
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Qual estrutura utilizar?

2010/1/7 Alexsander Rosa alexsander.r...@gmail.com:
 Comentários no texto.

Tranqüilo, é o padrão.


 2010/1/7 Leandro DUTRA leandro.gfc.du...@gmail.com

 Há vários motivos pelos quais CNPF ou CNPJ podem não ser chave natural
 — a questão que se coloca é, justamente, de qual entidade?

 A entidade cliente, por exemplo. Ou quem sabe, fornecedor. Talvez exista
 uma entidade pessoa que contém apenas os dados básicos (nome, cpf/cnpj,
 etc) e as demais, como cliente, fornecedor, funcionário, etc sejam
 especializações.

Exato — ao menos, conceitualmente, normalizando.  A questão é se vale
a pena implementar; mas essa só pode ser respondida para situações
específicas.  Genericamente, é preciso analisar as chaves (entre
outras coisas) para descobrir até onde se deve normalizar, para só
então decidir o que dá para implementar, entre tudo que se descobriu.


 De qualquer forma, não é prático usar, digamos, o nome
 completo (+ nome da mãe para o caso dos homônimos): imagine um setor da
 empresa conversando com outro, por telefone, sobre um cliente específico.

Usar como?

Usar como chave primária, ou como única chave, provavelmente.

Já declarar como chave natural, ainda que não a primária, é necessário
para evitar duplicações.

Especificamente nesse exemplo, provavelmente precise-se de uma chave
composta, visto que mesmo o conjunto de nome e filiação não costuma
ser chave.


 Tradicionalmente as empresas criam um código de cliente para cada cliente
 mas permitem que eles cheguem no balcão munidos apenas com o CPF e localizem
 seu registro. A chave natural não deixa de existir, apenas não é primária.

Aí está certo.


 Indo por este caminho acabaríamos criando entidades para escolas (cuja chave
 primária pode ser o código INEP, como foi dito aqui), agências dos correios
 (cada agência tem seu número), agências de alguns bancos públicos (nº do
 banco + nº da agência), sedes do SESC (deve haver algum código que eles
 usam) e assim por diante.

Exato.  O SQL não ajuda muito, mas pode ser necessário.

Não necessariamente com códigos particulares, embora eles sejam
atraente.  Poderia ser endereço, por exemplo.


 Sendo mais preciso, pode ser necessária uma chave artificial; mas não
 tentar uma chave natural, mesmo que não seja declarada como a
 primária, seria convidar problemas pela porta da frente.

 Mas este é o processo: tentar em primeiro lugar uma chave natural como chave
 primária.

Exato!

Conversando com boa vontade, a gente se entende…


  Sou totalmente a favor de chaves naturais, uso sempre que possível, mas
  há casos em que simplesmente não dá.

 Não dá para usar como chave primária, não estou preocupado.

 Eu me refiro a usar como chave primária.

Tudo certo.


 Extremismo na defesa da liberdade não é defeito.
 Moderação na busca por justiça não é virtude.
 -- Barry Goldwater

Hm, acho que não concordo… OT!  :-)


-- 
skype:leandro.gfc.dutra?chat  Yahoo!: ymsgr:sendIM?lgcdutra
+55 (11) 3854 7191  gTalk: xmpp:leand...@jabber.org
+55 (11) 9406 7191ICQ/AIM: aim:GoIM?screenname=61287803
BRAZIL GMT-3  MSN: msnim:chat?contact=lean...@dutra.fastmail.fm
Sent from Sao Paulo, SP, Brésil
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Qual estrutura utilizar?

2010-01-07 Por tôpico Alexsander Rosa

Que bom que acabamos nos entendendo...

2010/1/7 Leandro DUTRA leandro.gfc.du...@gmail.com


  De qualquer forma, não é prático usar, digamos, o nome
  completo (+ nome da mãe para o caso dos homônimos): imagine um setor da
  empresa conversando com outro, por telefone, sobre um cliente específico.

 Usar como?

 Usar como chave primária, ou como única chave, provavelmente.

 Já declarar como chave natural, ainda que não a primária, é necessário
 para evitar duplicações.

 Especificamente nesse exemplo, provavelmente precise-se de uma chave
 composta, visto que mesmo o conjunto de nome e filiação não costuma
 ser chave.

 Sim, eu me referia a usar como chave primária.

Agora uma curiosidade: um ex-colega de faculdade se chamava TÉLVIO e tinha
um irmão gêmeo chamado TÉLCIO. O irmão fez o título de eleitor primeiro e
meu colega não conseguiu tirar o título -- pelo menos até a época da
formatura. O sistema do TRE achou que era fraude, pois eles tinham os nomes
muito parecidos, mudando apenas uma letra, e tinham data de nascimento e
nome da mãe iguais. Ele deve estar com quase 40 anos hoje; não sei se
conseguiu votar algum dia.


  Extremismo na defesa da liberdade não é defeito.
  Moderação na busca por justiça não é virtude.
  -- Barry Goldwater

 Hm, acho que não concordo… OT!  :-)

 Com o extremismo ou com a moderação? :-)

-- 
Atenciosamente,
Alexsander da Rosa
Linux User #113925

Extremismo na defesa da liberdade não é defeito.
Moderação na busca por justiça não é virtude.
-- Barry Goldwater
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Qual estrutura utilizar?

2010/1/7 Alexsander Rosa alexsander.r...@gmail.com:
 Que bom que acabamos nos entendendo...

Costuma acontecer… talvez não tanto quanto deveria.


  Extremismo na defesa da liberdade não é defeito.
  Moderação na busca por justiça não é virtude.
  -- Barry Goldwater

 Hm, acho que não concordo… OT!  :-)

 Com o extremismo ou com a moderação? :-)

Com o ‘não é’.  Eu concordaria com ‘não necessariamente é’.  :-)


-- 
skype:leandro.gfc.dutra?chat  Yahoo!: ymsgr:sendIM?lgcdutra
+55 (11) 3854 7191  gTalk: xmpp:leand...@jabber.org
+55 (11) 9406 7191ICQ/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] Qual estrutura utilizar?

2010-01-07 Por tôpico mateusgra


Aconselho todos a ler :

http://it.toolbox.com/blogs/database-soup/testing-for-normalization-33119
http://it.toolbox.com/blogs/database-soup/normalization-performance-and-virtual-private-databases-32525

De Josh Berkus (CEO, PostgreSQL Experts) .


Leandro DUTRA wrote:
 
 2010/1/7 Alexsander Rosa alexsander.r...@gmail.com:
 Que bom que acabamos nos entendendo...
 
 Costuma acontecer… talvez não tanto quanto deveria.
 
 
  Extremismo na defesa da liberdade não é defeito.
  Moderação na busca por justiça não é virtude.
  -- Barry Goldwater

 Hm, acho que não concordo… OT!  :-)

 Com o extremismo ou com a moderação? :-)
 
 Com o ‘não é’.  Eu concordaria com ‘não necessariamente é’.  :-)
 
 
 -- 
 skype:leandro.gfc.dutra?chat  Yahoo!: ymsgr:sendIM?lgcdutra
 +55 (11) 3854 7191  gTalk: xmpp:leand...@jabber.org
 +55 (11) 9406 7191ICQ/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
 
 

-- 
View this message in context: 
http://old.nabble.com/Qual-estrutura-utilizar--tp26956001p27064579.html
Sent from the PostgreSQL - Brasil mailing list archive at Nabble.com.

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

Re: [pgbr-geral] Qual estrutura utilizar?

2010-01-07 Por tôpico Andre Fernandes

 Pelo contrário, estou aqui com o livro do Codd, _The Relational Model
 for Database Management: Version 2_.  Não existe outro modelo
 relacional, nem aplicação fora de bases de dados.  Aliás, a teoria não
 é somente matemática: fundamenta-se na lógica dos predicados /e/ na
 teoria dos conjuntos.



Boa tarde,
Lógica de predicados e teoria dos conjuntos são parte da matemática.
No restante, não discordo muito de ti, apenas devo dizer que modelo
relacional tem aplicação em qualquer armazenamento, até mesmo em bibliotecas
ou estoques,
não somente em bancos de dados. Infelizmente não é comum vermos o uso
explícito fora de bancos de dados, mas existe aplicação fora deste. A não
ser que consideremos
bibliotecas ou estoques de uma empresa como sendo bancos de dados (há um
professor alemão que menciona muito essa forma de se tratar banco de dados,
extendendo o conceito para qualquer agrupamento organizado de objetos e/ou
dados - todos os objetos podem ser considerados dados).


Abraços,
-- 
André de Camargo Fernandes
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Qual estrutura utilizar?

2010/1/7 Andre Fernandes fernandes.an...@gmail.com:
 Lógica de predicados e teoria dos conjuntos são parte da matemática.

Verdade, perdão pela desinformação.


 No restante, não discordo muito de ti, apenas devo dizer que modelo
 relacional tem aplicação em qualquer armazenamento, até mesmo em bibliotecas
 ou estoques, não somente em bancos de dados.

Uai, essa me interessou.  Tem alguma referência?


 A não ser que consideremos
 bibliotecas ou estoques de uma empresa como sendo bancos de dados (há um
 professor alemão que menciona muito essa forma de se tratar banco de dados,
 extendendo o conceito para qualquer agrupamento organizado de objetos e/ou
 dados - todos os objetos podem ser considerados dados).

De fato, qualquer coleção organizada de dados pode ser considerada uma
base.  O que me surpreenderia seriam objetos.  ¿Tens o nome de Herr
Profeßor Doktor?


-- 
skype:leandro.gfc.dutra?chat  Yahoo!: ymsgr:sendIM?lgcdutra
+55 (11) 3854 7191  gTalk: xmpp:leand...@jabber.org
+55 (11) 9406 7191ICQ/AIM: aim:GoIM?screenname=61287803
BRAZIL GMT-3  MSN: msnim:chat?contact=lean...@dutra.fastmail.fm
Sent from Sao Paulo, SP, Brésil
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Qual estrutura utilizar?

2010-01-04 Por tôpico Leandro DUTRA

2009/12/30 Mozart Hasse mozart.ha...@usa.net:
 Particularmente, prefiro saber quando muda uma chave.  Melhor que as
 alterações sejam explícitas que implícitas.

 Quer saber quando a chave muda? Registre alterações via trigger numa
 tabela de histórico. Teu modelo não tem nenhuma obrigação de mudar
 por causa desse desejo.

Hm, não me expliquei bem.  Creio que a aplicação deve saber quando uma
chave natural exportada mudar — ou melhor, o programador.  Não é uma
alteração comum, e o custo de pensar sobre ela vale a pena os
benefícios.


 E isso pode mudar a qualquer momento quando os requisitos do seu sistema
 mudarem.

Naturalmente — e, mais uma vez, prefiro mudanças explícitas a implícitas.


 Conheci sistemas que precisaram colocar até nome da mãe na chave
 alternativa da tabela de pessoas para evitar duplicidades. Que tal fazer
 isso na minha tabela de pessoas, com 47 filhas?

Até mais que o nome da mãe… poderia chegar ao ponto do DNA, das
digitais, da íris entrarem para a chave.  A idéia da chave artificial
foi justamente lidar com esse tipo de situação.  Nunca foi
implementada corretamente, mas mesmdo do jeito que está pode ser útil
e, até, necessário.

 Quer embutir essa tralha
 toda na chave primária e em todas as chaves estrangeiras por questão de
 purismo conceitual?

Não.  Nunca falei isso.  Falei que geralmente chave artificial é
desnecessária; não que é sempre desnecessária.  E, aliás, que o que
menos me importa é qual seja a chave primária, ou qual chave será
‘exportada’ (não nesta discussão, talvez).


 Em TODOS os bancos de dados o tamanho do índice conta na decisão de usá-lo
 ou não, e uma chave serial de 2, 4 ou 8 bytes jamais será maior do que
 qualquer chave natural que se encontre para a mesma tabela. Portanto, usar
 chaves naturais para fazer FKs aumenta sim o tamanho dos índices e tem toda a
 chance de igualar ou piorar o desempenho.

Pelo contrário, uma chave artificial (que não é chave,
conceitualmente) tem de ser definida *além* das naturais, e portanto
sempre será gordura.  Pode ser uma gordura necessária, mas em alguns
casos, não todos.

Aliás, que diferença faz o tamanho da chave para a maioria das
tabelas, que não tem filhas de tamanho significativo?  Evitar junções
desnecessárias costuma ser mais importante.


 Se quer ler e entender o modelo, use a representação conceitual (modelo
 lógico).

Que, normalmente, não é mantido e, quando é, geralmente é apenas uma
reversa do físico, ocultando mais do que explicando.


 3 anos é pouco pra você?! Tá bom, que tal o sistema que mantenho hoje, que
 tem uns 15?

Melhorando!


 900 tabelas tá bom pra você ou é meio pequenininho pra entrar na conta?

A quantidade de tabelas parece interessante… mas você já está na
polêmica pela polêmica, caro Herr Hasse.  Não percebeu, ou esqueceu,
que não estou impondo verdades absolutas, mas derrubando regrinhas
estúpidas que são úteis nalguns casos mas prejudicam na maioria.  Veja
que em nenhum lugar tentei proibir chaves artificiais; só disse que
elas são úteis numa minoria dos casos onde são usadas hoje.  Parabéns
por ter um sistema grande e longevo.  Mas não use tua experiência e
capacidade para desprezar a experiência e capacidade de outros.  Leia
o que foi escrito, não o que te irritou no passado.  Parece que não
estás lendo o que escrevi, mas algo que algum sabichão falou sabe-se
lá quando e ficou atravessado em tua garganta.


 Catálogo do Oracle mal modelado? Quando apresentar algum mais normalizado que
 faça o mesmo que ele e ainda por cima tenha o mesmo desempenho, avise.

Simples: o do PostgreSQL.  Mas isso foi apenas sacanagenzinha minha…

Falando sério, é só ver a inconsistência dos nomes de atributos…


 Isto é apenas um número sem fonte (vulgo chute) com um valor cheio de zeros.

De fato não li o referido estudo, e não tenho a pachorra de buscá-lo
agora.  O interessante é que, para quem tem experiência na área, não
parece tão absurdo quanto deveria.  Creio que tu mesmo concordarias,
não estivesses tão quente com a polêmica.

Aliás, quero escrever um pouco a respeito, dia desses… todas as
oportunidades desperdiçadas, por exemplo com programação funcional e
de pilha, processadores específicos, computação hospedeiro-terminais,
sistemas abertos e livres, processadores RISC, Unix e Plan9, métodos
formais, sistemas relacionais… o mundo poderia ser bem melhor.


 Nível de isolamento serializável, e de quebra a aplicação fica mais
 robusta.

 E mais lenta, especialmente em acessos concorrentes. Nem todo mundo tem tempo,
 dinheiro ou motivo para esperar.

Nem tão mais lenta quanto se pensa, nem todo mundo tem o gargalo aí.
Geralmente, a aplicação mais robusta e melhor pensada mais do que
compensaria os custos computacionais da serialização.


 Não, pois faço os testes de desempenho com uma única conexão a um servidor
 dedicado.

Hm, isso não seria um teste válido para muitos casos… mas é claro que
conheces tua situação melhor que qualquer um de fora.


 Tamanho do índice entra na conta,

Re: [pgbr-geral] Qual estrutura utilizar?

2010-01-04 Por tôpico Alexsander Rosa

Isso me lembra aquela velha discussão sobre usar CPF/CNPJ como chave
natural, o que é impossível porque inúmeros órgãos públicos compartilham o
mesmo CNPJ. Aqui no RS, por exemplo, simplesmente TODAS as escolas estaduais
usam o CNPJ da Secretaria da Educação, não apenas a raiz, o CNPJ inteiro.
Para o pagamento de empenhos os nomes das escolas precisam estar corretos
até a última vírgula, não dá pra emitir a NF em nome da Secretaria e depois
mandar entregar na escola. É muito mais simples usar um SERIAL para código
de cliente do que tentar achar uma chave natural viável.

Sou totalmente a favor de chaves naturais, uso sempre que possível, mas há
casos em que simplesmente não dá.

2010/1/4 Leandro DUTRA leandro.gfc.du...@gmail.com


 Não.  Nunca falei isso.  Falei que geralmente chave artificial é
 desnecessária; não que é sempre desnecessária.  E, aliás, que o que
 menos me importa é qual seja a chave primária, ou qual chave será
 ‘exportada’ (não nesta discussão, talvez).
 (...)
 O problema não é a existência do SERIAL, é seu uso — e abuso.

 Para bom entendedor… fica claro que o que exijo é chave natural,
 independente de ser primária ou alternativa, e que prefiro que não
 haja artificial a não ser que o desempenho exija.



-- 
Atenciosamente,
Alexsander da Rosa
Linux User #113925

Extremismo na defesa da liberdade não é defeito.
Moderação na busca por justiça não é virtude.
-- Barry Goldwater
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Qual estrutura utilizar?

2010-01-04 Por tôpico Andre Fernandes

Boa tarde,
Pessoalmente, após analisar um pouco mais o assunto, sou a favor de chaves
artificiais em muitas tabelas, salvo algumas poucas exceções. Isso não
significa que a chave artificial precise estar desprovida de significado.
Uma chave primária tem de ser a forma de buscar na tabela usada
primariamente e que identifica o registro. Isso significa que criar uma
chave artificial numa tabela de pedidos pode ter um sentido, é a
identificação de qual o pedido do cliente e quando o mesmo ligar, será
solicitada essa chave (número do pedido) para achar o mesmo. Por outro lado,
se formos olhar a tabela de clientes, quando um cliente ligar, o que
pediremos dele? O CPF/CNPJ, nome, etc., ou o seu número de cadastro (Id)?
Nesse caso a chave artificial perde o sentido (meaningless), e precisamos
avaliar se haveria razão para usá-la.
Antes que mencionem que podemos ter alguma alteração em chaves primárias
naturais (mudanças de regras de negócio, por exemplo), essa não seria uma
boa justificativa para não usá-las visto a teoria Relacional não proibir
alterações de chaves primárias. Por outro lado, no caso de um cliente, qual
seria uma boa alternativa? Eu diria que o CPF/CNPJ pois é único, identifica
o registro. Contudo nesse caso temos de analisar outro aspecto, tamanho
ocupado. Supondo que não guardamos os dígitos nem traços, teremos um campo
com tamanho 14. Na tabela de clientes temos esse registro e em todas as
tabelas que possuam chave estrangeira para ela.
Se usássemos um inteiro longo, teríamos na tabela de clientes adicionado 8
bytes por linha, e em todas as tabelas que possuam chave estrangeira para
com ela adicionaríamos 8 bytes e tiraríamos o tamanho da string (15 bytes).
Ou seja, diminuiríamos em cada linha de cada tabela 7 bytes.
Colocando valores para teste, imaginemos que tenhamos 1 clientes
cadastrados, 120 pedidos (incluindo cancelados), 22000 telefones
cadastrados (a tabela telefone teria uma chave estrangeira para indicar qual
o cliente dono do mesmo) e 12400 endereços cadastrados (a tabela de
endereços teria uma chave estrangeira para indicar qual o cliente dono do
mesmo).
Nota: os valores são de um período de uma base na qual trabalhei
(arredondados), somente não posso mencionar o nome da empresa.
Voltando ao caso, temos adicionados 8*1 bytes na tabela clientes com
relação a não termos essa chave artificial, e ganhamos 7 *
(120+22000+12400) bytes, ou seja, neste caso o ganho de espaço (sem nem
considerar as chaves em si, que também ocupam espaço em disco) seria
considerável.
Vários casos assim podem ter vantagem de chaves artificiais, mas precisamos
tomar cuidado, isso não é lei, há exceções. Ainda não há provas concretas e
irrefutáveis de que usar chaves naturais ou artificiais seja a melhor
alternativa, talvez por nem ser possível isso, mas muitas vezes chaves
artificiais são uma ótima adição.
Recomendo que verifiquem se vale a pena o uso de chaves artificiais.

Atenciosamente,
André.


PS: a teoria relacional não trata de chaves artificiais ou naturais, não
especifica nenhuma delas, trata de normalizações e relações entre conjuntos.
Aliás, nem trata de banco de dados, banco de dados apenas usam a mesma, mas
não são as únicas coisas que usam essa teoria matemática.

PS2: No exemplo apresentado, por quê não usas o código INEP?

2010/1/4 Alexsander Rosa alexsander.r...@gmail.com

 Isso me lembra aquela velha discussão sobre usar CPF/CNPJ como chave
 natural, o que é impossível porque inúmeros órgãos públicos compartilham o
 mesmo CNPJ. Aqui no RS, por exemplo, simplesmente TODAS as escolas estaduais
 usam o CNPJ da Secretaria da Educação, não apenas a raiz, o CNPJ inteiro.
 Para o pagamento de empenhos os nomes das escolas precisam estar corretos
 até a última vírgula, não dá pra emitir a NF em nome da Secretaria e depois
 mandar entregar na escola. É muito mais simples usar um SERIAL para código
 de cliente do que tentar achar uma chave natural viável.

 Sou totalmente a favor de chaves naturais, uso sempre que possível, mas há
 casos em que simplesmente não dá.

 2010/1/4 Leandro DUTRA leandro.gfc.du...@gmail.com


 Não.  Nunca falei isso.  Falei que geralmente chave artificial é
 desnecessária; não que é sempre desnecessária.  E, aliás, que o que
 menos me importa é qual seja a chave primária, ou qual chave será
 ‘exportada’ (não nesta discussão, talvez).
 (...)
 O problema não é a existência do SERIAL, é seu uso — e abuso.

 Para bom entendedor… fica claro que o que exijo é chave natural,
 independente de ser primária ou alternativa, e que prefiro que não
 haja artificial a não ser que o desempenho exija.



 --
 Atenciosamente,
 Alexsander da Rosa
 Linux User #113925

 Extremismo na defesa da liberdade não é defeito.
 Moderação na busca por justiça não é virtude.
 -- Barry Goldwater

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




-- 
André

Re: [pgbr-geral] Qual estrutura utilizar?

2010-01-04 Por tôpico Leonardo Cezar

2010/1/4 Alexsander Rosa alexsander.r...@gmail.com:
 Então devo fazer uma chave composta com CNPJ+INEP e deixar NULL no campo
 codigo_inep em 99% dos registros?

De forma alguma!!!

Cada instituição obrigatoriamente deve possuir um código INEP, segundo
Ministério da Educação. Portanto este código é de fato a *chave
natural* de uma instituição de ensino e nao precisa de outro atributo
para compor a unicidade.

 Escolas são apenas uma pequena parte do
 problema, outras secretarias em outras esferas apresentam o mesmo problema.
 Outros exemplos: Correios, CEEE, SESC, etc. Parece mais um caso onde a
 emenda é pior que o soneto.

Eu imagino mesmo que deve ser só a ponta do iceberg, no entanto eu
utilizei o exemplo do INEP para ressaltar a importancia da *analise*
para identificar as chaves e entidades ainda na fase de modelagem.

-Leo
-- 
Leonardo Cezar
http://www.aslid.org.br
http://postgreslogia.wordpress.com
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Qual estrutura utilizar?

2010-01-04 Por tôpico Andre Fernandes

Boa tarde,
Eu tinha perguntado a mesma coisa há pouco... :-)

Mas também já vi a resposta, abraços, desculpa por ter mencionado a mesma
coisa...


Utilize o código INEP [1] ... ;-) que naturalmente deveria ser a chave
 de instituição educional.

 1) inep.gov.br

 /só-pra-ser-chato

 -Leo
 --
 Leonardo Cezar
 http://www.aslid.org.br
 http://postgreslogia.wordpress.com
 ___
 pgbr-geral mailing list
 pgbr-geral@listas.postgresql.org.br
 https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral




-- 
André de Camargo Fernandes
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Qual estrutura utilizar?

2010-01-04 Por tôpico Eduardo Andrade Bahiense


Leonardo Cezar escreveu:

2010/1/4 Alexsander Rosa alexsander.r...@gmail.com:
  

Então devo fazer uma chave composta com CNPJ+INEP e deixar NULL no campo
codigo_inep em 99% dos registros?



De forma alguma!!!

Cada instituição obrigatoriamente deve possuir um código INEP, segundo
Ministério da Educação. Portanto este código é de fato a *chave
natural* de uma instituição de ensino e nao precisa de outro atributo
para compor a unicidade.
  
Exceto que algumas escolas públicas compartilham este código com outras 
por serem, fisicamente independentes, mas, formalmente, partes de uma 
outra escola.


O que estamos esquecendo de considerar nesta discussão é que algumas 
informações como códigos de pessoas, alunos, escolas, clintes, entre 
outros, atribuídos de forma serial, já faziam parte das rotinas de 
instituições antes de alguém pensar em energia elétrica, e que, por 
regra de negócio, são chaves naturais e não artificiais, pois os 
sistemas devem continuar gerando esses números para satisfazer 
requisitos do próprio negócio. Então, não dá para ir contra a própria 
ordem natural das coisas. O que concordo em grau, gênero e número é que 
muitos usam chaves artificiais como uma regra absoluta, alegando, em 
análise reversa, que o fazem por questão de performance, quando deveriam 
elaborar melhor o modelo e se valer das chaves naturais, sempre que, 
pelo menos, não fosse tão penoso utilizá-las.


Eduardo

  

Escolas são apenas uma pequena parte do
problema, outras secretarias em outras esferas apresentam o mesmo problema.
Outros exemplos: Correios, CEEE, SESC, etc. Parece mais um caso onde a
emenda é pior que o soneto.



Eu imagino mesmo que deve ser só a ponta do iceberg, no entanto eu
utilizei o exemplo do INEP para ressaltar a importancia da *analise*
para identificar as chaves e entidades ainda na fase de modelagem.

-Leo
  




Nenhum vírus encontrado nessa mensagem recebida.
Verificado por AVG - www.avgbrasil.com.br 
Versão: 9.0.725 / Banco de dados de vírus: 270.14.124/2598 - Data de Lançamento: 01/03/10 07:41:00


  


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

Re: [pgbr-geral] Qual estrutura utilizar?

2010-01-04 Por tôpico Leonardo Cezar

2010/1/4 Andre Fernandes fernandes.an...@gmail.com:
 Boa tarde,
 Eu tinha perguntado a mesma coisa há pouco... :-)

 Mas também já vi a resposta, abraços, desculpa por ter mencionado a mesma
 coisa...

Afe ...
Boiei!

-Leo
-- 
Leonardo Cezar
http://www.aslid.org.br
http://postgreslogia.wordpress.com
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Qual estrutura utilizar?

2010-01-04 Por tôpico Andre Fernandes

Sobre o código INEP, usar o código INEP no lugar de CNPJ...

Abraços,

2010/1/4 Leonardo Cezar lhce...@gmail.com

 2010/1/4 Andre Fernandes fernandes.an...@gmail.com:
  Boa tarde,
  Eu tinha perguntado a mesma coisa há pouco... :-)
 
  Mas também já vi a resposta, abraços, desculpa por ter mencionado a mesma
  coisa...

 Afe ...
 Boiei!

 -Leo
 --
 Leonardo Cezar
 http://www.aslid.org.br
 http://postgreslogia.wordpress.com
 ___
 pgbr-geral mailing list
 pgbr-geral@listas.postgresql.org.br
 https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral




-- 
André de Camargo Fernandes
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Qual estrutura utilizar?

2009-12-30 Por tôpico Leandro DUTRA

2009/12/29 Marcal Hokama mhok...@hotmail.com:
 haverá uma demanda de processamento (envolvendo CPU, memória e E/S), até por 
 outra informação dada:  porém quando inicia a execução das classificações o 
 desempenho do servidor cai drasticamente.

Há muitos fatores a considerar, ainda… os algoritmos são eficientes?
O momento dos cálculos é conveniente?  Que outras formas de os fazer
haveria?  Qual o gargalo, E/S ou processador?  E vai por aí afora.


 é bem provável que o modelo atual (transacional) nao atenderá a essa 
 necessidade de emissão de relatórios em tempo real, sendo necessária a 
 criação de novas estruturas para atender a essa finalidade.

Uma coisa não exclui a outra.  Novas estruturas não significam que o
modelo atual não atende; é tudo questão de modelo físico e
circunstâncias.


 Tudo depende do contexto em que vai ser aplicado. Existem soluções que não 
 são adequadas para determinados casos e para outros são.

CQD.


-- 
skype:leandro.gfc.dutra?chat  Yahoo!: ymsgr:sendIM?lgcdutra
+55 (11) 3854 7191  gTalk: xmpp:leand...@jabber.org
+55 (11) 9406 7191ICQ/AIM: aim:GoIM?screenname=61287803
BRAZIL GMT-3  MSN: msnim:chat?contact=lean...@dutra.fastmail.fm
Sent from Sao Paulo, SP, Brazil
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Qual estrutura utilizar?

2009-12-30 Por tôpico Mozart Hasse

Leandro, 

 Particularmente, prefiro saber quando muda uma chave.  Melhor que as
 alterações sejam explícitas que implícitas.

Quer saber quando a chave muda? Registre alterações via trigger numa 
tabela de histórico. Teu modelo não tem nenhuma obrigação de mudar 
por causa desse desejo.

 Os problemas do CNPF são outros, geralmente: gente que não tem CNPF
 pode até ter conta bancária, por exemplo mulheres casadas com conta
 conjunta com o marido.

E isso pode mudar a qualquer momento quando os requisitos do seu sistema 
mudarem. Conheci sistemas que precisaram colocar até nome da mãe na chave 
alternativa da tabela de pessoas para evitar duplicidades. Que tal fazer 
isso na minha tabela de pessoas, com 47 filhas? Quer embutir essa tralha 
toda na chave primária e em todas as chaves estrangeiras por questão de 
purismo conceitual? Quando eu trocar o tamanho do campo vou ter de criar 
um script monstruoso que levará horas ao invés de 30 segundos digitando 
uma linha. Quando alguém digitar errado o nome do cara durante o cadastro 
e notar isso no mês seguinte, depois de lanças algumas dezenas de notas, 
devo deixar o cliente esperando a emissão de nota ficar parada porque o 
banco de dados precisa aplicar o cascade nas 47 filhas para o modelo não 
ser prejudicado? Na-na-ni-na-não.

  Exemplos pf, engorda a base? Pelo que entendo facilita até a maneira que
  o banco trabalha.

 Em alguns casos, já citados, sim, por limitações do SQL.  Mas na
 maioria dos casos é um atributo e um índice a mais sem necessidade, e
 mais junções.

Em TODOS os bancos de dados o tamanho do índice conta na decisão de usá-lo
ou não, e uma chave serial de 2, 4 ou 8 bytes jamais será maior do que
qualquer chave natural que se encontre para a mesma tabela. Portanto, usar
chaves naturais para fazer FKs aumenta sim o tamanho dos índices e tem toda a
chance de igualar ou piorar o desempenho.

  Obscurece o modelo? Por favor seja mais específico.
 
 Quem lê um modelo com chaves naturais entende tudo; quem lê um modelo
 com chaves artificiais tem de adivinhar muita coisa.

Se quer ler e entender o modelo, use a representação conceitual (modelo
lógico). Quando 
puser para funcionar, terá de lidar com o modelo *físíco*, com todas as
tabelas, índices, 
chaves artificiais, índices, triggers, visões materializadas e qualquer
outra coisa que
sirva para deixar a aplicação com um desempenho decente.

 Eu diria que é para evitar ser amaldiçoado por todas as gerações
 futuras de usuários, programadores e analistas, sem falar nos DBAs.

Estou pra conhecer um DBA que goste de rasgar SLAs com cláusulas de tempo de
resposta mínimo e mande todo mundo parar de trabalhar para esperar o banco
fazer um DELETE CASCADE
numa tabela com mais de 10 registros.
Estou também para conhecer um DBA que seja contratado por alguém que se dê
ao luxo 
pagar um cara qualificado para dizer para o cliente senta e chora quando
identificar 
deadlocks causados por purismos conceituais.

 Claro!  Mas eu tenho o pressentimento de que, como está, teu sistema
 dificilmente crescerá muito, e continuará a ser mantido por ti, então
 nada do que falei se tornará visível.

3 anos é pouco pra você?! Tá bom, que tal o sistema que mantenho hoje, que
tem uns 15?
900 tabelas tá bom pra você ou é meio pequenininho pra entrar na conta?

 Na verdade, mesmo os grandes ERPs têm péssimos modelos.  Até o
 catálogo da Oracle é mal modelado.  

Catálogo do Oracle mal modelado? Quando apresentar algum mais normalizado que
faça 
o mesmo que ele e ainda por cima tenha o mesmo desempenho, avise.

 Dá para ir tocando, mas são custos ocultos.  
 Alguém os estimou globalmente em US$1,2T por ano.

Isto é apenas um número sem fonte (vulgo chute) com um valor cheio de zeros.
Chutes 
não vão convencer ninguém a mudar de idéia nem vão justificar qualquer
abordagem que
se apresente.

 especialmente se você quiser usar a chave para
 identificar alterações concorrentes sobre o mesmo registro

 Nível de isolamento serializável, e de quebra a aplicação fica mais
robusta.

E mais lenta, especialmente em acessos concorrentes. Nem todo mundo tem tempo,

dinheiro ou motivo para esperar.

 Agora me dei conta? será que teus problemas recorrentes de desempenho
 não são por controle de transações na aplicação?

Não, pois faço os testes de desempenho com uma única conexão a um servidor
dedicado.

 A melhoria é grande demais para ser ignorada, pois
 quase todos os índices ficarão menores

 Ou melhor, depende. Tabela mãe pequena e pouco usada com tabelas
 filhas grandes, pode ser, se não forçar junções demais.

Tamanho do índice entra na conta, especialmente com muitos registros tanto na
tabela pai quanto na filha.

 Mas sempre haverá um índice a mais, tanto em disco quanto em memória,
 ocupando também cache e exigindo atualizações.

O que só seria problema se a atividade mais frequente fosse atualizar as
tabelas 
ao invés de consultá-las.

 e com distribuição estatística mais
 evidente (do ponto de vista do banco de dados)

Re: [pgbr-geral] Qual estrutura utilizar?

2009-12-30 Por tôpico Marcal Hokama

From: leandro.gfc.du...@gmail.com
Date: Wed, 30 Dec 2009 07:40:50 -0200
To: pgbr-geral@listas.postgresql.org.br
Subject: Re: [pgbr-geral] Qual estrutura utilizar?

2009/12/29 Marcal Hokama :
haverá uma demanda de processamento (envolvendo CPU, memória e E/S), até por
outra informação dada: porém quando inicia a execução das classificações o
desempenho do servidor cai drasticamente.

Há muitos fatores a considerar, ainda… os algoritmos são eficientes?
O momento dos cálculos é conveniente? Que outras formas de os fazer
haveria? Qual o gargalo, E/S ou processador? E vai por aí afora.

Ok, ok... Vou voltar no tempo para tentar ajudar na dúvida original do Eder
Sousa:

Tenho um sistema de Distribuição onde 99% das atividades é inclusão de
registros que por sua vez está incluido em um database, surgiu a
necessidade de implantar um novo database onde será efetuado a carga de
dados diárias com aproximadamente 50.000 registros dias, porém neste
database será classificado N calculo para administrar o estoque de 55
filiais.
Até a carga de dados funciona maravilhosamente, porém quando inicia a
execução das classificações o desempenho do servidor cai drasticamente.
Pergunto: Neste caso é necessário um novo servidor para executar os
cálculos, ao invés de efetuar no mesmo servidor??
Só para conhecimento o servidor é um Quadcore com 8GB RAM e 1 Tera de
HD
[]s

Eder, eu diria que seria interessante neste caso saber algumas coisas:

1- O que você chama de classificações, o que faz exatamente?
2- De quanto em quanto tempo esta operação é executada?
3- Os dados gerados por estas classificações são armazenados em algum lugar?

é bem provável que o modelo atual (transacional) nao atenderá a essa
necessidade de emissão de relatórios em tempo real, sendo necessária a
criação de novas estruturas para atender a essa finalidade.

Uma coisa não exclui a outra. Novas estruturas não significam que o
modelo atual não atende; é tudo questão de modelo físico e
circunstâncias.

Leandro, se eu tenho meu modelo de dados, e uma necessidade de uma determinada
consulta que, utilizando as estruturas atuais, já foi otimizada ao máximo e o
tempo decorrido não atende a necessidade do cliente, como vou dizer que esse
modelo atual, sem ter nenhuma modificação, atende a minha necessidade?

Marçal de Lima Hokama
--
_
Faça transações bancárias de maneira segura. Baixe agora o Novo Internet
Explorer 8.
http://brasil.microsoft.com.br/IE8/mergulhe/?utm_source=MSN%3BHotmailutm_medium=Taglineutm_content=Tag2utm_campaign=IE8
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] Qual estrutura utilizar?


Tenho um sistema de Distribuição onde 99% das atividades é inclusão de
registros que por sua vez está incluido em um database, surgiu a
necessidade de implantar um novo database onde será efetuado a carga de
dados diárias com aproximadamente 50.000 registros dias, porém neste
database será classificado N calculo para administrar o estoque de 55
filiais.

Até a carga de dados funciona maravilhosamente, porém quando inicia a
execução das classificações o desempenho do servidor cai drasticamente.
Pergunto: Neste caso é necessário um novo servidor para executar os
cálculos, ao invés de efetuar no mesmo servidor??

Só para conhecimento o servidor é um Quadcore com 8GB RAM e 1 Tera de
HD 

[]s

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

Re: [pgbr-geral] Qual estrutura utilizar?

2009-12-29 Por tôpico JotaComm

Olá,

2009/12/29 lis...@softpira.com


 Tenho um sistema de Distribuição onde 99% das atividades é inclusão de
 registros que por sua vez está incluido em um database, surgiu a
 necessidade de implantar um novo database onde será efetuado a carga de
 dados diárias com aproximadamente 50.000 registros dias, porém neste
 database será classificado N calculo para administrar o estoque de 55
 filiais.


O que você considera um novo database. É um novo banco de dados separado? Ou
um novo esquema dentro do banco de dados atual?

A carga será em massa, isto é, em determinado horário serão inseridos 50 mil
registros ou isso será feito durante o dia todo?

Não entendi a última parte: Neste database será classificado N cálculo para
administrar...




 Até a carga de dados funciona maravilhosamente, porém quando inicia a
 execução das classificações o desempenho do servidor cai drasticamente.
 Pergunto: Neste caso é necessário um novo servidor para executar os
 cálculos, ao invés de efetuar no mesmo servidor??


Esta classificação é realizada a todo o momento ou em horários específicos?

Como está a configuração do postgresql.conf?


 Só para conhecimento o servidor é um Quadcore com 8GB RAM e 1 Tera de
 HD

 []s

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



[]s
-- 
JotaComm
http://jotacomm.wordpress.com
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Qual estrutura utilizar?


Graaande JP tudo bem???

Vamos por partes...

Um novo database para mim:

1.) O mesmo servidor possuindo dois BANCO DE DADOS:

EXEMPLO:

CREATE DATABASE producao
  WITH OWNER = postgres
   ENCODING = 'UTF8'
   CONNECTION LIMIT = -1;
ALTER DATABASE producao SET work_mem=100MB;

CREATE DATABASE producao2
  WITH OWNER = postgres
   ENCODING = 'UTF8'
   CONNECTION LIMIT = -1;
ALTER DATABASE producao SET work_mem=100MB;


2.) Sim a carga de 50.000 registros será em massa (no caso acima será no
producao2) porém no producao está a todo o momento incluindo
informações, em torno de 7.000 registros que neste caso não estarei
usando em cálculos.

3.) A Classificação que mencionei, são cálculos de vendas nos últimos
3 meses (aproximadamente 4.500.000 registros), 30 dias (aproximadamente
1.500.000 registros), 13800 produtos, das 55 filiais (solicitação de
amigos consultores..r).

4.) O postgresql é a versão 8.3.5 e a segundo a ultima consultoria (neste
caso do Banco de Dados) nos informaram o ideal é separar estas ações em
servidores diferentes pq temos dois bancos distintos, um para carga e
outro para classificação (Consultas, cálculos, classificações).

Abraços,

Eder Sousa



On Tue, 29 Dec 2009 13:56:58 -0200, JotaComm jota.c...@gmail.com wrote:
 Olá,
 
 2009/12/29 lis...@softpira.com
 

 Tenho um sistema de Distribuição onde 99% das atividades é inclusão
 de
 registros que por sua vez está incluido em um database, surgiu a
 necessidade de implantar um novo database onde será efetuado a carga de
 dados diárias com aproximadamente 50.000 registros dias, porém neste
 database será classificado N calculo para administrar o estoque de 55
 filiais.

 
 O que você considera um novo database. É um novo banco de dados
separado?
 Ou
 um novo esquema dentro do banco de dados atual?
 
 A carga será em massa, isto é, em determinado horário serão inseridos
 50 mil
 registros ou isso será feito durante o dia todo?
 
 Não entendi a última parte: Neste database será classificado N
cálculo
 para
 administrar...
 
 
 

 Até a carga de dados funciona maravilhosamente, porém quando inicia a
 execução das classificações o desempenho do servidor cai
 drasticamente.
 Pergunto: Neste caso é necessário um novo servidor para executar os
 cálculos, ao invés de efetuar no mesmo servidor??

 
 Esta classificação é realizada a todo o momento ou em horários
 específicos?
 
 Como está a configuração do postgresql.conf?
 

 Só para conhecimento o servidor é um Quadcore com 8GB RAM e 1 Tera de
 HD

 []s

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

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

Re: [pgbr-geral] Qual estrutura utilizar?

2009/12/29  lis...@softpira.com:

 1.) O mesmo servidor possuindo dois BANCO DE DADOS:

Normalmente, o que se quer são dois esquemas na mesma base ou, mais
raramente, dois servidores diferentes.


 2.) Sim a carga de 50.000 registros será em massa (no caso acima será no
 producao2) porém no producao está a todo o momento incluindo
 informações, em torno de 7.000 registros que neste caso não estarei
 usando em cálculos.

7K registros em que período de tempo?


 3.) A Classificação que mencionei, são cálculos de vendas nos últimos
 3 meses (aproximadamente 4.500.000 registros), 30 dias (aproximadamente
 1.500.000 registros), 13800 produtos, das 55 filiais (solicitação de
 amigos consultores..r).

Nada disso é significativo se não soubermos que carga geram esses cálculos.


 4.) O postgresql é a versão 8.3.5 e a segundo a ultima consultoria (neste
 caso do Banco de Dados) nos informaram o ideal é separar estas ações em
 servidores diferentes pq temos dois bancos distintos, um para carga e
 outro para classificação (Consultas, cálculos, classificações).

Impossível dizer sem saber o perfil de execução de cada tarefa.


-- 
skype:leandro.gfc.dutra?chat  Yahoo!: ymsgr:sendIM?lgcdutra
+55 (11) 3854 7191  gTalk: xmpp:leand...@jabber.org
+55 (11) 9406 7191ICQ/AIM: aim:GoIM?screenname=61287803
BRAZIL GMT-3  MSN: msnim:chat?contact=lean...@dutra.fastmail.fm
Sent from Sao Paulo, SP, Brazil
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Qual estrutura utilizar?

2009-12-29 Por tôpico JotaComm

Olá,

2009/12/29 lis...@softpira.com


 Graaande JP tudo bem???

 Vamos por partes...

 Um novo database para mim:

 1.) O mesmo servidor possuindo dois BANCO DE DADOS:

EXEMPLO:

CREATE DATABASE producao
  WITH OWNER = postgres
   ENCODING = 'UTF8'
   CONNECTION LIMIT = -1;
ALTER DATABASE producao SET work_mem=100MB;

CREATE DATABASE producao2
  WITH OWNER = postgres
   ENCODING = 'UTF8'
   CONNECTION LIMIT = -1;
ALTER DATABASE producao SET work_mem=100MB;


 Acho que pode ser um novo esquema e não necessariamente um novo banco de
dados, pois se você tiver que comunicar os dois bancos você terá que usar um
dblink, enquanto que se você usar esquemas um simples JOIN especificando o
esquema resolve o problema.

Uma pergunta. Vocês já fizeram um medição para definição do work_mem com
100MB? Sem uma noção dos processos (consultas) e vendo de longe me parece um
valor bem alto.


 2.) Sim a carga de 50.000 registros será em massa (no caso acima será no
 producao2) porém no producao está a todo o momento incluindo
 informações, em torno de 7.000 registros que neste caso não estarei
 usando em cálculos.


Beleza.


 3.) A Classificação que mencionei, são cálculos de vendas nos últimos
 3 meses (aproximadamente 4.500.000 registros), 30 dias (aproximadamente
 1.500.000 registros), 13800 produtos, das 55 filiais (solicitação de
 amigos consultores..r).

 4.) O postgresql é a versão 8.3.5 e a segundo a ultima consultoria (neste
 caso do Banco de Dados) nos informaram o ideal é separar estas ações em
 servidores diferentes pq temos dois bancos distintos, um para carga e
 outro para classificação (Consultas, cálculos, classificações).


Eu não tomaria a decisão de separar em 2 servidores sem mais informações.  O
procedimento será realizado todos os dias ou será em todo o fim de mês que
os dados serão processados?

E o arquivo de configuração do postgresql.conf como está? Foi realizada
alguma configuração nele?


 Abraços,

 Eder Sousa



 On Tue, 29 Dec 2009 13:56:58 -0200, JotaComm jota.c...@gmail.com wrote:
  Olá,
 
  2009/12/29 lis...@softpira.com
 
 
  Tenho um sistema de Distribuição onde 99% das atividades é inclusão
  de
  registros que por sua vez está incluido em um database, surgiu a
  necessidade de implantar um novo database onde será efetuado a carga de
  dados diárias com aproximadamente 50.000 registros dias, porém neste
  database será classificado N calculo para administrar o estoque de 55
  filiais.
 
 
  O que você considera um novo database. É um novo banco de dados
 separado?
  Ou
  um novo esquema dentro do banco de dados atual?
 
  A carga será em massa, isto é, em determinado horário serão inseridos
  50 mil
  registros ou isso será feito durante o dia todo?
 
  Não entendi a última parte: Neste database será classificado N
 cálculo
  para
  administrar...
 
 
 
 
  Até a carga de dados funciona maravilhosamente, porém quando inicia a
  execução das classificações o desempenho do servidor cai
  drasticamente.
  Pergunto: Neste caso é necessário um novo servidor para executar os
  cálculos, ao invés de efetuar no mesmo servidor??
 
 
  Esta classificação é realizada a todo o momento ou em horários
  específicos?
 
  Como está a configuração do postgresql.conf?
 
 
  Só para conhecimento o servidor é um Quadcore com 8GB RAM e 1 Tera de
  HD
 
  []s
 
  Eder Sousa
  ___
  pgbr-geral mailing list
  pgbr-geral@listas.postgresql.org.br
  https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
 
 
 
  []s
 ___
 pgbr-geral mailing list
 pgbr-geral@listas.postgresql.org.br
 https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral



[]s
-- 
JotaComm
http://jotacomm.wordpress.com
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Qual estrutura utilizar?

2009-12-29 Por tôpico Shairon Toledo

Já pensou em desenhar essa solução usando trigger de inserção?
Para cada nova venda vc atualiza as tabelas de estatísticas, com isso vc
pode listar os dados das tabela evitando demasiados joins e ainda ganha em
saber o desempenho de cada vendedor/filial diariamente(ou até por minuto).
Quando eu trabalhava com voip(~150K registro/ligações) essa foi a solução,
mas cada caso é um caso.



2009/12/29 JotaComm jota.c...@gmail.com

 Olá,

 2009/12/29 lis...@softpira.com


 Graaande JP tudo bem???

 Vamos por partes...

 Um novo database para mim:

 1.) O mesmo servidor possuindo dois BANCO DE DADOS:

EXEMPLO:

CREATE DATABASE producao
  WITH OWNER = postgres
   ENCODING = 'UTF8'
   CONNECTION LIMIT = -1;
ALTER DATABASE producao SET work_mem=100MB;

CREATE DATABASE producao2
  WITH OWNER = postgres
   ENCODING = 'UTF8'
   CONNECTION LIMIT = -1;
ALTER DATABASE producao SET work_mem=100MB;


 Acho que pode ser um novo esquema e não necessariamente um novo banco de
 dados, pois se você tiver que comunicar os dois bancos você terá que usar um
 dblink, enquanto que se você usar esquemas um simples JOIN especificando o
 esquema resolve o problema.

 Uma pergunta. Vocês já fizeram um medição para definição do work_mem com
 100MB? Sem uma noção dos processos (consultas) e vendo de longe me parece um
 valor bem alto.


 2.) Sim a carga de 50.000 registros será em massa (no caso acima será no
 producao2) porém no producao está a todo o momento incluindo
 informações, em torno de 7.000 registros que neste caso não estarei
 usando em cálculos.


 Beleza.


 3.) A Classificação que mencionei, são cálculos de vendas nos últimos
 3 meses (aproximadamente 4.500.000 registros), 30 dias (aproximadamente
 1.500.000 registros), 13800 produtos, das 55 filiais (solicitação de
 amigos consultores..r).

 4.) O postgresql é a versão 8.3.5 e a segundo a ultima consultoria (neste
 caso do Banco de Dados) nos informaram o ideal é separar estas ações em
 servidores diferentes pq temos dois bancos distintos, um para carga e
 outro para classificação (Consultas, cálculos, classificações).


 Eu não tomaria a decisão de separar em 2 servidores sem mais informações.
  O procedimento será realizado todos os dias ou será em todo o fim de mês
 que os dados serão processados?

 E o arquivo de configuração do postgresql.conf como está? Foi realizada
 alguma configuração nele?


 Abraços,

 Eder Sousa



 On Tue, 29 Dec 2009 13:56:58 -0200, JotaComm jota.c...@gmail.com wrote:
  Olá,
 
  2009/12/29 lis...@softpira.com
 
 
  Tenho um sistema de Distribuição onde 99% das atividades é inclusão
  de
  registros que por sua vez está incluido em um database, surgiu a
  necessidade de implantar um novo database onde será efetuado a carga de
  dados diárias com aproximadamente 50.000 registros dias, porém neste
  database será classificado N calculo para administrar o estoque de 55
  filiais.
 
 
  O que você considera um novo database. É um novo banco de dados
 separado?
  Ou
  um novo esquema dentro do banco de dados atual?
 
  A carga será em massa, isto é, em determinado horário serão inseridos
  50 mil
  registros ou isso será feito durante o dia todo?
 
  Não entendi a última parte: Neste database será classificado N
 cálculo
  para
  administrar...
 
 
 
 
  Até a carga de dados funciona maravilhosamente, porém quando inicia a
  execução das classificações o desempenho do servidor cai
  drasticamente.
  Pergunto: Neste caso é necessário um novo servidor para executar os
  cálculos, ao invés de efetuar no mesmo servidor??
 
 
  Esta classificação é realizada a todo o momento ou em horários
  específicos?
 
  Como está a configuração do postgresql.conf?
 
 
  Só para conhecimento o servidor é um Quadcore com 8GB RAM e 1 Tera de
  HD
 
  []s
 
  Eder Sousa
  ___
  pgbr-geral mailing list
  pgbr-geral@listas.postgresql.org.br
  https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
 
 
 
  []s
 ___
 pgbr-geral mailing list
 pgbr-geral@listas.postgresql.org.br
 https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral



 []s
 --
 JotaComm
 http://jotacomm.wordpress.com

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




-- 
[ ]'s
Shairon Toledo
http://www.google.com/profiles/shairon.toledo
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Qual estrutura utilizar?

2009/12/29 Shairon Toledo shairon.tol...@gmail.com:
 Já pensou em desenhar essa solução usando trigger de inserção?

Ou visões materializadas.


-- 
skype:leandro.gfc.dutra?chat  Yahoo!: ymsgr:sendIM?lgcdutra
+55 (11) 3854 7191  gTalk: xmpp:leand...@jabber.org
+55 (11) 9406 7191ICQ/AIM: aim:GoIM?screenname=61287803
BRAZIL GMT-3  MSN: msnim:chat?contact=lean...@dutra.fastmail.fm
Sent from Sao Paulo, SP, Brazil
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Qual estrutura utilizar?


Shairon.. 

neste caso estou precisando de inforamções dos produtos... não pensei
neste caso... vou tentar para ver como fica.. abraços!!!

On Tue, 29 Dec 2009 13:02:53 -0500, Shairon Toledo
shairon.tol...@gmail.com wrote:
 Já pensou em desenhar essa solução usando trigger de inserção?
 Para cada nova venda vc atualiza as tabelas de estatísticas, com isso vc
 pode listar os dados das tabela evitando demasiados joins e ainda ganha
em
 saber o desempenho de cada vendedor/filial diariamente(ou até por
minuto).
 Quando eu trabalhava com voip(~150K registro/ligações) essa foi a
 solução,
 mas cada caso é um caso.
 
 
 
 2009/12/29 JotaComm jota.c...@gmail.com
 
 Olá,

 2009/12/29 lis...@softpira.com


 Graaande JP tudo bem???

 Vamos por partes...

 Um novo database para mim:

 1.) O mesmo servidor possuindo dois BANCO DE DADOS:

EXEMPLO:

CREATE DATABASE producao
  WITH OWNER = postgres
   ENCODING = 'UTF8'
   CONNECTION LIMIT = -1;
ALTER DATABASE producao SET work_mem=100MB;

CREATE DATABASE producao2
  WITH OWNER = postgres
   ENCODING = 'UTF8'
   CONNECTION LIMIT = -1;
ALTER DATABASE producao SET work_mem=100MB;


 Acho que pode ser um novo esquema e não necessariamente um novo banco
 de
 dados, pois se você tiver que comunicar os dois bancos você terá que
 usar um
 dblink, enquanto que se você usar esquemas um simples JOIN
especificando
 o
 esquema resolve o problema.

 Uma pergunta. Vocês já fizeram um medição para definição do
 work_mem com
 100MB? Sem uma noção dos processos (consultas) e vendo de longe me
 parece um
 valor bem alto.


 2.) Sim a carga de 50.000 registros será em massa (no caso acima será
 no
 producao2) porém no producao está a todo o momento incluindo
 informações, em torno de 7.000 registros que neste caso não estarei
 usando em cálculos.


 Beleza.


 3.) A Classificação que mencionei, são cálculos de vendas nos
 últimos
 3 meses (aproximadamente 4.500.000 registros), 30 dias (aproximadamente
 1.500.000 registros), 13800 produtos, das 55 filiais (solicitação de
 amigos consultores..r).

 4.) O postgresql é a versão 8.3.5 e a segundo a ultima consultoria
 (neste
 caso do Banco de Dados) nos informaram o ideal é separar estas ações
 em
 servidores diferentes pq temos dois bancos distintos, um para carga e
 outro para classificação (Consultas, cálculos, classificações).


 Eu não tomaria a decisão de separar em 2 servidores sem mais
 informações.
  O procedimento será realizado todos os dias ou será em todo o fim de
  mês
 que os dados serão processados?

 E o arquivo de configuração do postgresql.conf como está? Foi
 realizada
 alguma configuração nele?


 Abraços,

 Eder Sousa



 On Tue, 29 Dec 2009 13:56:58 -0200, JotaComm jota.c...@gmail.com
 wrote:
  Olá,
 
  2009/12/29 lis...@softpira.com
 
 
  Tenho um sistema de Distribuição onde 99% das atividades é
  inclusão
  de
  registros que por sua vez está incluido em um database, surgiu a
  necessidade de implantar um novo database onde será efetuado a
carga
  de
  dados diárias com aproximadamente 50.000 registros dias, porém
  neste
  database será classificado N calculo para administrar o estoque de
  55
  filiais.
 
 
  O que você considera um novo database. É um novo banco de dados
 separado?
  Ou
  um novo esquema dentro do banco de dados atual?
 
  A carga será em massa, isto é, em determinado horário serão
  inseridos
  50 mil
  registros ou isso será feito durante o dia todo?
 
  Não entendi a última parte: Neste database será classificado N
 cálculo
  para
  administrar...
 
 
 
 
  Até a carga de dados funciona maravilhosamente, porém quando
inicia
  a
  execução das classificações o desempenho do servidor cai
  drasticamente.
  Pergunto: Neste caso é necessário um novo servidor para executar
os
  cálculos, ao invés de efetuar no mesmo servidor??
 
 
  Esta classificação é realizada a todo o momento ou em horários
  específicos?
 
  Como está a configuração do postgresql.conf?
 
 
  Só para conhecimento o servidor é um Quadcore com 8GB RAM e 1 Tera
  de
  HD
 
  []s
 
  Eder Sousa
  ___
  pgbr-geral mailing list
  pgbr-geral@listas.postgresql.org.br
  https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
 
 
 
  []s
 ___
 pgbr-geral mailing list
 pgbr-geral@listas.postgresql.org.br
 https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral



 []s
 --
 JotaComm
 http://jotacomm.wordpress.com

 ___
 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] Qual estrutura utilizar?


On Tue, 29 Dec 2009 16:39:07 -0200, Leandro DUTRA
leandro.gfc.du...@gmail.com wrote:
 2009/12/29 Shairon Toledo shairon.tol...@gmail.com:
 Já pensou em desenhar essa solução usando trigger de inserção?
 
 Ou visões materializadas.

Isto eu já pensei ... rss
Mas não foi muito bom o desempenho... 
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Qual estrutura utilizar?

2009-12-29 Por tôpico Marcal Hokama

Opa,

 To: pgbr-geral@listas.postgresql.org.br
 Date: Tue, 29 Dec 2009 14:09:49 -0200
 From: lis...@softpira.com
 Subject: Re: [pgbr-geral] Qual estrutura utilizar?

 Graaande JP tudo bem???

 Vamos por partes...

 Um novo database para mim:

 1.) O mesmo servidor possuindo dois BANCO DE DADOS:

 EXEMPLO:

 CREATE DATABASE producao
 WITH OWNER = postgres
 ENCODING = 'UTF8'
 CONNECTION LIMIT = -1;
 ALTER DATABASE producao SET work_mem=100MB;

 CREATE DATABASE producao2
 WITH OWNER = postgres
 ENCODING = 'UTF8'
 CONNECTION LIMIT = -1;
 ALTER DATABASE producao SET work_mem=100MB;

 2.) Sim a carga de 50.000 registros será em massa (no caso acima será no
 producao2) porém no producao está a todo o momento incluindo
 informações, em torno de 7.000 registros que neste caso não estarei
 usando em cálculos.

 3.) A Classificação que mencionei, são cálculos de vendas nos últimos
 3 meses (aproximadamente 4.500.000 registros), 30 dias (aproximadamente
 1.500.000 registros), 13800 produtos, das 55 filiais (solicitação de
 amigos consultores..r).

Pelo que foi mencionado no item 3, com o volume de dados envolvido, não há 
dúvidas de que vai ser necessário um modelo diferenciado do modelo transacional 
atual para armazenar os dados consolidados. O que vai impactar aqui é a 
periodicidade em que esses dados consolidados devem ser atualizados (por 
exemplo: mensal, diário ou tempo real), pois aí as rotinas de consolidação 
deverão ser executadas mais vezes e aí vai o poder de processamento. Se houver 
uma expectativa de aumento de demanda de dados consolidados, pode ser 
interessante partir para um datamart e para um modelo dimensional.

Marçal de Lima Hokama
- 
_
Faça transações bancárias de maneira segura. Baixe agora o Novo Internet 
Explorer 8.
http://brasil.microsoft.com.br/IE8/mergulhe/?utm_source=MSN%3BHotmailutm_medium=Taglineutm_content=Tag2utm_campaign=IE8
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Qual estrutura utilizar?

2009/12/29  lis...@softpira.com:
 On Tue, 29 Dec 2009 16:39:07 -0200, Leandro DUTRA
 leandro.gfc.du...@gmail.com wrote:
 Ou visões materializadas.

 Mas não foi muito bom o desempenho...

Nenhuma idéia se aplica a todas as situações…


-- 
skype:leandro.gfc.dutra?chat  Yahoo!: ymsgr:sendIM?lgcdutra
+55 (11) 3854 7191  gTalk: xmpp:leand...@jabber.org
+55 (11) 9406 7191ICQ/AIM: aim:GoIM?screenname=61287803
BRAZIL GMT-3  MSN: msnim:chat?contact=lean...@dutra.fastmail.fm
Sent from Sao Paulo, SP, Brazil
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Qual estrutura utilizar?

2009/12/29 Marcal Hokama mhok...@hotmail.com:

 com o volume de dados envolvido, não há dúvidas de que vai ser necessário um 
 modelo diferenciado do modelo transacional

Não necessariamente… não sabemos o suficiente sobre complexidade dos
cálculos, como serão executados, como serão consultados os resultados…
se esses volumes serão gerados ou apenas usados… se o gargalo é
processamento ou E/S (geralmente é E/S)…

Outra coisa, muito que geralmente se considera como ‘modelo
diferenciado do transacional’ pode ser implantado com extensões deste
último, como visões materializadas, gatilhos c.

Datamart e modelo dimensional (como, aliás, prefixos de nomes de
objetos, chaves artificiais, desnormalização c) amiúde são as
respostas certas para as questões erradas — ou respostas em buscas de
questões.


-- 
skype:leandro.gfc.dutra?chat  Yahoo!: ymsgr:sendIM?lgcdutra
+55 (11) 3854 7191  gTalk: xmpp:leand...@jabber.org
+55 (11) 9406 7191ICQ/AIM: aim:GoIM?screenname=61287803
BRAZIL GMT-3  MSN: msnim:chat?contact=lean...@dutra.fastmail.fm
Sent from Sao Paulo, SP, Brazil
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Qual estrutura utilizar?

2009-12-29 Por tôpico JotaComm

Olá,

2009/12/29 lis...@softpira.com


 Shairon..

 neste caso estou precisando de inforamções dos produtos... não pensei
 neste caso... vou tentar para ver como fica.. abraços!!!


Mas agora fiquei na dúvida. A sua carga será feita em massa, isto é, em lote
ou pode ser a cada inserção? Comento isso porque são duas coisas distintas,
uma é mais transacional (inserção via trigger) e a outra não, fica mais
caracterizada para o lado de um data mart e datawarehouse.


 On Tue, 29 Dec 2009 13:02:53 -0500, Shairon Toledo
 shairon.tol...@gmail.com wrote:
  Já pensou em desenhar essa solução usando trigger de inserção?
  Para cada nova venda vc atualiza as tabelas de estatísticas, com isso vc
  pode listar os dados das tabela evitando demasiados joins e ainda ganha
 em
  saber o desempenho de cada vendedor/filial diariamente(ou até por
 minuto).
  Quando eu trabalhava com voip(~150K registro/ligações) essa foi a
  solução,
  mas cada caso é um caso.
 
 
 
  2009/12/29 JotaComm jota.c...@gmail.com
 
  Olá,
 
  2009/12/29 lis...@softpira.com
 
 
  Graaande JP tudo bem???
 
  Vamos por partes...
 
  Um novo database para mim:
 
  1.) O mesmo servidor possuindo dois BANCO DE DADOS:
 
 EXEMPLO:
 
 CREATE DATABASE producao
   WITH OWNER = postgres
ENCODING = 'UTF8'
CONNECTION LIMIT = -1;
 ALTER DATABASE producao SET work_mem=100MB;
 
 CREATE DATABASE producao2
   WITH OWNER = postgres
ENCODING = 'UTF8'
CONNECTION LIMIT = -1;
 ALTER DATABASE producao SET work_mem=100MB;
 
 
  Acho que pode ser um novo esquema e não necessariamente um novo banco
  de
  dados, pois se você tiver que comunicar os dois bancos você terá que
  usar um
  dblink, enquanto que se você usar esquemas um simples JOIN
 especificando
  o
  esquema resolve o problema.
 
  Uma pergunta. Vocês já fizeram um medição para definição do
  work_mem com
  100MB? Sem uma noção dos processos (consultas) e vendo de longe me
  parece um
  valor bem alto.
 
 
  2.) Sim a carga de 50.000 registros será em massa (no caso acima será
  no
  producao2) porém no producao está a todo o momento incluindo
  informações, em torno de 7.000 registros que neste caso não estarei
  usando em cálculos.
 
 
  Beleza.
 
 
  3.) A Classificação que mencionei, são cálculos de vendas nos
  últimos
  3 meses (aproximadamente 4.500.000 registros), 30 dias (aproximadamente
  1.500.000 registros), 13800 produtos, das 55 filiais (solicitação de
  amigos consultores..r).
 
  4.) O postgresql é a versão 8.3.5 e a segundo a ultima consultoria
  (neste
  caso do Banco de Dados) nos informaram o ideal é separar estas ações
  em
  servidores diferentes pq temos dois bancos distintos, um para carga e
  outro para classificação (Consultas, cálculos, classificações).
 
 
  Eu não tomaria a decisão de separar em 2 servidores sem mais
  informações.
   O procedimento será realizado todos os dias ou será em todo o fim de
   mês
  que os dados serão processados?
 
  E o arquivo de configuração do postgresql.conf como está? Foi
  realizada
  alguma configuração nele?
 
 
  Abraços,
 
  Eder Sousa
 
 
 
  On Tue, 29 Dec 2009 13:56:58 -0200, JotaComm jota.c...@gmail.com
  wrote:
   Olá,
  
   2009/12/29 lis...@softpira.com
  
  
   Tenho um sistema de Distribuição onde 99% das atividades é
   inclusão
   de
   registros que por sua vez está incluido em um database, surgiu a
   necessidade de implantar um novo database onde será efetuado a
 carga
   de
   dados diárias com aproximadamente 50.000 registros dias, porém
   neste
   database será classificado N calculo para administrar o estoque de
   55
   filiais.
  
  
   O que você considera um novo database. É um novo banco de dados
  separado?
   Ou
   um novo esquema dentro do banco de dados atual?
  
   A carga será em massa, isto é, em determinado horário serão
   inseridos
   50 mil
   registros ou isso será feito durante o dia todo?
  
   Não entendi a última parte: Neste database será classificado N
  cálculo
   para
   administrar...
  
  
  
  
   Até a carga de dados funciona maravilhosamente, porém quando
 inicia
   a
   execução das classificações o desempenho do servidor cai
   drasticamente.
   Pergunto: Neste caso é necessário um novo servidor para executar
 os
   cálculos, ao invés de efetuar no mesmo servidor??
  
  
   Esta classificação é realizada a todo o momento ou em horários
   específicos?
  
   Como está a configuração do postgresql.conf?
  
  
   Só para conhecimento o servidor é um Quadcore com 8GB RAM e 1 Tera
   de
   HD
  
   []s
  
   Eder Sousa
   ___
   pgbr-geral mailing list
   pgbr-geral@listas.postgresql.org.br
  
 https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
  
  
  
   []s
  ___
  pgbr-geral mailing list
  pgbr-geral@listas.postgresql.org.br
  https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
 
 
 
  []s

Re: [pgbr-geral] Qual estrutura utilizar?