subject:"\[pgbr\-geral\] Modelando um Controle de Estoque"



No caso por exemplo numa tabela endereço qual seria um chave natural?

poderia ser um cep por exemplo

e como modelar isto na tabela? este campo seria um campo normal
conigurado para not null?

seria uma primary key , que é a mesma coisa que um campo unique not null.

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

Re: [pgbr-geral] Modelando um Controle de Estoque

2008/7/15  [EMAIL PROTECTED]:
 No caso por exemplo numa tabela endereço qual seria um chave natural?

O que basta para tornar um endereço único?  Dependendo da modelagem,
pode ser até todos os atributos -- exceto seqüenciais, claro.


 e como modelar isto na tabela? este campo seria um campo normal
 conigurado para not null?

Um conjunto de atributos constituindo uma chave primária ou
alternativa (UNIQUE KEY).


-- 
skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra
+55 (11) 3040 7300 r155 gTalk: xmpp:[EMAIL PROTECTED]
+55 (11) 9406 7191 ICQ/AIM: aim:GoIM?screenname=61287803
+55 (11) 5685 2219 MSN: msnim:[EMAIL PROTECTED]
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Modelando um Controle de Estoque

2008/7/15 joao.junior [EMAIL PROTECTED]:
No caso por exemplo numa tabela endereço qual seria um chave natural?

 poderia ser um cep por exemplo

Só se for uma tabela de endereços de 'grandes assinantes' brasileiros,
não?  Fora isso, há muitos endereços num único CEP.


e como modelar isto na tabela? este campo seria um campo normal
conigurado para not null?

 seria uma primary key , que é a mesma coisa que um campo unique not null.

Quase a mesma coisa: pode haver apenas uma chave primária, mas várias
alternativas.


-- 
skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra
+55 (11) 3040 7300 r155 gTalk: xmpp:[EMAIL PROTECTED]
+55 (11) 9406 7191 ICQ/AIM: aim:GoIM?screenname=61287803
+55 (11) 5685 2219 MSN: msnim:[EMAIL PROTECTED]
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Modelando um Controle de Estoque


- Original Message - 
From: Leandro DUTRA [EMAIL PROTECTED]

Um conjunto de atributos constituindo uma chave primária ou alternativa 
(UNIQUE KEY).

Só com constraint unique você não garante que os campos não recebam nulo.



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

Re: [pgbr-geral] Modelando um Controle de Estoque

2008/7/15 joao.junior [EMAIL PROTECTED]:
 From: Leandro DUTRA [EMAIL PROTECTED]

Um conjunto de atributos constituindo uma chave primária ou alternativa
(UNIQUE KEY).

 Só com constraint unique você não garante que os campos não recebam nulo.

Correto.


-- 
skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra
+55 (11) 3040 7300 r155 gTalk: xmpp:[EMAIL PROTECTED]
+55 (11) 9406 7191 ICQ/AIM: aim:GoIM?screenname=61287803
+55 (11) 5685 2219 MSN: msnim:[EMAIL PROTECTED]
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Modelando um Controle de Estoque

2008/7/15 joao.junior [EMAIL PROTECTED]:
 Leandro meu jovem, poderia mandar alguns textos interessantes sobre
 modelagem..?

Então, tem pouca coisa enviável... é um campo onde as pessoas vivem do
que publicam, basicamente.

Já creio que passei algumas coisas, mas, tirando compra de livros, é
um exercício de paciência e persistência de ler várias coisas picadas
e ir juntando tudo.  No final das contas, creio que pelo menos o
investimento no _Introduction to Database Systems_ do Christopher J
DATE é essencial.

http://dmoz.org./Computers/Software/Databases/Relational
http://thethirdmanifesto.com/
http://dbdebunk.com/

Quanto a livros, qualquer coisa do Date, do Darwen, do McGoveran, do Codd...

-- 
skype:leandro.gfc.dutra?chat  Yahoo!: ymsgr:sendIM?lgcdutra
+55 (11) 3040 7300 r155 gTalk: xmpp:[EMAIL PROTECTED]
+55 (11) 9406 7191ICQ/AIM: aim:GoIM?screenname=61287803
+55 (11) 5685 2219MSN: msnim:[EMAIL PROTECTED]
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Modelando um Controle de Estoque

comprei um livro seriamente devolvi!!!

do Watson Data managment Horrivel

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

Re: [pgbr-geral] Modelando um Controle de Estoque

2008/7/15 joao.junior [EMAIL PROTECTED]:
 comprei um livro seriamente devolvi!!!
 do Watson Data managment Horrivel

Sério?  O que era tão ruim assim?


-- 
skype:leandro.gfc.dutra?chat  Yahoo!: ymsgr:sendIM?lgcdutra
+55 (11) 3040 7300 r155 gTalk: xmpp:[EMAIL PROTECTED]
+55 (11) 9406 7191ICQ/AIM: aim:GoIM?screenname=61287803
+55 (11) 5685 2219MSN: msnim:[EMAIL PROTECTED]
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Modelando um Controle de Estoque

Leandro, a primeira vista me pareceu um livro voltado para AD mesmo, uma 
rápida foleada e achei que tinha encontrado a menina dos olhos.

Mas ... o cabra não explica conceito algum , exemplos superficiais voltados 
mais a prática mesmo e o conceito pro beleléu!!

EX: relacionamento 1xm coloca-se o código da tabela do lado 1 para o lado 
N... Acho que para AD tudo parte do conceito!!!

Sinceramente achei o Paulo Cougos muito melhor conceitualmente

- Original Message - 
From: Leandro DUTRA [EMAIL PROTECTED]
To: Comunidade PostgreSQL Brasileira pgbr-geral@listas.postgresql.org.br
Sent: Tuesday, July 15, 2008 11:25 AM
Subject: Re: [pgbr-geral] Modelando um Controle de Estoque


2008/7/15 joao.junior [EMAIL PROTECTED]:
 comprei um livro seriamente devolvi!!!
 do Watson Data managment Horrivel

Sério?  O que era tão ruim assim?


-- 
skype:leandro.gfc.dutra?chat  Yahoo!: ymsgr:sendIM?lgcdutra
+55 (11) 3040 7300 r155 gTalk: xmpp:[EMAIL PROTECTED]
+55 (11) 9406 7191ICQ/AIM: aim:GoIM?screenname=61287803
+55 (11) 5685 2219MSN: msnim:[EMAIL PROTECTED]
___
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] Modelando um Controle de Estoque

2008-07-14 Por tôpico Alexsandro Haag

Não teria como, pois a proposta até o momento é utilizar estes campos 
como chave primária das tabelas pessoa física e jurídica. Sendo assim 
não poderia ser nulo.


Att.
Alexandro Haag

Adriano Sanches Tonetto escreveu:


Você pode deixar a coluna aceitando nulo !
--
Adriano Sanches Tonetto
astoneto (at) gmail (dot) com

Antes de imprimir, lembre-se da sua responsabilidade como planeta !

[EMAIL PROTECTED] escreveu:

Outro problema para o CNPJ ser a chave natural. E se quisermos ter cliente
cadastrado sem CNPJ ou CPF, ou seja, poderão ser futuros clientes, com
cadastro incompleto, estão cadastrados para mailing, mala-direta ou qualquer
outra atividade de marketing.

No meu caso eu procuro sempre generalizar as coisas.


Alecindro

Quoting Ribamar Sousa [EMAIL PROTECTED]:

  

2008/7/11 Leandro DUTRA [EMAIL PROTECTED]:



2008/7/11 Ribamar Sousa [EMAIL PROTECTED]:
  

Mesmo sem ser o Leandro vou arriscar um palpite: em separando bem as


coisas,
  

física, jurídica, pública e privada, acredito que se deva usar nossos


CPF
  

e CNPJ.


Desde que não entrem nem estrangeiros (não têm CNP[FJ]), nem crianças
nem mulheres casadas sem vida econômica (não têm CNPF), concordo.


Acredito que se tem que chegar a um acordo sobre as restrições de
abrangência, pois se não restringirmos a abrangência a coisa ficará muito
difícil de implementar, correto?

  


--
skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra
+55 (11) 3040 7300 r155 gTalk: 
xmpp:[EMAIL PROTECTED][EMAIL PROTECTED]

+55 (11) 9406 7191 ICQ/AIM: aim:GoIM?screenname=61287803
+55 (11) 5685 2219 MSN: msnim:[EMAIL PROTECTED]
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

  

--
Ribamar FS - [EMAIL PROTECTED]
http://ribafs.net






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

  




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

Re: [pgbr-geral] Modelando um Controle de Estoque

2008-07-14 Por tôpico Ribamar Sousa

2008/7/13 Leandro DUTRA [EMAIL PROTECTED]:

  Mas também acho que já conquistamos nosso espaço e já podemos tentar
 deixar
  os padrões de lado (pelo menos em boa parte) e trilhar algo mais
 saudável.

 Hm, não é viável.

 São duas coisas diferentes.  Por um lado é bom que haja um SGBD SQL
 conforme e livre, como alternativa aos proprietários, forçando-os à
 conformidade e à liberdade, uma vez que não se prevê o abandono do ISO
 SQL a não ser a longo prazo.


Será?
Talvez sim, apenas no sentido de que não podemos trabalhar em dois projetos:
um para manter o PostgreSQL em cima do SQL e outro para ter um PostgreSQL em
cima de algo mais algo (nem sei o que) .


 Por outro, é bom que se desenvolva uma D ou algo assim, mas é difícil
 pensar que isso se dê como um desenvolvimento ou migração duma
 ferramenta ISO SQL.


Coerente.


 O melhor que consigo imaginar para facilitar essa migração é o caminho
 do Dataphor: um SGBDR D virtual, usando SGBDs SQL como mecanismo de
 armazenamento até que se possa desenvolver algo próprio e melhor.


Mas imaginar o PostgreSQL trilhando por aí é dar uma volta quase completa.
Não se percebe nenhuma sinalização nesse sentido, ou sim?

Vou ver se consigo instalar num XP no VirtualBox (Ubuntu) aqui, pois no XP
que tenho instalado em outra partição não consegui (ele não consegue iniciar
o serviço).

-- 
Ribamar FS - [EMAIL PROTECTED]
http://ribafs.net
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Modelando um Controle de Estoque

2008-07-14 Por tôpico Leandro DUTRA

2008/7/14 Ribamar Sousa [EMAIL PROTECTED]:
 Será?

Uma vez propus uma linguagem D para o PostgreSQL na -hackers, digamos
que eu não tive como dar seguimento à proposta.  Claro que
principalmente por falta de conhecimento técnico, mas os argumentos de
que isso implicaria em refazer partes importantes do sistema foram bem
convincentes.


 Talvez sim, apenas no sentido de que não podemos trabalhar em dois projetos:
 um para manter o PostgreSQL em cima do SQL e outro para ter um PostgreSQL em
 cima de algo mais algo (nem sei o que) .

Aliás não seria mais um PostgreSQL, mas um PostgresR, PostgresD ou
simplesmente Postgres -- que aliás já voltou a ser nome aceito.


 Mas imaginar o PostgreSQL trilhando por aí é dar uma volta quase completa.
 Não se percebe nenhuma sinalização nesse sentido, ou sim?

Eu não consigo.

Por outro lado, havendo um porte do Dataphor ao PostgreSQL (o que não
é trivial), poder-se-ia pensar em usar, mais tarde, partes do
mecanismo do PostgreSQL numa segunda geração do Dataphor que tenha
armazenamento nativo.  Se não me engano o povo da Alphora chegou a
pensar nisso.


-- 
skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra
+55 (11) 3040 7300 r155 gTalk: xmpp:[EMAIL PROTECTED]
+55 (11) 9406 7191 ICQ/AIM: aim:GoIM?screenname=61287803
+55 (11) 5685 2219 MSN: msnim:[EMAIL PROTECTED]
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Modelando um Controle de Estoque

2008-07-13 Por tôpico Adriano Sanches Tonetto






Voc pode deixar a coluna aceitando nulo !
-- 
Adriano Sanches Tonetto
astoneto (at) gmail (dot) com

Antes de imprimir, lembre-se da sua responsabilidade como planeta !

[EMAIL PROTECTED] escreveu:

  Outro problema para o CNPJ ser a chave natural. E se quisermos ter cliente
cadastrado sem CNPJ ou CPF, ou seja, podero ser futuros clientes, com
cadastro incompleto, esto cadastrados para mailing, mala-direta ou qualquer
outra atividade de marketing.

No meu caso eu procuro sempre generalizar as coisas.


Alecindro

Quoting Ribamar Sousa [EMAIL PROTECTED]:

  
  
2008/7/11 Leandro DUTRA [EMAIL PROTECTED]:



  2008/7/11 Ribamar Sousa [EMAIL PROTECTED]:
  
  
Mesmo sem ser o Leandro vou arriscar um palpite: em separando bem as

  
  coisas,
  
  
fsica, jurdica, pblica e privada, acredito que se "deva" usar nossos

  
  CPF
  
  
e CNPJ.

  
  Desde que no entrem nem estrangeiros (no tm CNP[FJ]), nem crianas
nem mulheres casadas sem vida econmica (no tm CNPF), concordo.


Acredito que se tem que chegar a um acordo sobre as restries de
abrangncia, pois se no restringirmos a abrangncia a coisa ficar muito
difcil de implementar, correto?

  




  
--
skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra
+55 (11) 3040 7300 r155 gTalk: 
xmpp:[EMAIL PROTECTED][EMAIL PROTECTED]
+55 (11) 9406 7191 ICQ/AIM: aim:GoIM?screenname=61287803
+55 (11) 5685 2219 MSN: msnim:[EMAIL PROTECTED]
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

  



--
Ribamar FS - [EMAIL PROTECTED]
http://ribafs.net


  
  


___
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] Modelando um Controle de Estoque

2008/7/13 Adriano Sanches Tonetto [EMAIL PROTECTED]:


 Você pode deixar a coluna aceitando nulo !

 Tens razão. Atualizei o script e o diagrama, colocando cnpj como um campo
comun mas deixei como not null.
Realmente, deve ser um campo secundário e aceitando null para quando não se
tiver cnpj, ou cpf.

 --
 Adriano Sanches Tonetto
 astoneto (at) gmail (dot) com

 Antes de imprimir, lembre-se da sua responsabilidade como planeta !


 [EMAIL PROTECTED] escreveu:

 Outro problema para o CNPJ ser a chave natural. E se quisermos ter cliente
 cadastrado sem CNPJ ou CPF, ou seja, poderão ser futuros clientes, com
 cadastro incompleto, estão cadastrados para mailing, mala-direta ou qualquer
 outra atividade de marketing.

 No meu caso eu procuro sempre generalizar as coisas.


 Alecindro

 Quoting Ribamar Sousa [EMAIL PROTECTED] [EMAIL PROTECTED]:



  2008/7/11 Leandro DUTRA [EMAIL PROTECTED] [EMAIL PROTECTED]:



  2008/7/11 Ribamar Sousa [EMAIL PROTECTED] [EMAIL PROTECTED]:


  Mesmo sem ser o Leandro vou arriscar um palpite: em separando bem as


  coisas,


  física, jurídica, pública e privada, acredito que se deva usar nossos


  CPF


  e CNPJ.


  Desde que não entrem nem estrangeiros (não têm CNP[FJ]), nem crianças
 nem mulheres casadas sem vida econômica (não têm CNPF), concordo.


 Acredito que se tem que chegar a um acordo sobre as restrições de
 abrangência, pois se não restringirmos a abrangência a coisa ficará muito
 difícil de implementar, correto?



   --skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra
 +55 (11) 3040 7300 r155 gTalk: xmpp:[EMAIL PROTECTED][EMAIL PROTECTED] 
 [EMAIL PROTECTED]
 +55 (11) 9406 7191 ICQ/AIM: aim:GoIM?screenname=61287803
 +55 (11) 5685 2219 MSN: msnim:[EMAIL PROTECTED]
 ___
 pgbr-geral mailing [EMAIL 
 PROTECTED]://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

--
 Ribamar FS - [EMAIL PROTECTED]://ribafs.net

  ___
 pgbr-geral mailing [EMAIL 
 PROTECTED]://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




-- 
Ribamar FS - [EMAIL PROTECTED]
http://ribafs.net
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Modelando um Controle de Estoque

2008-07-13 Por tôpico Leonardo Cezar

2008/7/11 Leandro DUTRA [EMAIL PROTECTED]:

 Ainda não vi um uso interessante e generalizado de TYPEs; de qualquer
 maneira, qualquer TYPE criado fica mais interessante se usado dentro
 de DOMAINs.

 Talvez o Leonardo César tenha alguns exemplos interessantes?

Temos, sob condição de propriedade intelectual em um cliente :-(.

Talvez um tema prum Hacker Talk do PGCon'08 ???

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

Re: [pgbr-geral] Modelando um Controle de Estoque

2008/7/13 Leonardo Cezar [EMAIL PROTECTED]:
 2008/7/11 Leandro DUTRA [EMAIL PROTECTED]:

 Ainda não vi um uso interessante e generalizado de TYPEs; de qualquer
 maneira, qualquer TYPE criado fica mais interessante se usado dentro
 de DOMAINs.

 Talvez um tema prum Hacker Talk do PGCon'08 ???

Boa!

-- 
skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra
+55 (11) 3040 7300 r155 gTalk: xmpp:[EMAIL PROTECTED]
+55 (11) 9406 7191 ICQ/AIM: aim:GoIM?screenname=61287803
+55 (11) 5685 2219 MSN: msnim:[EMAIL PROTECTED]
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Modelando um Controle de Estoque

2008/7/13 Adriano Sanches Tonetto [EMAIL PROTECTED]:

 Você pode deixar a coluna aceitando nulo !

Em princípio, NULLs indicam falta de normalização.


-- 
skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra
+55 (11) 3040 7300 r155 gTalk: xmpp:[EMAIL PROTECTED]
+55 (11) 9406 7191 ICQ/AIM: aim:GoIM?screenname=61287803
+55 (11) 5685 2219 MSN: msnim:[EMAIL PROTECTED]
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Modelando um Controle de Estoque

2008/7/13 Leandro DUTRA [EMAIL PROTECTED]:

 2008/7/13 Adriano Sanches Tonetto [EMAIL PROTECTED]:
 
  Você pode deixar a coluna aceitando nulo !

 Em princípio, NULLs indicam falta de normalização.


Parece que a própria lógica mostra a coerência da teoria, desde que estou
adicionando um campo que não tem importância. Neste caso temos que criar
uma outra tabela e relacionar, correto?
Vou ver com calma isso para tentar colocar no script.



 --
 skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra
 +55 (11) 3040 7300 r155 gTalk: xmpp:[EMAIL PROTECTED][EMAIL PROTECTED]
 +55 (11) 9406 7191 ICQ/AIM: aim:GoIM?screenname=61287803
 +55 (11) 5685 2219 MSN: msnim:[EMAIL PROTECTED]
 ___
 pgbr-geral mailing list
 pgbr-geral@listas.postgresql.org.br
 https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral




-- 
Ribamar FS - [EMAIL PROTECTED]
http://ribafs.net
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Modelando um Controle de Estoque

2008/7/13 Ribamar Sousa [EMAIL PROTECTED]:

 Parece que a própria lógica mostra a coerência da teoria

Bingo!

Teoria *é* lógica!


 desde que estou
 adicionando um campo que não tem importância.

Exato.  Ou seja, denota que na verdade fala-se de duas entidades...


 Neste caso temos que criar
 uma outra tabela e relacionar, correto?

Exato, uma relação ('tabela') para cada entidade.


 Vou ver com calma isso para tentar colocar no script.

Legal.

Isso dito, em SQL pode ser que a normalização total fique
excessivamente complexa, por causa de limitações arbitrárias nas
relações derivadas  (visões, VIEWs) atualizáveis (nível conceitual) e
da falta de independência de dados (nível físico — difícil garantir
desempenho em situações extremas.  Aliás o Date está nos devendo o tal
modelo transrelacional).  Mas seria a única maneira de fazer um modelo
verdadeiramente genérico.


-- 
skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra
+55 (11) 3040 7300 r155 gTalk: xmpp:[EMAIL PROTECTED]
+55 (11) 9406 7191 ICQ/AIM: aim:GoIM?screenname=61287803
+55 (11) 5685 2219 MSN: msnim:[EMAIL PROTECTED]
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Modelando um Controle de Estoque

2008/7/13 Leandro DUTRA [EMAIL PROTECTED]:

 2008/7/13 Ribamar Sousa [EMAIL PROTECTED]:

 Isso dito, em SQL pode ser que a normalização total fique
 excessivamente complexa, por causa de limitações arbitrárias nas
 relações derivadas  (visões, VIEWs) atualizáveis (nível conceitual) e
 da falta de independência de dados (nível físico — difícil garantir
 desempenho em situações extremas.  Aliás o Date está nos devendo o tal
 modelo transrelacional).  Mas seria a única maneira de fazer um modelo
 verdadeiramente genérico.


Por que você acha que não se usa uma outra linguagem que melhor atenda ao
modelo relacional?
Não seria mais indicado uma linguagem mais coerente com o modelo ao invés de
um novo modelo para evitar as limitações da linguagem?
Acho que não é só o fato de ter virado padrão que dá força ao SQL. Acho que
houve e há uma certa acomodação, ou estou enganado?

-- 
Ribamar FS - [EMAIL PROTECTED]
http://ribafs.net
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Modelando um Controle de Estoque

2008/7/13 Ribamar Sousa [EMAIL PROTECTED]:
 Por que você acha que não se usa uma outra linguagem que melhor atenda ao
 modelo relacional?

Sinceramente?  Inércia do mercado.

Há quem discorde, e ache que SQL é o que dá para fazer com a
tecnologia e o desenvolvimento teórico disponíveis hoje.


 Não seria mais indicado uma linguagem mais coerente com o modelo ao invés de
 um novo modelo para evitar as limitações da linguagem?

Sim!  Daí o Terceiro Manifesto, e iniciativas como Dataphor, Rel e vai
por aí afora.


 Acho que não é só o fato de ter virado padrão que dá força ao SQL. Acho que
 houve e há uma certa acomodação, ou estou enganado?

Concordo.

Mesmo fugindo da questão do modelo relacional em si, veja que só o
PostgreSQL tem uma preocupação forte com conformidade a padrões.  O
IBM DB2 tem uma preocupação fraca, e outros concorrentes nenhuma...


-- 
skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra
+55 (11) 3040 7300 r155 gTalk: xmpp:[EMAIL PROTECTED]
+55 (11) 9406 7191 ICQ/AIM: aim:GoIM?screenname=61287803
+55 (11) 5685 2219 MSN: msnim:[EMAIL PROTECTED]
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Modelando um Controle de Estoque

2008/7/13 Leandro DUTRA [EMAIL PROTECTED]:

 2008/7/13 Ribamar Sousa [EMAIL PROTECTED]:
  Por que você acha que não se usa uma outra linguagem que melhor atenda ao
  modelo relacional?


 Mesmo fugindo da questão do modelo relacional em si, veja que só o
 PostgreSQL tem uma preocupação forte com conformidade a padrões.  O
 IBM DB2 tem uma preocupação fraca, e outros concorrentes nenhuma...


Mas talvez eu entenda, embora concorde que chegou o momento de mudar o foco,
pois já crescemos.
Acho que se tento agradar a todos é porque quero conquistar meu espaço,
enquanto que os demais conquistaram seu espaço.
Como também já conquistamos nosso espaço acho que tá na hora de mudar o foco
e trilhar um caminho pessoal.

-- 
Ribamar FS - [EMAIL PROTECTED]
http://ribafs.net
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Modelando um Controle de Estoque

2008/7/13 Ribamar Sousa [EMAIL PROTECTED]:

 Mas talvez eu entenda, embora concorde que chegou o momento de mudar o foco,
 pois já crescemos.
 Acho que se tento agradar a todos é porque quero conquistar meu espaço,
 enquanto que os demais conquistaram seu espaço.
 Como também já conquistamos nosso espaço acho que tá na hora de mudar o foco
 e trilhar um caminho pessoal.

Vixe, estou ficando burro... segunda colocação tua que não entendo, e
duas mensagens seguidas!


-- 
skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra
+55 (11) 3040 7300 r155 gTalk: xmpp:[EMAIL PROTECTED]
+55 (11) 9406 7191 ICQ/AIM: aim:GoIM?screenname=61287803
+55 (11) 5685 2219 MSN: msnim:[EMAIL PROTECTED]
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Modelando um Controle de Estoque

2008/7/13 Leandro DUTRA [EMAIL PROTECTED]:

 2008/7/13 Ribamar Sousa [EMAIL PROTECTED]:
 
  Mas talvez eu entenda, embora concorde que chegou o momento de mudar o
 foco,
  pois já crescemos.
  Acho que se tento agradar a todos é porque quero conquistar meu espaço,
  enquanto que os demais conquistaram seu espaço.
  Como também já conquistamos nosso espaço acho que tá na hora de mudar o
 foco
  e trilhar um caminho pessoal.

 Vixe, estou ficando burro... segunda colocação tua que não entendo, e
 duas mensagens seguidas!

 Ok.
Entendo que o PostgreSQL adotou usar o padrão, para ser compatível com todos
que estão aí.
Mas também acho que já conquistamos nosso espaço e já podemos tentar deixar
os padrões de lado (pelo menos em boa parte) e trilhar algo mais saudável.


 --
 skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra
 +55 (11) 3040 7300 r155 gTalk: xmpp:[EMAIL PROTECTED][EMAIL PROTECTED]
 +55 (11) 9406 7191 ICQ/AIM: aim:GoIM?screenname=61287803
 +55 (11) 5685 2219 MSN: msnim:[EMAIL PROTECTED]
 ___
 pgbr-geral mailing list
 pgbr-geral@listas.postgresql.org.br
 https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral




-- 
Ribamar FS - [EMAIL PROTECTED]
http://ribafs.net
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Modelando um Controle de Estoque

2008-07-13 Por tôpico Leonardo Cezar

2008/7/13 Ribamar Sousa [EMAIL PROTECTED]:

eis que surge um invasor na conversa...

 Entendo que o PostgreSQL adotou usar o padrão, para ser compatível com todos
 que estão aí.

... e pra alcançar o padrão ainda tem caminho pra se andar.

 Mas também acho que já conquistamos nosso espaço e já podemos tentar deixar
 os padrões de lado (pelo menos em boa parte) e trilhar algo mais saudável.

Protocolos (padrões) são saudáveis e devem ser seguidos para evitar a
procria de softcidas.

Vide post no Soli Deo Gloria: Um brasileiro pelegrino, no nosso
planeta,  sobre o assunto.

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

Re: [pgbr-geral] Modelando um Controle de Estoque

2008/7/13 Ribamar Sousa [EMAIL PROTECTED]:
 Entendo que o PostgreSQL adotou usar o padrão, para ser compatível com todos
 que estão aí.

Na verdade parcialmente, porque ninguém mais segue o padrão como nós.


 Mas também acho que já conquistamos nosso espaço e já podemos tentar deixar
 os padrões de lado (pelo menos em boa parte) e trilhar algo mais saudável.

Hm, não é viável.

São duas coisas diferentes.  Por um lado é bom que haja um SGBD SQL
conforme e livre, como alternativa aos proprietários, forçando-os à
conformidade e à liberdade, uma vez que não se prevê o abandono do ISO
SQL a não ser a longo prazo.

Por outro, é bom que se desenvolva uma D ou algo assim, mas é difícil
pensar que isso se dê como um desenvolvimento ou migração duma
ferramenta ISO SQL.

O melhor que consigo imaginar para facilitar essa migração é o caminho
do Dataphor: um SGBDR D virtual, usando SGBDs SQL como mecanismo de
armazenamento até que se possa desenvolver algo próprio e melhor.

-- 
skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra
+55 (11) 3040 7300 r155 gTalk: xmpp:[EMAIL PROTECTED]
+55 (11) 9406 7191 ICQ/AIM: aim:GoIM?screenname=61287803
+55 (11) 5685 2219 MSN: msnim:[EMAIL PROTECTED]
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Modelando um Controle de Estoque

2008-07-12 Por tôpico Ribamar Sousa

2008/7/11 Leandro DUTRA [EMAIL PROTECTED]:

 2008/7/11 Ribamar Sousa [EMAIL PROTECTED]:
  Mesmo sem ser o Leandro vou arriscar um palpite: em separando bem as
 coisas,
  física, jurídica, pública e privada, acredito que se deva usar nossos
 CPF
  e CNPJ.

 Desde que não entrem nem estrangeiros (não têm CNP[FJ]), nem crianças
 nem mulheres casadas sem vida econômica (não têm CNPF), concordo.

 Entendi agora. Áí onde entra a importância da experiência. Imaginei numa
situação real, com um dos citados por você e com certeza podem ocorrer
vários outros, então eu não venderia.
A coisa é mais complexa. Vou escutar mais. :)


 --
 skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra
 +55 (11) 3040 7300 r155 gTalk: xmpp:[EMAIL PROTECTED][EMAIL PROTECTED]
 +55 (11) 9406 7191 ICQ/AIM: aim:GoIM?screenname=61287803
 +55 (11) 5685 2219 MSN: msnim:[EMAIL PROTECTED]
 ___
 pgbr-geral mailing list
 pgbr-geral@listas.postgresql.org.br
 https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral




-- 
Ribamar FS - [EMAIL PROTECTED]
http://ribafs.net
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Modelando um Controle de Estoque

2008-07-12 Por tôpico Guilherme Carvalho

Venho acompanhando esta discussão, que por sinal mostra-se muito
interessante, e por ter se tornado tão interessante acho que ficar apenas na
lista seria um pecado, visto que para acompanhar é mais complicado, gostaria
portanto sugerir que fosse criado algo para que assuntos como estes pudesse
ser melhor discutidos, creio que um blog / wiki seria algo interessante,
visto que assim a organização e o progresso seriam mais proveitosos, é
apenas uma opnião, visto que realmente esta lista é uma comunidade, onde um
assunto que para muitos é básico tornou-se nos últimos tempos o assunto mais
discutido em todas as listas das quais participo.

Porém para não ficar parecendo que o e-mail está fora de contexto, eu
concordo no ponto de vista que usar CPF / CNPJ como chave não seria uma
abordagem digamos das mais indicadas, nas modelagens que faço trabalho na
maioria das vezes com chaves pk do tipo serial.

Atenciosamente
Guilherme de Carvalho Carneiro.



2008/7/11 Ribamar Sousa [EMAIL PROTECTED]:

 2008/7/11 Johnny Taylor Faria Chaves [EMAIL PROTECTED]:

  Basta declarar pessoa, cliente ou fornecedor.  Três tabelas.
 
  Daí pessoa jurídica ou física, mais duas tabelas.

 Há muito estou acompanhando aos pedaços essa discussão (nem vi onde ela
 saiu
 do estoque propriamente dito e entrou nessa de clientes, fornecedores e
 etc..., mas está ótimo).

 Leandro, agora chegou em um ponto que venho matutando desde que vi o
 desvio
 citado acima. Concordo que a solução é como você mostrou acima (pessoas=
 físicas| jurídicas + clientes| fornecedores) e facilita inserir sem
 duplicar
 dados (e esforços) funcionários (físicas), transportadoras (fornecedores e
 jurídicas), terceirizados (físicas ou jurídicas).

 Agora vem a pergunta, qual é (são) a(s) pk(s) disso tudo? Sequencial, você
 já
 mostrou sem sombra de dúvida que não pode ser (em qualquer contexto).
 CNPJ|
 CPF, como já debateram aqui, também está fora para a *grande maioria* dos
 casos.

 E mais, como você mesmo tem levantado ultimamente: *o domínio* dessa(s)
 pk(s),
 uma vez que parece que o Postgresql, nessa parte seguiu bem o padrão SQL,
 ou
 seja, fraco, quero dizer criar um domínio mesmo com operadores e tal.


 Mesmo sem ser o Leandro vou arriscar um palpite: em separando bem as
 coisas, física, jurídica, pública e privada, acredito que se deva usar
 nossos CPF e CNPJ.


 --
 Ribamar FS - [EMAIL PROTECTED]
 http://ribafs.net

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




-- 
Guilherme de Carvalho Carneiro
guilherme.carvalho[a]advogaweb.com.br
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Modelando um Controle de Estoque

2008-07-12 Por tôpico Leandro DUTRA

2008/7/12 Guilherme Carvalho [EMAIL PROTECTED]:
 concordo no ponto de vista que usar CPF / CNPJ como chave não seria uma
 abordagem digamos das mais indicadas, nas modelagens que faço trabalho na
 maioria das vezes com chaves pk do tipo serial.

Desde que tenha uma chave natural... e que ela não seja adequada para
ser primária... mas tem de ser declarada.

-- 
skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra
+55 (11) 3040 7300 r155 gTalk: xmpp:[EMAIL PROTECTED]
+55 (11) 9406 7191 ICQ/AIM: aim:GoIM?screenname=61287803
+55 (11) 5685 2219 MSN: msnim:[EMAIL PROTECTED]
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Modelando um Controle de Estoque

2008-07-12 Por tôpico Leandro DUTRA

2008/7/11 Johnny Taylor Faria Chaves [EMAIL PROTECTED]:
 Quando dependemos (ou usamos o) do CPF não estamos modelando uma pessoa
 física, mas sim um brasileiro com cadastro na Receita Federal :( .

Ótima definição!


-- 
skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra
+55 (11) 3040 7300 r155 gTalk: xmpp:[EMAIL PROTECTED]
+55 (11) 9406 7191 ICQ/AIM: aim:GoIM?screenname=61287803
+55 (11) 5685 2219 MSN: msnim:[EMAIL PROTECTED]
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Modelando um Controle de Estoque

2008-07-11 Por tôpico Alexsander Rosa

Já pensei em usar uma chave composta CPF_CNPJ + NUMERO (inteiro) onde o
campo numero seria uma sequencia de 1 até N, de acordo com o número de
escolas/hospitais/etc com o mesmo CNPJ. Poderia haver uma coluna booleana
orgao_publico e um CHECK para garantir que apenas tuplas com
orgao_publico TRUE possam ter numero  1.

2008/7/7 Leandro DUTRA [EMAIL PROTECTED]:

 2008/7/7 Alexsander Rosa [EMAIL PROTECTED]:
  Eu vejo um problema em usar CNPJ como chave primária de clientes: os
 órgãos
  públicos. Em geral vários órgãos diferentes, com nomes e endereços
  diferentes, usam o mesmo CNPJ.

 Não sabia dessa, boa.

 Será que seria o caso então de especializar entidades em públicas ou
 privadas?  Talvez não, visto que, na internacionalização, o modelo já
 ia se complicar mais também.

 --
 skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra
 +55 (11) 3040 7300 r155 gTalk: xmpp:[EMAIL PROTECTED][EMAIL PROTECTED]
 +55 (11) 9406 7191 ICQ/AIM: aim:GoIM?screenname=61287803
 +55 (11) 5685 2219 MSN: msnim:[EMAIL PROTECTED]
 ___
 pgbr-geral mailing list
 pgbr-geral@listas.postgresql.org.br
 https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral




-- 
Atenciosamente,
Alexsander da Rosa
Linux User #113925
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Modelando um Controle de Estoque

2008-07-11 Por tôpico Leandro DUTRA

2008/7/11 Alexsander Rosa [EMAIL PROTECTED]:
 Já pensei em usar uma chave composta CPF_CNPJ + NUMERO (inteiro) onde o
 campo numero seria uma sequencia de 1 até N, de acordo com o número de
 escolas/hospitais/etc com o mesmo CNPJ. Poderia haver uma coluna booleana
 orgao_publico e um CHECK para garantir que apenas tuplas com
 orgao_publico TRUE possam ter numero  1.

Engenhoso, talvez até demais!

Normalmente não é bom compor mais de um significado num único
atributo, por isso a sugestão de normalizar.

Veja que, independente da modelagem das relações em si, o que se está
modelando são de fato duas entidades diferentes: organizações privadas
brasileiras de um lado, e órgãos públicos brasileiros de outro.

Não que tua modelagem seja proibida, mas veja que ela torna os dados
ambíguos, e o modelo meio opaco.

-- 
skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra
+55 (11) 3040 7300 r155 gTalk: xmpp:[EMAIL PROTECTED]
+55 (11) 9406 7191 ICQ/AIM: aim:GoIM?screenname=61287803
+55 (11) 5685 2219 MSN: msnim:[EMAIL PROTECTED]
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Modelando um Controle de Estoque

2008-07-11 Por tôpico Shander Lyrio


Alexsander Rosa escreveu:
  Já pensei em usar uma chave composta CPF_CNPJ + NUMERO (inteiro) onde o
  campo numero seria uma sequencia de 1 até N, de acordo com o número de
  escolas/hospitais/etc com o mesmo CNPJ. Poderia haver uma coluna
  booleana orgao_publico e um CHECK para garantir que apenas tuplas com
  orgao_publico TRUE possam ter numero  1.


Que coisa, recebi a resposta do Leandro cerca de 10 min antes desta 
mensagem

Sinistro!!

--
Shander Lyrio

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

Re: [pgbr-geral] Modelando um Controle de Estoque

2008/7/11 Leandro DUTRA [EMAIL PROTECTED]:

 2008/7/11 Alexsander Rosa [EMAIL PROTECTED]:
  Já pensei em usar uma chave composta CPF_CNPJ + NUMERO (inteiro) onde o
  campo numero seria uma sequencia de 1 até N, de acordo com o número de
  escolas/hospitais/etc com o mesmo CNPJ. Poderia haver uma coluna booleana
  orgao_publico e um CHECK para garantir que apenas tuplas com
  orgao_publico TRUE possam ter numero  1.

 Engenhoso, talvez até demais!

 Normalmente não é bom compor mais de um significado num único
 atributo, por isso a sugestão de normalizar.

 Veja que, independente da modelagem das relações em si, o que se está
 modelando são de fato duas entidades diferentes: organizações privadas
 brasileiras de um lado, e órgãos públicos brasileiros de outro.

 Não que tua modelagem seja proibida, mas veja que ela torna os dados
 ambíguos, e o modelo meio opaco.


Mesmo sem ainda ter um bom conhecimento eu tenho uma grande empatia pela
normalização.
Tentando traduzie no popular é como se fosse uma boa organização, cada coisa
em seu lugar e uma grande saparação, especializando e simplificando as
coisas.
Muito engenhosa e interessante a idéias e até tentadora à primeira vista,
mas veja que realmente deixa as coisas mais complexas e engessadas.

Não custa nada se criar então duas tabelas: uma para empresas privadas e
outra para órgãos públicos, ou então, talvez melhor ainda, apenas empresa e
com relacionamento com algo como tipo (privada e pública). Acho, minha
iniciante opinião, mais eficiente.

-- 
Ribamar FS - [EMAIL PROTECTED]
http://ribafs.net
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Modelando um Controle de Estoque

2008/7/11 Shander Lyrio [EMAIL PROTECTED]:


 Alexsander Rosa escreveu:
   Já pensei em usar uma chave composta CPF_CNPJ + NUMERO (inteiro) onde o
   campo numero seria uma sequencia de 1 até N, de acordo com o número de
   escolas/hospitais/etc com o mesmo CNPJ. Poderia haver uma coluna
   booleana orgao_publico e um CHECK para garantir que apenas tuplas com
   orgao_publico TRUE possam ter numero  1.


 Que coisa, recebi a resposta do Leandro cerca de 10 min antes desta
 mensagem

Sinistro!!


Leandro, The Flash?
Fusos horários?
Prediletismo?
Questões!
Brincadeirinha!


 --
 Shander Lyrio

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




-- 
Ribamar FS - [EMAIL PROTECTED]
http://ribafs.net
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Modelando um Controle de Estoque

2008-07-11 Por tôpico Johnny Taylor Faria Chaves

Em Monday 23 June 2008 20:36:53 Leandro DUTRA escreveu:
 2008/6/23 Ribamar Sousa [EMAIL PROTECTED]:
  EMPRESA: ALEX
 
  TIPOS_DE_EMPRESA (FUNCIONÁRIO,CLIENTE,FORNECEDOR, UNIDADE
  ORGANIZACIONAL) EMPRESA_TIPO: ALEX - (FUNCIONÁRIO,CLIENTE)
 
  Acho que isso não confronta com a normalização, realmente pelo contrário,
  mas a coisa deve ser feita com  calma, pois parece ficar mais complexa.

 Desnecessariamente complexo.

 Basta declarar pessoa, cliente ou fornecedor.  Três tabelas.

 Daí pessoa jurídica ou física, mais duas tabelas.

Há muito estou acompanhando aos pedaços essa discussão (nem vi onde ela saiu 
do estoque propriamente dito e entrou nessa de clientes, fornecedores e 
etc..., mas está ótimo).

Leandro, agora chegou em um ponto que venho matutando desde que vi o desvio 
citado acima. Concordo que a solução é como você mostrou acima (pessoas= 
físicas| jurídicas + clientes| fornecedores) e facilita inserir sem duplicar 
dados (e esforços) funcionários (físicas), transportadoras (fornecedores e 
jurídicas), terceirizados (físicas ou jurídicas).

Agora vem a pergunta, qual é (são) a(s) pk(s) disso tudo? Sequencial, você já 
mostrou sem sombra de dúvida que não pode ser (em qualquer contexto). CNPJ|
CPF, como já debateram aqui, também está fora para a *grande maioria* dos 
casos. 

E mais, como você mesmo tem levantado ultimamente: *o domínio* dessa(s) pk(s), 
uma vez que parece que o Postgresql, nessa parte seguiu bem o padrão SQL, ou 
seja, fraco, quero dizer criar um domínio mesmo com operadores e tal.

[]'s

-- 
Johnny Taylor Faria Chaves - LUN 157066 
www.brdados.com.br - [EMAIL PROTECTED]
Eu não posso mais, se você pode, doe sangue!
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Modelando um Controle de Estoque

2008/7/11 Johnny Taylor Faria Chaves [EMAIL PROTECTED]:

  Basta declarar pessoa, cliente ou fornecedor.  Três tabelas.
 
  Daí pessoa jurídica ou física, mais duas tabelas.

 Há muito estou acompanhando aos pedaços essa discussão (nem vi onde ela
 saiu
 do estoque propriamente dito e entrou nessa de clientes, fornecedores e
 etc..., mas está ótimo).

 Leandro, agora chegou em um ponto que venho matutando desde que vi o
 desvio
 citado acima. Concordo que a solução é como você mostrou acima (pessoas=
 físicas| jurídicas + clientes| fornecedores) e facilita inserir sem
 duplicar
 dados (e esforços) funcionários (físicas), transportadoras (fornecedores e
 jurídicas), terceirizados (físicas ou jurídicas).

 Agora vem a pergunta, qual é (são) a(s) pk(s) disso tudo? Sequencial, você
 já
 mostrou sem sombra de dúvida que não pode ser (em qualquer contexto). CNPJ|
 CPF, como já debateram aqui, também está fora para a *grande maioria* dos
 casos.

 E mais, como você mesmo tem levantado ultimamente: *o domínio* dessa(s)
 pk(s),
 uma vez que parece que o Postgresql, nessa parte seguiu bem o padrão SQL,
 ou
 seja, fraco, quero dizer criar um domínio mesmo com operadores e tal.


Mesmo sem ser o Leandro vou arriscar um palpite: em separando bem as coisas,
física, jurídica, pública e privada, acredito que se deva usar nossos CPF
e CNPJ.

-- 
Ribamar FS - [EMAIL PROTECTED]
http://ribafs.net
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Modelando um Controle de Estoque

2008-07-11 Por tôpico Leandro DUTRA

2008/7/11 Johnny Taylor Faria Chaves [EMAIL PROTECTED]:
 Agora vem a pergunta, qual é (são) a(s) pk(s) disso tudo? Sequencial, você já
 mostrou sem sombra de dúvida que não pode ser (em qualquer contexto).

Não é tão simples.

Pode ser, desde que haja também pelo menos uma chave natural, mesmo
que composta — em último caso, composta até por toda a tabela, se
necessário; exceto campos seqüenciais, claro.


 E mais, como você mesmo tem levantado ultimamente: *o domínio* dessa(s) pk(s),
 uma vez que parece que o Postgresql, nessa parte seguiu bem o padrão SQL, ou
 seja, fraco, quero dizer criar um domínio mesmo com operadores e tal.

Pois é, essa questão não tem resposta fácil.

Domínio em si não tem operadores; é o tipo que é o domínio mais os operadores.

E de fato temos CREATE TYPE, mas tem de ser codificado em C, D ou
coisa assim e carregado como código objeto.  E não tem o que o DOMAIN
tem, como restrições de integridade.

Ainda não vi um uso interessante e generalizado de TYPEs; de qualquer
maneira, qualquer TYPE criado fica mais interessante se usado dentro
de DOMAINs.

Talvez o Leonardo César tenha alguns exemplos interessantes?


-- 
skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra
+55 (11) 3040 7300 r155 gTalk: xmpp:[EMAIL PROTECTED]
+55 (11) 9406 7191 ICQ/AIM: aim:GoIM?screenname=61287803
+55 (11) 5685 2219 MSN: msnim:[EMAIL PROTECTED]
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Modelando um Controle de Estoque

2008-07-11 Por tôpico Leandro DUTRA

2008/7/11 Ribamar Sousa [EMAIL PROTECTED]:
 Mesmo sem ser o Leandro vou arriscar um palpite: em separando bem as coisas,
 física, jurídica, pública e privada, acredito que se deva usar nossos CPF
 e CNPJ.

Desde que não entrem nem estrangeiros (não têm CNP[FJ]), nem crianças
nem mulheres casadas sem vida econômica (não têm CNPF), concordo.


-- 
skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra
+55 (11) 3040 7300 r155 gTalk: xmpp:[EMAIL PROTECTED]
+55 (11) 9406 7191 ICQ/AIM: aim:GoIM?screenname=61287803
+55 (11) 5685 2219 MSN: msnim:[EMAIL PROTECTED]
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Modelando um Controle de Estoque

2008-07-11 Por tôpico Johnny Taylor Faria Chaves

Em Friday 11 July 2008 22:27:51 Leandro DUTRA escreveu:
 2008/7/11 Ribamar Sousa [EMAIL PROTECTED]:
  Mesmo sem ser o Leandro vou arriscar um palpite: em separando bem as
  coisas, física, jurídica, pública e privada, acredito que se deva usar
  nossos CPF e CNPJ.

 Desde que não entrem nem estrangeiros (não têm CNP[FJ]), nem crianças
 nem mulheres casadas sem vida econômica (não têm CNPF), concordo.

O que *para mim* e minha clientela atual, não serve, laboratórios (área de 
saúde em geral), precisam, principalmente para crianças. 

Quando dependemos (ou usamos o) do CPF não estamos modelando uma pessoa 
física, mas sim um brasileiro com cadastro na Receita Federal :( .

-- 
Johnny Taylor Faria Chaves - LUN 157066 
www.brdados.com.br - [EMAIL PROTECTED]
Eu não posso mais, se você pode, doe sangue!
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Modelando um Controle de Estoque

2008/7/11 Leandro DUTRA [EMAIL PROTECTED]:

 2008/7/11 Ribamar Sousa [EMAIL PROTECTED]:
  Mesmo sem ser o Leandro vou arriscar um palpite: em separando bem as
 coisas,
  física, jurídica, pública e privada, acredito que se deva usar nossos
 CPF
  e CNPJ.

 Desde que não entrem nem estrangeiros (não têm CNP[FJ]), nem crianças
 nem mulheres casadas sem vida econômica (não têm CNPF), concordo.


 Acredito que se tem que chegar a um acordo sobre as restrições de
 abrangência, pois se não restringirmos a abrangência a coisa ficará muito
 difícil de implementar, correto?





 --
 skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra
 +55 (11) 3040 7300 r155 gTalk: xmpp:[EMAIL PROTECTED][EMAIL PROTECTED]
 +55 (11) 9406 7191 ICQ/AIM: aim:GoIM?screenname=61287803
 +55 (11) 5685 2219 MSN: msnim:[EMAIL PROTECTED]
 ___
 pgbr-geral mailing list
 pgbr-geral@listas.postgresql.org.br
 https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral




-- 
Ribamar FS - [EMAIL PROTECTED]
http://ribafs.net
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Modelando um Controle de Estoque

2008-07-11 Por tôpico alecindro

Outro problema para o CNPJ ser a chave natural. E se quisermos ter cliente
cadastrado sem CNPJ ou CPF, ou seja, poderão ser futuros clientes, com
cadastro incompleto, estão cadastrados para mailing, mala-direta ou qualquer
outra atividade de marketing.

No meu caso eu procuro sempre generalizar as coisas.


Alecindro

Quoting Ribamar Sousa [EMAIL PROTECTED]:

 2008/7/11 Leandro DUTRA [EMAIL PROTECTED]:

 2008/7/11 Ribamar Sousa [EMAIL PROTECTED]:
  Mesmo sem ser o Leandro vou arriscar um palpite: em separando bem as
 coisas,
  física, jurídica, pública e privada, acredito que se deva usar nossos
 CPF
  e CNPJ.

 Desde que não entrem nem estrangeiros (não têm CNP[FJ]), nem crianças
 nem mulheres casadas sem vida econômica (não têm CNPF), concordo.


 Acredito que se tem que chegar a um acordo sobre as restrições de
 abrangência, pois se não restringirmos a abrangência a coisa ficará muito
 difícil de implementar, correto?





 --
 skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra
 +55 (11) 3040 7300 r155 gTalk: 
 xmpp:[EMAIL PROTECTED][EMAIL PROTECTED]
 +55 (11) 9406 7191 ICQ/AIM: aim:GoIM?screenname=61287803
 +55 (11) 5685 2219 MSN: msnim:[EMAIL PROTECTED]
 ___
 pgbr-geral mailing list
 pgbr-geral@listas.postgresql.org.br
 https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral




 --
 Ribamar FS - [EMAIL PROTECTED]
 http://ribafs.net




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

Re: [pgbr-geral] Modelando um Controle de Estoque

2008-07-08 Por tôpico Alexsandro Haag


Obrigado pelo exemplo prático Alexsander.
Eu defendi este argumento, mas não tinha encontrado naquele momento um 
caso prático que o reforçasse.


Att.
Alex

Alexsander Rosa escreveu:
Eu vejo um problema em usar CNPJ como chave primária de clientes: os 
órgãos públicos. Em geral vários órgãos diferentes, com nomes e 
endereços diferentes, usam o mesmo CNPJ. Por exemplo, aqui no RS todas 
as escolas estaduais usam o mesmo CNPJ, da Secretaria de Educação: 
92.941.681/0001-00. Para efeito de negócio são clientes diferentes, 
pois cada escola tem um perfil e um histórico de compras diferente, um 
endereço diferente, uma relação de compradores diferente, etc. Não 
seria interessante, do ponto de vista do negócio, unificar todos no 
mesmo cadastro por causa de uma restrição da modelagem de dados.


2008/6/20 Leandro DUTRA [EMAIL PROTECTED] 
mailto:[EMAIL PROTECTED]:


2008/6/20 Ribamar Sousa [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]:

 Bem, hoje o banco está com 13 tabelas, todas relacionadas mas
percebo que
 uma grande maioria também deve ser adicionada num sistema real e
importante.

Muito bom enviar o script � e muito bom usar preferencialmente
chaves naturais!

Estávamos mesmo precisando de bons contra-exemplos ao Hybernate...

--
skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra
+55 (11) 3040 7300 r155 gTalk: xmpp:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
+55 (11) 9406 7191 ICQ/AIM: aim:GoIM?screenname=61287803
+55 (11) 5685 2219 MSN:
msnim:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
mailto:pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral




--
Atenciosamente,
Alexsander da Rosa
Linux User #113925


___
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] Modelando um Controle de Estoque

2008-07-07 Por tôpico Alexsander Rosa

Eu vejo um problema em usar CNPJ como chave primária de clientes: os órgãos
públicos. Em geral vários órgãos diferentes, com nomes e endereços
diferentes, usam o mesmo CNPJ. Por exemplo, aqui no RS todas as escolas
estaduais usam o mesmo CNPJ, da Secretaria de Educação: 92.941.681/0001-00.
Para efeito de negócio são clientes diferentes, pois cada escola tem um
perfil e um histórico de compras diferente, um endereço diferente, uma
relação de compradores diferente, etc. Não seria interessante, do ponto de
vista do negócio, unificar todos no mesmo cadastro por causa de uma
restrição da modelagem de dados.

2008/6/20 Leandro DUTRA [EMAIL PROTECTED]:

 2008/6/20 Ribamar Sousa [EMAIL PROTECTED]:
 
  Bem, hoje o banco está com 13 tabelas, todas relacionadas mas percebo que
  uma grande maioria também deve ser adicionada num sistema real e
 importante.

 Muito bom enviar o script — e muito bom usar preferencialmente chaves
 naturais!

 Estávamos mesmo precisando de bons contra-exemplos ao Hybernate...

 --
 skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra
 +55 (11) 3040 7300 r155 gTalk: xmpp:[EMAIL PROTECTED][EMAIL PROTECTED]
 +55 (11) 9406 7191 ICQ/AIM: aim:GoIM?screenname=61287803
 +55 (11) 5685 2219 MSN: msnim:[EMAIL PROTECTED]
 ___
 pgbr-geral mailing list
 pgbr-geral@listas.postgresql.org.br
 https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral




-- 
Atenciosamente,
Alexsander da Rosa
Linux User #113925
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Modelando um Controle de Estoque

2008-07-07 Por tôpico Ribamar Sousa

2008/7/7 Alexsander Rosa [EMAIL PROTECTED]:

 Eu vejo um problema em usar CNPJ como chave primária de clientes: os órgãos
 públicos. Em geral vários órgãos diferentes, com nomes e endereços
 diferentes, usam o mesmo CNPJ. Por exemplo, aqui no RS todas as escolas
 estaduais usam o mesmo CNPJ, da Secretaria de Educação: 92.941.681/0001-00.
 Para efeito de negócio são clientes diferentes, pois cada escola tem um
 perfil e um histórico de compras diferente, um endereço diferente, uma
 relação de compradores diferente, etc. Não seria interessante, do ponto de
 vista do negócio, unificar todos no mesmo cadastro por causa de uma
 restrição da modelagem de dados.


Não sabia disso. Nesse caso não é recomendado. Vou alterar.



-- 
Ribamar FS - [EMAIL PROTECTED]
http://ribafs.net
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Modelando um Controle de Estoque

2008-07-07 Por tôpico Leandro DUTRA

2008/7/7 Alexsander Rosa [EMAIL PROTECTED]:
 Eu vejo um problema em usar CNPJ como chave primária de clientes: os órgãos
 públicos. Em geral vários órgãos diferentes, com nomes e endereços
 diferentes, usam o mesmo CNPJ.

Não sabia dessa, boa.

Será que seria o caso então de especializar entidades em públicas ou
privadas?  Talvez não, visto que, na internacionalização, o modelo já
ia se complicar mais também.

-- 
skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra
+55 (11) 3040 7300 r155 gTalk: xmpp:[EMAIL PROTECTED]
+55 (11) 9406 7191 ICQ/AIM: aim:GoIM?screenname=61287803
+55 (11) 5685 2219 MSN: msnim:[EMAIL PROTECTED]
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Modelando um Controle de Estoque

2008-07-01 Por tôpico Aldo Prosol

ola a todos 

existe alguma forma de mudar um campo inteiro para serial 


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

Re: [pgbr-geral] Modelando um Controle de Estoque

2008-07-01 Por tôpico joao.junior

pode atrelar um serial ao campo inteiro, serial nao é um data type , e logo 
depois de atrelar setar o serial para o valor que estava no campo inteiro
  - Original Message - 
  From: Aldo Prosol 
  To: Comunidade PostgreSQL Brasileira 
  Sent: Tuesday, July 01, 2008 11:28 AM
  Subject: Re: [pgbr-geral] Modelando um Controle de Estoque


  ola a todos 

  existe alguma forma de mudar um campo inteiro para serial 





--


  ___
  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] Modelando um Controle de Estoque

2008-07-01 Por tôpico Osvaldo Kussama

Em 01/07/08, Aldo Prosol[EMAIL PROTECTED] escreveu:

 existe alguma forma de mudar um campo inteiro para serial



Do manual em:
http://pgdocptbr.sourceforge.net/pg80/datatype.html#DATATYPE-SERIAL

8.1.4. Tipos seriais

Os tipos de dado serial e bigserial não são tipos verdadeiros, mas
meramente uma notação conveniente para definir colunas identificadoras
únicas (semelhante à propriedade AUTO_INCREMENTO existente em alguns
outros bancos de dados). Na implementação corrente especificar

CREATE TABLE nome_da_tabela (
nome_da_coluna SERIAL
);

equivale a especificar:

CREATE SEQUENCE nome_da_tabela_nome_da_coluna_seq;
CREATE TABLE nome_da_tabela (
nome_da_coluna integer DEFAULT
nextval('nome_da_tabela_nome_da_coluna_seq') NOT NULL
); 

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

Re: [pgbr-geral] Modelando um Controle de Estoque

2008-07-01 Por tôpico Aldo Prosol

obrigado, ja acertei


- Original Message - 
From: Osvaldo Kussama [EMAIL PROTECTED]
To: Comunidade PostgreSQL Brasileira pgbr-geral@listas.postgresql.org.br
Sent: Tuesday, July 01, 2008 11:59 AM
Subject: Re: [pgbr-geral] Modelando um Controle de Estoque


Em 01/07/08, Aldo Prosol[EMAIL PROTECTED] escreveu:

 existe alguma forma de mudar um campo inteiro para serial



Do manual em:
http://pgdocptbr.sourceforge.net/pg80/datatype.html#DATATYPE-SERIAL

8.1.4. Tipos seriais

Os tipos de dado serial e bigserial não são tipos verdadeiros, mas
meramente uma notação conveniente para definir colunas identificadoras
únicas (semelhante à propriedade AUTO_INCREMENTO existente em alguns
outros bancos de dados). Na implementação corrente especificar

CREATE TABLE nome_da_tabela (
nome_da_coluna SERIAL
);

equivale a especificar:

CREATE SEQUENCE nome_da_tabela_nome_da_coluna_seq;
CREATE TABLE nome_da_tabela (
nome_da_coluna integer DEFAULT
nextval('nome_da_tabela_nome_da_coluna_seq') NOT NULL
); 

Osvaldo
___
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] Modelando um Controle de Estoque

2008-06-30 Por tôpico Alexsandro Haag


No ponto de compreensão do Sistema creio que tenha mesmo razão.

Só não tenho certeza quanto a questão de melhoria de desempenho, pois 
normalmente (como usuário do sistema) vou querer ver todos meus clientes 
de forma consolidada, desta forma vou normalmente precisar de uma View 
unindo estas tabelas e creio que em raríssimos casos vou utilizar o 
acesso a pessoa física ou pessoa jurídica individualmente.


Mas, como na prática, não implementei estas duas realidades de modelagem 
tudo que estou dizendo acima é suposição. Talvez pudésse, por exemplo, 
ter estas  tabelas separadas fisicamente em tablespaces que estão em 
discos separados, otimizando assim o acesso ao disco mesmo com o uso da 
View.


Claro, tudo depende do contexto inteiro e de pesar todos os prós e 
contras. É difícil tomarmos decisões isoladas sem termos todos os 
requisitos e informações do Projeto.


E concordo que é sempre altamente recomendável utilizarmos as boas 
práticas de modelagem para garantirmos escalabilidade e compreensão ao 
Sistema. Vou fazer uma experiência com a sugestão do Leandro neste 
projeto que estou envolvido atualmente para sentir na prática os 
prós/contras em relação a forma como tenho feito.


Leandro DUTRA escreveu:

2008/6/27 Alexsandro Haag [EMAIL PROTECTED]:
  

A forma como normalmente implemento meu DER Ã© muito aproximada, se nÃ£o
igual, ao mÃ©todo do Jocimar. CPF/CNPJ juntos e atÃ© entÃ£o nÃ£o tive problemas
com performance ou qualquer outro possÃvel problema relacionado ou levantado
na thread deste assunto na lista.



Pois Ã©, Alex, mas veja o que eu disse: hÃ¡ situaÃ§Ãµes particulares, e
creio ter deixado implÃcito mas claro que uma delas sÃ£o sistemas
pequenos, onde uma Ãºnica pessoa controla tanto base quanto programas.

Mas no caso geral, o correto Ã© validar na base para integridade, e
normalizar com o mesmo objetivo â�� o que incidentalmente pode trazer
benefÃcios de desempenho em situaÃ§Ãµes de grande volume, alÃ©m de tornar
o sistema mais compreensÃvel para quem o herdar.


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

Re: [pgbr-geral] Modelando um Controle de Estoque

2008-06-27 Por tôpico Igor



Leandro DUTRA escreveu:
 2008/6/23 Ribamar Sousa [EMAIL PROTECTED]:
   
 EMPRESA: ALEX

 TIPOS_DE_EMPRESA (FUNCIONÁRIO,CLIENTE,FORNECEDOR, UNIDADE ORGANIZACIONAL)
 EMPRESA_TIPO: ALEX - (FUNCIONÁRIO,CLIENTE)
   
 Acho que isso não confronta com a normalização, realmente pelo contrário,
 mas a coisa deve ser feita com  calma, pois parece ficar mais complexa.
 

 Desnecessariamente complexo.

 Basta declarar pessoa, cliente ou fornecedor.  Três tabelas.

 Daí pessoa jurídica ou física, mais duas tabelas.

   

Não entendi, pq separar Cliente em duas Tabelas PF e PJ se pode ser a 
mesma tabela com um TIPO?


-- 
[]'s
Igor C. Batista
msn: [EMAIL PROTECTED]
skype: mld_crark

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

Re: [pgbr-geral] Modelando um Controle de Estoque

2008-06-27 Por tôpico Emerson Casas Salvador

Igor escreveu:
 Leandro DUTRA escreveu:
   
 2008/6/23 Ribamar Sousa [EMAIL PROTECTED]:
 
 EMPRESA: ALEX

 TIPOS_DE_EMPRESA (FUNCIONÁRIO,CLIENTE,FORNECEDOR, UNIDADE ORGANIZACIONAL)
 EMPRESA_TIPO: ALEX - (FUNCIONÁRIO,CLIENTE)
 
 Acho que isso não confronta com a normalização, realmente pelo contrário,
 mas a coisa deve ser feita com  calma, pois parece ficar mais complexa.
   
 Desnecessariamente complexo.

 Basta declarar pessoa, cliente ou fornecedor.  Três tabelas.

 Daí pessoa jurídica ou física, mais duas tabelas.
 
 Não entendi, pq separar Cliente em duas Tabelas PF e PJ se pode ser a 
 mesma tabela com um TIPO?
   
por causa da validação de dados que são diferentes como por exemplo cpf 
e cnpj

--
Esta mensagem foi verificada pelo sistema de Anti-virus da SJB Solados.

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

Re: [pgbr-geral] Modelando um Controle de Estoque

2008-06-27 Por tôpico Dickson Guedes

Jocimar de Oliveira escreveu:
 On Friday 27 June 2008 15:00:03 Emerson Casas Salvador wrote:
 Igor escreveu:
 Basta declarar pessoa, cliente ou fornecedor.  Três tabelas.

 Daí pessoa jurídica ou física, mais duas tabelas.
 Não entendi, pq separar Cliente em duas Tabelas PF e PJ se pode ser
 a mesma tabela com um TIPO?
 por causa da validação de dados que são diferentes como por exemplo
 cpf e cnpj

 -
 
 Verifique o tamanho do resultado do campo, depois é só validar o CPF ou 
 CNPJ.

Razao social, nome fantasia, data de fundação etc... Pessoa é uma pessoa 
genérica, Pessoa Fisica e Pessoa Juridica são pessoas com algumas 
caracteristicas distintas entre elas.

Alem disso não é muito elegante usar um mesmo atributo para conter dados 
diferentes.

-- 
[]s
Dickson S. Guedes
-
Projeto Colmeia - Curitiba - PR
(41) 3254-7130 ramal: 27
http://pgcon.postgresql.org.br
http://makeall.wordpress.com/
http://planeta.postgresql.org.br/
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Modelando um Controle de Estoque

On Friday 27 June 2008 15:34:14 Dickson Guedes wrote:
 Jocimar de Oliveira escreveu:
  On Friday 27 June 2008 15:00:03 Emerson Casas Salvador wrote:
  Igor escreveu:
  Basta declarar pessoa, cliente ou fornecedor.  Três tabelas.
 
  Daí pessoa jurídica ou física, mais duas tabelas.
 
  Não entendi, pq separar Cliente em duas Tabelas PF e PJ se pode
  ser a mesma tabela com um TIPO?
 
  por causa da validação de dados que são diferentes como por
  exemplo cpf e cnpj
 
  --
 ---
 
  Verifique o tamanho do resultado do campo, depois é só validar o
  CPF ou CNPJ.

 Razao social, nome fantasia, data de fundação etc... Pessoa é uma
 pessoa genérica, Pessoa Fisica e Pessoa Juridica são pessoas com
 algumas caracteristicas distintas entre elas.

 Alem disso não é muito elegante usar um mesmo atributo para conter
 dados diferentes.

Utilizo há mais de 15 anos, funciona perfeitamente.

No cadastro de clientes, você cria opções para preenchimento específicos 
para empresas (Nome fantasia, data de fundação, etc, ...) e outro para 
pessoa física (data de nascimento, sexo, etc, ...) e o acesso você 
controle pelo CPF ou CNPJ

Veja que o termo elegante é questão de como criar as telas para o 
usuário, e de como se cria a sua modelagem. Atualmente tenho mais de 15 
tabelas apenas para cadastro de clientes, e o acesso as opções do 
cadastro é controlado por CPF ou CNPJ.

Não há problema nenhum de se fazer da sua forma como da minha, então não 
é questão de discussões, apenas de forma de modelar dados e atribuir 
telas adequadas para o usuário. No meu caso cliente é cliente, CPF e 
CNPJ na mesma tabela.

-- 
Saudações,

Jocimar de Oliveira
www.jocimar.com.br
(42) 8414-5546
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Modelando um Controle de Estoque

2008/6/27 Jocimar de Oliveira [EMAIL PROTECTED]:
 Utilizo há mais de 15 anos, funciona perfeitamente.

Tem gente que faz há 50, funciona perfeitamente.  Mas está errado.

O seu programa tem de validar.  E quando essa base está num sistema
enorme, com zilhares de usuários concorrentes, e programadores
recém-saídos dos cueiros?  Quem tem de validar é a base, e separar
informações em estruturas lógicas facilita o trabalhos dos
programadores e distribui o acesso a disco.

Muita coisa parece certa, até você pensar nos casos extremos que podem
não fazer parte da sua experiência mas fazem da de outros.  E por isso
existem os livros e os artigos técnicos — infelizmente, está difícil
achar os bons livros e artigos.

-- 
skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra
+55 (11) 3040 7300 r155 gTalk: xmpp:[EMAIL PROTECTED]
+55 (11) 9406 7191 ICQ/AIM: aim:GoIM?screenname=61287803
+55 (11) 5685 2219 MSN: msnim:[EMAIL PROTECTED]
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Modelando um Controle de Estoque

On Friday 27 June 2008 15:47:48 Leandro DUTRA wrote:
 2008/6/27 Jocimar de Oliveira [EMAIL PROTECTED]:
  Utilizo há mais de 15 anos, funciona perfeitamente.

 Tem gente que faz há 50, funciona perfeitamente.  Mas está errado.

Não está errado, pois cliente é cliente.


 O seu programa tem de validar.

E valida, tanto o CPF quanto o CNPJ.

 E quando essa base está num sistema 
 enorme, com zilhares de usuários concorrentes, e programadores
 recém-saídos dos cueiros?  Quem tem de validar é a base, e separar
 informações em estruturas lógicas facilita o trabalhos dos
 programadores e distribui o acesso a disco.

Então, cadastro de cliente. E validação pode ser feita na base sem 
problemas. Primeiro verifica se é CPF ou CNPJ e depois faz a validação.


 Muita coisa parece certa, até você pensar nos casos extremos que
 podem não fazer parte da sua experiência mas fazem da de outros.  E
 por isso existem os livros e os artigos técnicos — infelizmente, está
 difícil achar os bons livros e artigos.

Como comentado em e-mail anterior (eliminado aqui), é questão de como 
você quer modelar e recuperar informação.
A modelagem é feita conforme  o resultado que se espera.

Se o programa for ser usado por zillares de usuários ou que o mesmo seja 
mantido por programadores recém-saídos dos cueiros, isto é uma outra 
questão. Então não devemos apenas propor sistemas para este porte, pois 
temos sistema para vários mercados e propósitos.

Então entenda que a minha experiência de 15 anos desenvolvendo nesta 
forma não é imutável, mas, o comentário de que a forma como está e para 
o público que usa, atende perfeitamente, e não há necessidade de mudar 
isto.
Na sequẽncia de minha carreira, ao deparar-me com condições extremas, 
não tenha dúvida que estarei ao lado de pessoas como vocẽs, mestres, e 
doutores, e com certeza estarei adaptando-me as condições atuais.

Veja bem, tenho um trabalho finalizado em FlagShip x linux, e desde esta 
última segunda-feira estou revisando tudo que posso de PostgreSQL 
(ribamar) e na sequência vou rever todo material oficial. Após estarei 
gerando todo o banco de dados para este SGBD.
Tendo este primeiro passo resolvido, vou iniciar estudos e migração do 
front-end para Java. Estou colocando-me num trabalho que acredito que 
levará no mínimo 2 anos, entre estudos, testes e realização.
Aqui reafirmo que não sou imutável, mas ao deparar-me com novas 
realidades consigo ajustar-me a estas novas condições.

Finalizando, o e-mail anterior foi apenas uma posição de como tenho meu 
sistema, e que realmente considero o outro trabalho da forma como foi 
feito. O público de meu trabalho é: cliente é cliente, fornecedor é 
fornecedor, transportadora é transportadora, ..., nada mais.

Postei o e-mail sobre esta posição por se tratar de uma lista de 
discusão e não de imposição, onde devemos apenas acatar grandes livros, 
voltados para grandes empresas.

-- 
Saudações,

Jocimar de Oliveira
www.jocimar.com.br
(42) 8414-5546
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Modelando um Controle de Estoque

2008/6/27 Jocimar de Oliveira [EMAIL PROTECTED]:
 O seu programa tem de validar.

 E valida, tanto o CPF quanto o CNPJ.

Mas a validação tem de ficar na base.  O resto é adaptação a situações
particulares.

Entendeu?  Pode até ser certo para tua situação, mas é conceitualmente errado.

-- 
skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra
+55 (11) 3040 7300 r155 gTalk: xmpp:[EMAIL PROTECTED]
+55 (11) 9406 7191 ICQ/AIM: aim:GoIM?screenname=61287803
+55 (11) 5685 2219 MSN: msnim:[EMAIL PROTECTED]
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Modelando um Controle de Estoque

2008-06-27 Por tôpico Dickson Guedes

Jocimar de Oliveira escreveu:
 On Friday 27 June 2008 15:34:14 Dickson Guedes wrote:
 Razao social, nome fantasia, data de fundação etc... Pessoa é uma
 pessoa genérica, Pessoa Fisica e Pessoa Juridica são pessoas com
 algumas caracteristicas distintas entre elas.

 Alem disso não é muito elegante usar um mesmo atributo para conter
 dados diferentes.
 
 (...)
 Não há problema nenhum de se fazer da sua forma como da minha, então não 
 é questão de discussões, apenas de forma de modelar dados e atribuir 
 telas adequadas para o usuário. No meu caso cliente é cliente, CPF e 
 CNPJ na mesma tabela.

Longe de mim querer entrar nesse nivel de discussão, a idéia foi de 
apenas deixar minha opnião no histórico para futuras consultas.

Eu apenas sugeri superficialmente uma forma onde uma implementação de um 
modelo de segurança por granularidade-fina (mas não somente) torna-se 
mais simples pelo simples fato de eu poder distinguir fisicamente uma 
entidade da outra.

E isso numa base que gira em torno de 150 GB tem muita diferença.

-- 
[]s
Dickson S. Guedes
-
Projeto Colmeia - Curitiba - PR
(41) 3254-7130 ramal: 27
http://pgcon.postgresql.org.br
http://makeall.wordpress.com/
http://planeta.postgresql.org.br/
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Modelando um Controle de Estoque

On Friday 27 June 2008 16:18:02 Leandro DUTRA wrote:
 2008/6/27 Jocimar de Oliveira [EMAIL PROTECTED]:
  O seu programa tem de validar.
 
  E valida, tanto o CPF quanto o CNPJ.

 Mas a validação tem de ficar na base.  O resto é adaptação a
 situações particulares.

 Entendeu?  Pode até ser certo para tua situação, mas é
 conceitualmente errado.

Caro Leandro,

Sinto muito em retornar também este e-mail.

Veja que comento que não sou imutável, e que iniciei esta semana revisão 
de SQL x PostgreSQL,  e que na sequência vou mudar a linguagem de 
programação para Java, e que também vou revisar o material oficial do 
PostgreSQL.

Vejo que em seus e-mail's você sempre quer ser a última palavra, mas 
pare um pouco e leia novamente meu e-mail.
Em nenhum momento disse o que é certo ou errado, e não há motivo para 
ficar afirmando a mesma coisa, pois apenas comentei sobre a minha 
opção.

Então volto a afirmar: Durante os próximos 2 anos estarei estudando e 
muito, e estarei migrando todo meu trabalho, e não tenha dúvida que 
muita coisa será mudada do original que está em FlagShip. Nos últimos 3 
anos fiz várias mudanças na versão que está em FlagShip para ajustar as 
tabelas pouco mais perto da realidade dos SGBD, e desde 2005 venho 
apenas acompanhando esta lista (mesmo nas mudanças de hospedagem da 
mesma), com o objetivo de ampliar meus conhecimentos.

Após toda minha migração Java x SQL x PostgreSQL, vou postar mensagem 
nesta lista sobre a minha experiência em validação de CPF/CNPJ para 
cadastro de Clientes, vou guardar estes e-mail's para futura análise, 
já que vai demorar a finalização desta nova etapa.

-- 
Saudações,

Jocimar de Oliveira
www.jocimar.com.br
(42) 8414-5546
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Modelando um Controle de Estoque

On Friday 27 June 2008 16:27:40 Dickson Guedes wrote:
  Alem disso não é muito elegante usar um mesmo atributo para conter
  dados diferentes.
 
 Longe de mim querer entrar nesse nivel de discussão, a idéia foi de
 apenas deixar minha opnião no histórico para futuras consultas.

A sua afirmação foi de ser não ser elegante usar .,
este foi o motivo de mencionar discussão, já que havia seu 
posicionamento nesta questão. Nada mais.


 Eu apenas sugeri superficialmente uma forma onde uma implementação de
 um modelo de segurança por granularidade-fina (mas não somente)
 torna-se mais simples pelo simples fato de eu poder distinguir
 fisicamente uma entidade da outra.

 E isso numa base que gira em torno de 150 GB tem muita diferença.

Matando curiosidade: 150 GB de cadastro de clientes PF + PJ ?

-- 
Saudações,

Jocimar de Oliveira
www.jocimar.com.br
(42) 8414-5546
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Modelando um Controle de Estoque

2008/6/27 Jocimar de Oliveira [EMAIL PROTECTED]:
 Sinto muito em retornar também este e-mail.

Não há o que sentir, é apenas uma discussão técnica.


 Vejo que em seus e-mail's você sempre quer ser a última palavra

Eu não sou palavra, e não tenho a última — mas sou um Administrador de
Dados e tenho de prezar pelo conhecimento da minha área.

Portanto, insisto — há certo e errado, pelas razões explanadas; o
resto são situações particulares, como pode ser a sua.

Se pudermos deixar o lado pessoal fora dessas discussões, para serem
conversada em torno duma boa mesa de bar no fim do PgConBR ou algo
assim, vai muito melhor.

-- 
skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra
+55 (11) 3040 7300 r155 gTalk: xmpp:[EMAIL PROTECTED]
+55 (11) 9406 7191 ICQ/AIM: aim:GoIM?screenname=61287803
+55 (11) 5685 2219 MSN: msnim:[EMAIL PROTECTED]
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Modelando um Controle de Estoque

On Friday 27 June 2008 16:49:01 Leandro DUTRA wrote:
 2008/6/27 Jocimar de Oliveira [EMAIL PROTECTED]:
  Sinto muito em retornar também este e-mail.

 Não há o que sentir, é apenas uma discussão técnica.

  Vejo que em seus e-mail's você sempre quer ser a última palavra

 Eu não sou palavra, e não tenho a última — mas sou um Administrador
 de Dados e tenho de prezar pelo conhecimento da minha área.

 Portanto, insisto — há certo e errado, pelas razões explanadas; o
 resto são situações particulares, como pode ser a sua.

 Se pudermos deixar o lado pessoal fora dessas discussões, para serem
 conversada em torno duma boa mesa de bar no fim do PgConBR ou algo
 assim, vai muito melhor.

OK grande mestre.

-- 
Saudações,

Jocimar de Oliveira
www.jocimar.com.br
(42) 8414-5546
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Modelando um Controle de Estoque

2008-06-27 Por tôpico Alexsandro Haag


Só agora pude rever as mensagens da lista por falta de tempo.
Não entrando no mérito de certo/errado, só quero deixar minha 
experiência nesta questão.


A forma como normalmente implemento meu DER é muito aproximada, se não 
igual, ao método do Jocimar. CPF/CNPJ juntos e até então não tive 
problemas com performance ou qualquer outro possível problema 
relacionado ou levantado na thread deste assunto na lista.


Att.
Alex

Jocimar de Oliveira escreveu:

On Friday 27 June 2008 16:18:02 Leandro DUTRA wrote:
  

2008/6/27 Jocimar de Oliveira [EMAIL PROTECTED]:


O seu programa tem de validar.


E valida, tanto o CPF quanto o CNPJ.
  

Mas a validação tem de ficar na base.  O resto é adaptação a
situações particulares.

Entendeu?  Pode até ser certo para tua situação, mas é
conceitualmente errado.



Caro Leandro,

Sinto muito em retornar também este e-mail.

Veja que comento que não sou imutável, e que iniciei esta semana revisão 
de SQL x PostgreSQL,  e que na sequência vou mudar a linguagem de 
programação para Java, e que também vou revisar o material oficial do 
PostgreSQL.


Vejo que em seus e-mail's você sempre quer ser a última palavra, mas 
pare um pouco e leia novamente meu e-mail.
Em nenhum momento disse o que é certo ou errado, e não há motivo para 
ficar afirmando a mesma coisa, pois apenas comentei sobre a minha 
opção.


Então volto a afirmar: Durante os próximos 2 anos estarei estudando e 
muito, e estarei migrando todo meu trabalho, e não tenha dúvida que 
muita coisa será mudada do original que está em FlagShip. Nos últimos 3 
anos fiz várias mudanças na versão que está em FlagShip para ajustar as 
tabelas pouco mais perto da realidade dos SGBD, e desde 2005 venho 
apenas acompanhando esta lista (mesmo nas mudanças de hospedagem da 
mesma), com o objetivo de ampliar meus conhecimentos.


Após toda minha migração Java x SQL x PostgreSQL, vou postar mensagem 
nesta lista sobre a minha experiência em validação de CPF/CNPJ para 
cadastro de Clientes, vou guardar estes e-mail's para futura análise, 
já que vai demorar a finalização desta nova etapa.


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

Re: [pgbr-geral] Modelando um Controle de Estoque

2008/6/27 Jocimar de Oliveira [EMAIL PROTECTED]:
 Eu apenas sugeri superficialmente uma forma onde uma implementação de
 um modelo de segurança por granularidade-fina (mas não somente)
 torna-se mais simples pelo simples fato de eu poder distinguir
 fisicamente uma entidade da outra.

 E isso numa base que gira em torno de 150 GB tem muita diferença.

 Matando curiosidade: 150 GB de cadastro de clientes PF + PJ ?

Creio que ele está se referindo a uma base relativamente grande, onde
a organização e a centralização podem fazer muita diferença, tanto em
desempenho quando em gestão de segurança, entre outras coisas.

-- 
skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra
+55 (11) 3040 7300 r155 gTalk: xmpp:[EMAIL PROTECTED]
+55 (11) 9406 7191 ICQ/AIM: aim:GoIM?screenname=61287803
+55 (11) 5685 2219 MSN: msnim:[EMAIL PROTECTED]
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Modelando um Controle de Estoque

2008/6/27 Alexsandro Haag [EMAIL PROTECTED]:
 A forma como normalmente implemento meu DER é muito aproximada, se não
 igual, ao método do Jocimar. CPF/CNPJ juntos e até então não tive problemas
 com performance ou qualquer outro possível problema relacionado ou levantado
 na thread deste assunto na lista.

Pois é, Alex, mas veja o que eu disse: há situações particulares, e
creio ter deixado implícito mas claro que uma delas são sistemas
pequenos, onde uma única pessoa controla tanto base quanto programas.

Mas no caso geral, o correto é validar na base para integridade, e
normalizar com o mesmo objetivo — o que incidentalmente pode trazer
benefícios de desempenho em situações de grande volume, além de tornar
o sistema mais compreensível para quem o herdar.


-- 
skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra
+55 (11) 3040 7300 r155 gTalk: xmpp:[EMAIL PROTECTED]
+55 (11) 9406 7191 ICQ/AIM: aim:GoIM?screenname=61287803
+55 (11) 5685 2219 MSN: msnim:[EMAIL PROTECTED]
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Modelando um Controle de Estoque

On Friday 27 June 2008 17:00:08 Leandro DUTRA wrote:
 2008/6/27 Jocimar de Oliveira [EMAIL PROTECTED]:
 
  E isso numa base que gira em torno de 150 GB tem muita diferença.
 
  Matando curiosidade: 150 GB de cadastro de clientes PF + PJ ?

 Creio que ele está se referindo a uma base relativamente grande, onde
 a organização e a centralização podem fazer muita diferença, tanto em
 desempenho quando em gestão de segurança, entre outras coisas.

Esta questão eu entendi, tanto que questionei sobre o tamanho que ocupa 
os dados de cadastro de clientes PF + PJ, e só foi por curiosidade, 
pois fiquei imaginando o tamanho do banco de dados inteiro.

Várias foram as mensagens sobre custo de consulta para o SGBD e quanto 
mais separa-se tabelas melhor o desempenho.

Nos trabalhos que venho ajustando meu sistema atual, havia em torno de 
140 tabelas, e fazendo vários ajustes para iniciar esta migração já 
passei das 200 tabelas, mas no meu caso o perfil de meus clientes não 
há necessidade de normatizar mais o cadastro de clientes, separando PF 
e PJ.

-- 
Saudações,

Jocimar de Oliveira
www.jocimar.com.br
(42) 8414-5546
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Modelando um Controle de Estoque

On Friday 27 June 2008 16:59:12 Alexsandro Haag wrote:
 Só agora pude rever as mensagens da lista por falta de tempo.
 Não entrando no mérito de certo/errado, só quero deixar minha
 experiência nesta questão.

 A forma como normalmente implemento meu DER é muito aproximada, se
 não igual, ao método do Jocimar. CPF/CNPJ juntos e até então não tive
 problemas com performance ou qualquer outro possível problema
 relacionado ou levantado na thread deste assunto na lista.

 Att.
 Alex


Estou acompanhando a lista faz alguns anos, e veja que qualquer 
comentário que fazemos são na mesma hora respondido e sempre com 
imposições pela mesma pessoa. Já vi esta situação sendo repetida por 
aqui várias vezes. Não há como colocar a nossa forma de trabalho, pois 
ela sempre estará errada.

Até o momento pouco postei minhas posições por aqui por não conseguir 
trocar idéis e escutar a forma de trabalho dos demais profissionais. 
Por várias vezes acompanhei mensagens de outros em que também foram 
sufocadas do mesmo modo e pela mesma pessoa, e outros que poderiam 
dispôr de suas informações não a fizeram, que acabam ficando sem 
espaço.

Como venho estudando para migrar para este SGBD é fundamental esta troca 
de informação, se sou o único a fazer de determinada forma ou não, e 
desta forma poder decidir pelo melhor para mim.

Nesta lista com certeza têm pequenos desenvolvedores com pequenos 
sistemas como o meu com 160 mil linhas em FlagShip acessando mais de 
200 tabelas, e que acabam tendo em seus clientes entre 20 e 50 
estações, pequenas redes assim. E muitas vezes com faturamento entre 
100 mil a 5 milhões/mês. E, também grandes sistema com base de dados 
enormes, mas se não houver humildade da parte de todos, então não 
conseguiremos compartilhar nossa experiência e qualquer pessoa poderá 
ser surpreendido com posições prontas sem serem compreendidos.

Boa sorte a todos,

-- 
Saudações,

Jocimar de Oliveira
www.jocimar.com.br
(42) 8414-5546
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Modelando um Controle de Estoque

2008-06-27 Por tôpico Ribamar Sousa

Olá Jocimar e demais colegas!

2008/6/27 Jocimar de Oliveira [EMAIL PROTECTED]:

 Estou acompanhando a lista faz alguns anos, e veja que qualquer
 comentário que fazemos são na mesma hora respondido e sempre com
 imposições pela mesma pessoa. Já vi esta situação sendo repetida por
 aqui várias vezes. Não há como colocar a nossa forma de trabalho, pois
 ela sempre estará errada.

 Até o momento pouco postei minhas posições por aqui por não conseguir
 trocar idéis e escutar a forma de trabalho dos demais profissionais.
 Por várias vezes acompanhei mensagens de outros em que também foram
 sufocadas do mesmo modo e pela mesma pessoa, e outros que poderiam
 dispôr de suas informações não a fizeram, que acabam ficando sem
 espaço.

 Como venho estudando para migrar para este SGBD é fundamental esta troca
 de informação, se sou o único a fazer de determinada forma ou não, e
 desta forma poder decidir pelo melhor para mim.

 Nesta lista com certeza têm pequenos desenvolvedores com pequenos
 sistemas como o meu com 160 mil linhas em FlagShip acessando mais de
 200 tabelas, e que acabam tendo em seus clientes entre 20 e 50
 estações, pequenas redes assim. E muitas vezes com faturamento entre
 100 mil a 5 milhões/mês. E, também grandes sistema com base de dados
 enormes, mas se não houver humildade da parte de todos, então não
 conseguiremos compartilhar nossa experiência e qualquer pessoa poderá
 ser surpreendido com posições prontas sem serem compreendidos.


Sinceramente senti coisa parecida por várias vezes e até já levantei a
questão mas acabei me calando mas acho que precisamos de mais harmonia na
lista.

Reconheço que os colegas muito ativos ajudam muito a resolver os problemas
de quem chega, mas acredito que o tom de voz, a forma como as perguntas
são repsondidas deve melhorar.

Sei que a lista gera um grande tráfego mas vejam que deve existir maior
liberdade pois já houve um racha na lista e eu não gostaria de presenciar
mais um, pelo contrário, gostaria de colaborar para seu fortalecimento e do
nosso PostgreSQL, visto que a lista é uma das mais improtantes fontes de
informação sobre o mesmo.

É importante responder, mas lembrem que um dia foram iniciantes e tiveram
dúvidas. Não estou generalizando, apenas gostaria que a carapuça pegasse,
pois sei que muita gente aqui responde com muita paciência. Arriscaria até
que todos. Apenas algumas vezes exagera-se e é muito importante dar
liberdade para outros discordarem.

Espero com essa intervenção não estar causando confusão mas sim colaborando
para melhorar o clima que se respira na nossa lista, pois como já levantei
certa vez essa questão, acho que isso é importante para uma melhor
convivência e para um melhor desempenho da lista.

-- 
Ribamar FS - [EMAIL PROTECTED]
http://ribafs.net
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Modelando um Controle de Estoque

2008-06-25 Por tôpico alecindro

Bem pessoal resolvi entrar na discussão. Sou programador java e metido a
Analista.

Primeiramente antes de modelarmos algo seria ideal estudarmos o processo que
envolve o controle de estoque. Com isso, poderíamos desenvolvermos em
módulos, e  ofertar um sistema de acordo com a necessidade do cliente.

O tópico em questão é sobre Controle de Estoque. Mas vi diversas
manifestações que, creio, fogem um pouco a controle de Estoque, que seriam
como vender, a quem vender, como comprar, de quem comprar.

Processo de Controle de Estoque:

Basicamente, compreende-se em 3 etapas:

entrada, logística de armazenagem e saída.

Podemos chamar um sistema voltado para Almoxarifado.

Entrada - Para entrada devemos responder as seguintes perguntas:

- toda entrada de mercadoria deve ter um documento de entrada?
- toda entrada de mercadoria deve ter um pedido previamente cadastrado?
- deve haver conferência entre o documento de entrada e o pedido?
- essa conferência é feita via sistema ou pelo operador?
- todo produto de entrada deve ter código de barras?
- Senão, devemos criar o código de barras, isto é, existe necessidade de
adotarmos código de barras?
- toda entrada é uma compra?
- produtos tem número de série?
- Como será tratado a entrada de produtos proveniente de devoluções, entregas
não efetuadas, cortesias, etc?

Logística de armazenagem:

- vamos identificar o local de armazenamento do produto?
- produtos similares com pequenas alterações iremos criar grade de produtos?
Exemplo: sapatos tamanho 34,36,38,40.
- produtos tem prazo de validade?
- produtos são em unidade, volume (kg, lt, cm, m), produtos a granel?

Saída:
- todo produto que tiver saída tem um documento para tal?
- toda saída tem nota fiscal?
- se a saída é feita por uma transportadora, correio ou motoboy é criado um
romaneio?
- é possível a saída de produtos que não sejam vendas (feiras,
demonstração, vendas em consignação)? Como tratar isso? Existirá documento
de saída?
- como serão tratadas as quebras? Existe documento para tal?
- produtos para mostruário são dados saídas do Almoxarifado ou é
identificado em local de armazenamento na logística?

Tem muito mais perguntas que isso, no entanto é um bom começo.

Lembrando. Toda transferência de mercadorias entre matriz x filial, filial x
filial, depósito x ambos, desde que em endereços distintos (obviamente terão
razões sociais distintas) deve ser emitido NF de transferência (Isso é Lei).
Dentro da mesma empresa é um caso de logística e que devemos tratar, pois
sempre devemos saber onde está a mercadoria (é o ideal).

Outras perguntas?
- Quem cadastra o produto, setor de compras ou almoxarifado?
- Quem cadastra o fornecedor, setor de compras ou almoxarifado?
- Quem cadastra o cliente, o setor de Vendas ou Crédito ou almoxarido?(EHEHEH)

Outras discussões que devemos abordar é que informações o Financeiro,
Compras, Vendas, Contabilidade e outros setores necessitam do Controle de
Estoque (preferia chamar de Almoxarifado).


Espero ter contribuído.



Alecindro



Quoting Wagner Bonfiglio [EMAIL PROTECTED]:

 Eu tenho algum conhecimento e algumas horas livres por dia, gostaria
 de entrar num projeto assim..

 Sou novo na lista e não acompanhei a discussão, mas posso ajudar no
 desenvolvimento sim!

 2008/6/24 Ribamar Sousa [EMAIL PROTECTED]:
 Desculpem-me se não estou conseguindo acompanhar o debate, acontece que o
 Coutinho me fez um convite e aceitei.
 Sinceramente estou sem tempo de ler e responder. Andei lendo boa parte e
 gostei muito da idéia do projeto e espero que não seja reinventar a roda.

 Mesmo que eu não esteja sem tempo mas fico contente pois o assunto esta em
 ótimas mãos. Para constar, se for preciso eu tenho um servidor com espaço
 ilimitado, é, ilimitado. Se precisarem de espaço e da criação de um portal
 num piscar de olhos, contem comigo.

 2008/6/23 Rudinei Dias [EMAIL PROTECTED]:

 Sugestão.

 Visto a dificuldade de achar software de estoque bom e aberto na net, e a
 vontade do Ribamar em liberar seu esforço de modelagem, poderíamos fazer um
 grupo para desenvolver o core do negócio, todo com implementação m pl/pgsql.
 Assim ficaria facil de desenvolver a interface em qualquer linguagem de
 programação, seja web ou desktop.
 Ai sim pensar em algo abrangente, bem genérico.



 --
 Ribamar FS - [EMAIL PROTECTED]
 http://ribafs.net
 ___
 pgbr-geral mailing list
 pgbr-geral@listas.postgresql.org.br
 https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


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




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

Re: [pgbr-geral] Modelando um Controle de Estoque

2008-06-25 Por tôpico Alexsandro Haag

Como comentei antes, acho que seria interessante trabalharmos sobre o 
ER, pois somente assim conseguiremos demonstrar melhor o que falamos. Se 
for relatar todo o detalhamento de tabelas de movimento e filhas vai 
ficar longo e nosso tempo geralmente é curto.


Do contrário acabamos falando de um único ponto sem demonstrar toda a 
estruturação do ER, e parece como comentado abaixo, que se está falando 
de um único tabelão para tudo. E com certeza não é disso que estou falando.




Jocimar de Oliveira escreveu:

On Tuesday 24 June 2008 16:52:50 Alexsandro Haag wrote:
  

Leandro DUTRA escreveu:


2008/6/24 Alexsandro Haag [EMAIL PROTECTED]:
  

Pode ser sim. Dá prá fazer separado. Mas normalmente é uma mesma
tabela, pois é tudo movimento de estoque.


Então há uma tabela com movimento de estoque, e outra específica
para cada tipo de movimento de estoque.  Se não, vira bagunça.
  

Não entendi por que bagunça? teria apenas uma campo indicando a
CFOP e dentro da tabela de CFOPs um qualificador de saída ou entrada.




Como ficaria a movimentação no momento do faturamento para entrega 
futura (não baixa estoque), e o faturamento que acompanha as 
mercadorias referente a entrega futura (baixa estoque) ?


O movimento dos produtos num único arquivo é interessante para registrar 
apenas a movimentação, da qual vêm das saídas (NF, Ordem de 
Serviço/Ordem de produção, etc ...) e das entradas (NF, Romaneios de 
entrada, entrada por produção).


Não consigo ver um único arquivo para controlar várias origens de 
entradas e saídas de produtos, isto fazendo referências com vários 
campos para tal identificação. Aconselho fazer a movimentação dos 
produtos num arquivo separado, mas que tal arquivo não seja a tabela 
filha de várias origens, realmente ficaria uma tabela com uma 
infinidade de campos.


Na questão de códigos fiscais, é algo muito complicado para simplificar 
como entrada e saída de mercadoria, já que existe muitos códigos 
fiscais que não geram tal movimentação, por exemplo, como ficaria as 
entradas dos documentos com modelo:

06 - Energia elétrica,
08 a 11 que são conhecimentos de fretes que acompanham mercadoria ou que 
realmente são documentos de faturamento de transportadoras,

modelo 22 - Telecomunicação, que pode ser compra ou venda da mesma.

Imagina que teríamos que cruzar modelo fiscal x código fiscal x situação 
tributária x alíquota de ICMS x alíquota de IPI.


Venho desenvolvendo há quase 20 anos, e não consigo ver uma 
centralização de tabelas para diminuir, pois isto vai aumentar e 
muito o tamanho de registros e irá gerar muitos, mas muitos problemas 
para gravar e ler estas informações, que no meu ponto de vista seria um 
trabalho para ser jogado e iniciado um novo.


Vou continuar acompanhando estes e-mail's, pois achei interessante o 
ponto de vista de cada um que foi postado. legal !


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

Re: [pgbr-geral] Modelando um Controle de Estoque

2008-06-25 Por tôpico Jocimar de Oliveira

O que coloquei abaixo é parte de um movimento de estoque, e não foje ao 
que postei.

Por favor, qual o real objetivo que deverá atender ?, pois no mencionado 
abaixo não coloquei movimentação por cupom fiscal e negociação com 
clientes onde envolve custo de última entrada com várias classes para 
formação de preço.

Acredito que seria interessante ter qual o objetivo final deste 
trabalho, o quê ele irá atender e informar.


On Wednesday 25 June 2008 08:00:08 Alexsandro Haag wrote:
 Como comentei antes, acho que seria interessante trabalharmos sobre o
 ER, pois somente assim conseguiremos demonstrar melhor o que falamos.
 Se for relatar todo o detalhamento de tabelas de movimento e filhas
 vai ficar longo e nosso tempo geralmente é curto.

 Do contrário acabamos falando de um único ponto sem demonstrar toda a
 estruturação do ER, e parece como comentado abaixo, que se está
 falando de um único tabelão para tudo. E com certeza não é disso que
 estou falando.

 Jocimar de Oliveira escreveu:
  On Tuesday 24 June 2008 16:52:50 Alexsandro Haag wrote:
  Leandro DUTRA escreveu:
  2008/6/24 Alexsandro Haag [EMAIL PROTECTED]:
  Pode ser sim. Dá prá fazer separado. Mas normalmente é uma mesma
  tabela, pois é tudo movimento de estoque.
 
  Então há uma tabela com movimento de estoque, e outra específica
  para cada tipo de movimento de estoque.  Se não, vira bagunça.
 
  Não entendi por que bagunça? teria apenas uma campo indicando
  a CFOP e dentro da tabela de CFOPs um qualificador de saída ou
  entrada.
 
  Como ficaria a movimentação no momento do faturamento para entrega
  futura (não baixa estoque), e o faturamento que acompanha as
  mercadorias referente a entrega futura (baixa estoque) ?
 
  O movimento dos produtos num único arquivo é interessante para
  registrar apenas a movimentação, da qual vêm das saídas (NF, Ordem
  de Serviço/Ordem de produção, etc ...) e das entradas (NF,
  Romaneios de entrada, entrada por produção).
 
  Não consigo ver um único arquivo para controlar várias origens de
  entradas e saídas de produtos, isto fazendo referências com vários
  campos para tal identificação. Aconselho fazer a movimentação dos
  produtos num arquivo separado, mas que tal arquivo não seja a
  tabela filha de várias origens, realmente ficaria uma tabela com
  uma infinidade de campos.
 
  Na questão de códigos fiscais, é algo muito complicado para
  simplificar como entrada e saída de mercadoria, já que existe
  muitos códigos fiscais que não geram tal movimentação, por exemplo,
  como ficaria as entradas dos documentos com modelo:
  06 - Energia elétrica,
  08 a 11 que são conhecimentos de fretes que acompanham mercadoria
  ou que realmente são documentos de faturamento de transportadoras,
  modelo 22 - Telecomunicação, que pode ser compra ou venda da mesma.
 
  Imagina que teríamos que cruzar modelo fiscal x código fiscal x
  situação tributária x alíquota de ICMS x alíquota de IPI.
 
  Venho desenvolvendo há quase 20 anos, e não consigo ver uma
  centralização de tabelas para diminuir, pois isto vai aumentar e
  muito o tamanho de registros e irá gerar muitos, mas muitos
  problemas para gravar e ler estas informações, que no meu ponto de
  vista seria um trabalho para ser jogado e iniciado um novo.
 
  Vou continuar acompanhando estes e-mail's, pois achei interessante
  o ponto de vista de cada um que foi postado. legal !

 Esta mensagem foi verificada pelo E-mail Protegido Terra.
 Atualizado em 25/06/2008



-- 
Saudações,

Jocimar de Oliveira
www.jocimar.com.br
(42) 8402-3035
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Modelando um Controle de Estoque

2008-06-25 Por tôpico Dickson Guedes

[EMAIL PROTECTED] escreveu:
 O tópico em questão é sobre Controle de Estoque. Mas vi diversas
 manifestações que, creio, fogem um pouco a controle de Estoque, que seriam
 como vender, a quem vender, como comprar, de quem comprar.

Apenas reforçando, já foi citado nesse mesmo tópico o Sistema Stoq que 
se propõe a fazer isso. Como o Riba falou, cuidado com a re-invenção da 
roda.

Quem sabe, ao invés disso, o grupo de interessados poderia reunir 
esforços e ajudar no projeto já existente, já que o Stoq utiliza o nosso 
elefantinho e poderia ser uma boa forma de colocar em prática todo esse 
conhecimento aqui existente.


Apenas uma opnião :)

-- 
[]s
Dickson S. Guedes
-
Projeto Colmeia - Curitiba - PR
(41) 3254-7130 ramal: 27
http://pgcon.postgresql.org.br
http://makeall.wordpress.com/
http://planeta.postgresql.org.br/
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Modelando um Controle de Estoque

2008-06-25 Por tôpico Alexsandro Haag

O Stoq inclusive não faz apenas isso. Ele tem também outros módulos: 
controle financeiro, ECF, CRM e outros.


Uma coisa legal dele é que suas versões podem ser atualizadas via apt-get.

Esse é o link onde falam sobre ajuda no desenvolvimento: 
http://www.stoq.com.br/index.php?option=com_contenttask=viewid=42Itemid=60 
http://www.stoq.com.br/index.php?option=com_contenttask=viewid=42Itemid=60


Dickson Guedes escreveu:

[EMAIL PROTECTED] escreveu:
  

O tópico em questão é sobre Controle de Estoque. Mas vi diversas
manifestações que, creio, fogem um pouco a controle de Estoque, que seriam
como vender, a quem vender, como comprar, de quem comprar.



Apenas reforçando, já foi citado nesse mesmo tópico o Sistema Stoq que 
se propõe a fazer isso. Como o Riba falou, cuidado com a re-invenção da 
roda.


Quem sabe, ao invés disso, o grupo de interessados poderia reunir 
esforços e ajudar no projeto já existente, já que o Stoq utiliza o nosso 
elefantinho e poderia ser uma boa forma de colocar em prática todo esse 
conhecimento aqui existente.



Apenas uma opnião :)

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

Re: [pgbr-geral] Modelando um Controle de Estoque

2008-06-24 Por tôpico Rudinei Dias

Sugestão.

Visto a dificuldade de achar software de estoque bom e aberto na net, e a
vontade do Ribamar em liberar seu esforço de modelagem, poderíamos fazer um
grupo para desenvolver o core do negócio, todo com implementação m pl/pgsql.
Assim ficaria facil de desenvolver a interface em qualquer linguagem de
programação, seja web ou desktop.
Ai sim pensar em algo abrangente, bem genérico.

É uma sugestão e me candidado para fazer parte do projeto.

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

Re: [pgbr-geral] Modelando um Controle de Estoque

2008-06-24 Por tôpico Leandro DUTRA

2008/6/23 Rudinei Dias [EMAIL PROTECTED]:

 Visto a dificuldade de achar software de estoque bom e aberto na net

Adempière, Compière não atendem?

Só para evitar duplicação de esforços...


-- 
skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra
+55 (11) 3040 7300 r155 gTalk: xmpp:[EMAIL PROTECTED]
+55 (11) 9406 7191 ICQ/AIM: aim:GoIM?screenname=61287803
+55 (11) 5685 2219 MSN: msnim:[EMAIL PROTECTED]
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Modelando um Controle de Estoque

Pode ser sim. Dá prá fazer separado. Mas normalmente é uma mesma tabela, 
pois é tudo movimento de estoque. Pode ser saída, entrada, 
transferência, saída para empréstimo, para venda, etc. Normalmente é uma 
tabela e o que define se é entrada/saída é a CFOP.


Não se trata de transformar qualquer coisa em qualquer coisa. Apenas 
estava me referindo a casos reais e casos ideais. Infelizmenete são 
coisas diferentes.


Em nenhum momento me referi a que fosse utilizado um mesmo CPF/CNPJ para 
pessoas diferentes, mas em alguns casos para variações da mesma pessoa.


Compras e Vendas são bastante semelhantes, só o que muda é que um entra 
no estoque e outro sai.


A questão de Regras Rígidas pode engessar o sistema. Temos que ter 
este cuidado, do contrário um usuário vai acabar optando por retirar 
algo do estoque sem passar pelo sistema devido a dificuldade e 
burocracia para fazê-lo. E desta forma nenhum controle de estoque funciona.




Ribamar Sousa escreveu:
2008/6/23 Leandro DUTRA [EMAIL PROTECTED] 
mailto:[EMAIL PROTECTED]:


 Conheço inúmeros casos reais
 onde há várias vezes, pelas mais diferentes razões, clientes
diferentes
 cadastrados com o mesmo CPF ou mesmo CNPJ.

Tem de ver se as razões são razoáveis, me parece mais um defeito de
modelagem exigindo gambiarras.

Arriscando: se formos agir assim poderemos transformar qualquer coisa 
em qualquer coisa.
Sou mais por cada coisa tem seu papél separado, normalizado, isolado e 
com regras rígidas.
Se houver flexibilidade de um cara usar o CPF do outro, do filho do 
dono poder retirar algum produtoi sem passar pelo sistema, então a 
coisa vira boteco da esquina e não precisa de um sistema.


 Outra coisa que vejo que poderia ser unificado é o cadastro de 
Pedidos. O

 pedido pode ser de Venda, mas também um pedido de Compra.
Então mais uma vez, seria uma entidade-pai pedidos e um arco de

entidades-filhas de vendas, compras, serviços, o que for.


Acho que vendas e compras são coisas bem diferentes: entrada e saída 
do estoque.


--
Ribamar FS - [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
http://ribafs.net


___
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] Modelando um Controle de Estoque


Tenho que concordar.
Mas o fato de se fazer separado não chega a estar errado, apenas a mim 
parece um pouco desnecessário e em alguns momentos vai gerar maior 
dificuldade de controle.


Mas ainda defendo o padrão como sugestão, não imposição. Claro que 
muitos pensam diferente, mas uma opção entre fazer junto ou separado 
sempre vai em algum momento ser percebido se foi uma decisão certa ou 
não num passo de integração seguinte. Aí aos poucos o modelo vai se 
moldando e sendo corrigido. Não proponho nada imutável.




Leandro DUTRA escreveu:

2008/6/23 Ribamar Sousa [EMAIL PROTECTED]:
  

Acho que vendas e compras são coisas bem diferentes: entrada e saída do
estoque.



Mas ambos são movimentos...

...e aí está o problema de modelos de dados padrão: cada um classifica
duma maneira diferente.

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

Re: [pgbr-geral] Modelando um Controle de Estoque

2008-06-24 Por tôpico Mozart Hasse

Leandro,


2008/6/23 Mozart Hasse [EMAIL PROTECTED]:
 Não vejo futuro. Conheci gente que não vê futuro nem em unificação de
 sintaxe SQL e estruturas de bancos de dados, que dirá em unificação de
 modelagem.

Leandro DUTRA:
Não sei se entendi a parte de estruturas ? a sintaxe SQL certamente
deveria ser unificada. Mas não será.


Eu me referi a 'estruturas' como as outras coisas que estão nos bancos de
dados 
hoje em dia além das tabelas 'físicas' e índices. Coisas como Triggers,
Views, 
Chaves estrangeiras, Stored Procedures, Rules, Defaults, Functions, Domains,
etc. 
Pode-se modelar de forma diferente se for do interesse do analista usar alguns

desses recursos específicos a determinado banco de dados. Perde-se a 
compatibilidade (o que para muitos é um preço alto demais), porém em alguns

casos ganha-se um nível de produtividade que viabiliza muitos negócios.


 Unificar o modelo implicaria em aceitar um desempenho horrível para
certas
 operações

 Teoricamente não, pelo menos não no modelo relacional. Mas com SQL, sim.

O desempenho dos bancos de dados na prática está muito aquém do desempenho
esperado conceitualmente, ao menos em várias tabelas de milhões de
registros
que eu tive de remodelar por causa de lentidão. Quando o modelo cresce
demais
(como em qualquer ERP), passamos a ter dezenas de consultas diferentes sobre
a mesma tabela de milhões de registros, e nem sempre (nas versões antigas do

Postgres raramente) o otimizador sabe que fazer com tantos JOINs para deixar 
o desempenho aceitável.


 ou em torná-lo tão genérico que consultar qualquer picuinha se
 tornaria uma jornada épica por dúzias de tabelas radicalmente
normalizadas

 Visões existem para isso...

Quando *um monte* de tabelas puder ser visto de *dúzias* de maneiras
diferentes, 
visões passam a ser um problema, pois o desenvolvedor sempre vai preferir
pegar 
uma ou duas colunas prontas de uma das visões disponíveis (assumindo que ele

seja um gênio da documentação e nomenclatura e *ache* a visão certa no
meio 
de todas as outras, o que em termos práticos é muito difícil) ao invés de

montar um SQL só para aquela situação. 
Se a visão tiver JOINs com tabelas pouco usadas, UNIONs, SubSELECTs ou
funções 
de agregação e o desenvolvedor *não* usar todos os campos, o otimizador 
dificilmente vai conseguir dar um tempo de resposta decente comparado à
consulta 
específica para aquela situação. Quando isso acontece em larga escala se 
transforma num desastre que inviabiliza a aplicação, independente da
quantidade de
CPUs, discos SCSI e pentes de memória disponíveis.

Bom, aí até pode-se questionar se o número de objetos de banco de dados
seria tão 
grande a ponto de ter estes problemas numa aplicação 'pequena' como um
controle
de estoque. Bom, se quiser no futuro integrá-la com um ERP, meu parecer é de
que sim.

Atenciosamente,


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] Modelando um Controle de Estoque


E quando surgir a tranportadora? Criamos outra tabela?
Por que? Da forma exemplificada se resolve pelo sistema, sem necessidade 
de mudar programa.

Sinceramente, não vejo complexidade nisso.

Leandro DUTRA escreveu:

2008/6/23 Ribamar Sousa [EMAIL PROTECTED]:
  

EMPRESA: ALEX

TIPOS_DE_EMPRESA (FUNCIONÁRIO,CLIENTE,FORNECEDOR, UNIDADE ORGANIZACIONAL)
EMPRESA_TIPO: ALEX - (FUNCIONÁRIO,CLIENTE)
  

Acho que isso não confronta com a normalização, realmente pelo contrário,
mas a coisa deve ser feita com  calma, pois parece ficar mais complexa.



Desnecessariamente complexo.

Basta declarar pessoa, cliente ou fornecedor.  Três tabelas.

Daí pessoa jurídica ou física, mais duas tabelas.

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

Re: [pgbr-geral] Modelando um Controle de Estoque

Tem também o Openbravo, baseado inicialmente no Compiére. Claro que 
poderia se partir daí. Já andei dando uma estudada nele e tenho ele 
instalado.


É um caso de avaliar a curva de aprendizado para entendê-los e talvez 
partir de um destes. Estão hoje bem maduros e já com bastante complexidade.

Por isso comentei da curva de aprendizado. Tem que se pesar esta questão.

Mas mesmo que se opte por desenvolver algo novo podemos nos inspirar 
muito fortemente nestes projetos.


Sei que um ponto forte deles é o Dicionário que possuem, permitindo 
que se acrescente campos em tabelas e até novas tabelas pelo runtime, 
sem necessitar programação. Eles têm um dicionário assim como o 
Postgresql/Oracle/demais BDs tem também dos objetos do schema.


Isso considero complexidade de modelagem. Não deve ter sido fácil fazer 
isso.




Leandro DUTRA escreveu:

2008/6/23 Rudinei Dias [EMAIL PROTECTED]:
  

Visto a dificuldade de achar software de estoque bom e aberto na net



Adempière, Compière não atendem?

Só para evitar duplicação de esforços...


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

Re: [pgbr-geral] Modelando um Controle de Estoque

2008-06-24 Por tôpico Leandro DUTRA

2008/6/24 Alexsandro Haag [EMAIL PROTECTED]:
 Pode ser sim. Dá prá fazer separado. Mas normalmente é uma mesma tabela,
 pois é tudo movimento de estoque.

Então há uma tabela com movimento de estoque, e outra específica para
cada tipo de movimento de estoque.  Se não, vira bagunça.


 Em nenhum momento me referi a que fosse utilizado um mesmo CPF/CNPJ para
 pessoas diferentes, mas em alguns casos para variações da mesma pessoa.

Mais uma vez, então tem de haver uma tabela pessoa, outras duas
pessoas física e jurídica, com respectivamente chaves CNPF e CNPJ (por
exemplo), e aí derivando dessas outras mais específicas para essas
variações.

O que não se pode jamais mudar é a chave forte e natural, mesmo que,
por algum acaso, não natural.


 A questão de Regras Rígidas pode engessar o sistema. Temos que ter este
 cuidado, do contrário um usuário vai acabar optando por retirar algo do
 estoque sem passar pelo sistema devido a dificuldade e burocracia para
 fazê-lo. E desta forma nenhum controle de estoque funciona.

Esse problema é o do modelo incompleto, não de regras rígidas.


-- 
skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra
+55 (11) 3040 7300 r155 gTalk: xmpp:[EMAIL PROTECTED]
+55 (11) 9406 7191 ICQ/AIM: aim:GoIM?screenname=61287803
+55 (11) 5685 2219 MSN: msnim:[EMAIL PROTECTED]
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Modelando um Controle de Estoque

Leandro DUTRA escreveu:

2008/6/23 Alexsandro Haag [EMAIL PROTECTED]:

Se for o caso, chame de PESSOA então. O nome da entidade não altera a
questão. O que me refiria era sobre poder manter o cadastro na mesma
entidade. Independente do nome que tiver.

Mas tem de separar as características específicas, não pode ficar só
um tabelão. Por isso a idéia (ortodoxa, por sinal) de entidades que
se vão especializando.

Sim, os detalhes são tabelas que vão se agregando conforme os atributos
diferentes vão sendo definidos.

Eu os criaria como chaves secundárias, não como primárias ou únicas.

Numa tabela pessoa, nem estarão presentes. Mas numa de pessoa física
e noutra de jurídica, sim, e como chave. Preferencialmente, mas não
necessariamente, primárias (pressupondo que, num ERP, só vamos ter
pessoas assim identificáveis).

Isso muitas vezes depende de como o cliente quer tratar sua base. Por
exemplo ele pode não possuir 2 empresas com CNPJs diferentes, mas quer
trabalhar como se tivésse, devido a alguma logística sua. Pode ter por
exemplo a indústria num prédio dos fundos e a loja no prédio da frente e vai
querer fazer uma transferência de produto de uma unidade para outra.

Então é um erro de modelagem. Não são duas empresas; são dois
endereços duma mesma empresa.

Que seja, mas como faria uma transferência de uma empresa para a mesma?
Não existe mesma empresa com endereços diferentes, se os endereços
são diferentes obrigatoriamente é outra empresa (filial).
Mas aí voltamos na questão. Se o cliente não quer registrar uma
filial vamos impedi-lo de controlar o estoque pelo sistema e obrigá-lo a
fazer manual neste caso?

Claro que há outras maneiras de tratar isso, poderíamos por exemplo obrigar
o cliente a registrar uma outra empresa/filial para a loja, mesmo elas
estando no mesmo endereço, o que seria o mais correto a fazer. Mas na
prática isso não é flexível para o cliente.

Faça o que é correto. Como apresentar é outro assunto.

E como a gente faria esse tipo de gambiarra num modelo de referência.

Não se trata de Gambiarra, pois estamos garantindo a integridade
através do ID sequencial. Veja como outros ERPs fazem... Pode olhar por
exemplo os já citados... Compiére, Adempiére, OpenBravo, Stoq
(nacional). Outro detalhe... Será que existe CNPJ/CPF em outros países?
Vejo estes dois campos como características adicionais da entidade
PESSOA, não chaves primárias.

Creio que podemos orientar o cliente a fazer da forma correta, mas
se quiser trabalhar errado é opção dele. No nosso dia-dia vemos inúmeros
exemplos de bons administradores que são extremamente sistêmicos e se
preocupam com padrões. Já há outros que, conseguem ter rentabilidade
mesmo sem os controles que as vezes consideramos importantes. E por mais
que insistimos que ele não está fazendo da melhor forma sempre será
opção dele.

Ou poderíamos ainda acrescentar uma sequencia que complementasse o CNPJ e a
PK ficaria CNPJ + sequencia, mas acho neste caso seria mais simples criar ID
sequencial e uma rotina para alertar, mas não bloquear o usuário quando
tentar criar um cliente que já exista no cadastro.

BT! Errado! É para isso que existem chaves, para evitar duplicados.

Novamente digo depende do escopo do sistema. Eu não considero CNPJ e/ou
CPF chaves suficientemente fortes para isso, pelos motivos já relatados.
Um ID sequencial continua sendo para mim uma melhor opção.

E reforço o que já disse antes o Ribamar, não para iniciar uma discussão
danosa, mas para nossa qualidade de vida, peço mais cuidado com a forma
como coloca tuas opiniões. Preocupe-se em não agredir por não concordar,
pensando antes de escrever.

BT! Errado! - é disso que estou falando. Nenhum de nós é dono da verdade. Poderia substituir
por algo como Discordo, Não acho que está correto. É mais educado desta forma. Tome
por favor como sugestão, não ofensa.
Obrigado!

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

Re: [pgbr-geral] Modelando um Controle de Estoque

É que muitas vezes se não pensamos nestes detalhes que a princípio 
parecem trazer complexidade, depois do sistema feito acabamos tendo 
muita dificuldade para mudar.
Por isso acho que uma modelagem inicial mais complexa vai garantir mais 
flexibilidade depois.


Quanto ao que falou abaixo, realmente pode ser que não compreendi todos 
os relacionamentos do teu modelo. Assim que tiver um tempo dou uma 
olhada melhor e te respondo OK?


Veja que de estoque posso chegar a produtos e cheguei a fazer como você 
sugere, acontece que fechou-se um círculo de relacionamentos. Não há 
necessidade, pois se de estoque vou a compra-itens e desta vou a 
produto, tá resolvido, ou não?


O negócio hoje aqui tá bem corrido...

Obrigado!
Att.
Alex

Ribamar Sousa escreveu:
2008/6/23 Alexsandro Haag [EMAIL PROTECTED] 
mailto:[EMAIL PROTECTED]:


Concordo, temos que ter um ponto de partida.

Sobre a modelagem em geral eu faria algumas sugestões:

* Ao invés de um cadastro de clientes e outro de fornecedores
  poderia haver apenas uma tabela de cadastro de Empresas ou
  Pessoas (como achar melhor), com isso um fornecedor pode em
  qualquer momento se tornar cliente sem que seja necessário
  um novo cadastro ou importação de cadastro. Assim como um
  funcionário pode ser cliente ou fornecedor em qualquer
  momento. Vi que você já tem um cadastro de empresas, que
  deve estar sendo utilizado como uma Unidade Organizacional.
  Esta poderia também continuar sendo uma empresa sem problemas.
* Para melhor viabilizar a unificação de cadastro acima (não
  estou quebrando regras de normalização, pelo contrário)
  poderíamos aí criar um novo cadastro de TIPOS_DE_EMPRESA e
  uma outra chamada EMPRESA_TIPOS (que conteria os tipos
  associados a determinada empresa) Ex.:
* EMPRESA: ALEX
* TIPOS_DE_EMPRESA
  (FUNCIONÁRIO,CLIENTE,FORNECEDOR,
  UNIDADE ORGANIZACIONAL)
* EMPRESA_TIPO: ALEX -
  (FUNCIONÁRIO,CLIENTE)

Acho que isso não confronta com a normalização, realmente pelo 
contrário, mas a coisa deve ser feita com  calma, pois parece ficar 
mais complexa.


   *


*  Outra sugestão seria utilizar um código sequencial para o
  cadastro desta empresa (fornecedores,funcionários,clientes),
  pois os campos de CPF e CNPJ como chaves primárias pode
  limitar o sistema. Conheço inúmeros casos reais onde há
  várias vezes, pelas mais diferentes razões, clientes
  diferentes cadastrados com o mesmo CPF ou mesmo CNPJ. Além
  disso, da forma como está definida a sua modelagem o sistema
  só venderá para pessoa física, nunca para pessoa jurídica.

Como já disse, acredito que um sistema sério não deve ter essas 
brechas.


   *


* Eu chamaria a entidade Almoxarifados de algo mais
  genérico, como Centros de Armazenagem ou algo ainda mais
  genérico, pois muitas vezes os estoques estão espalhados
  pela empresa, não somente dentro de um ou mais
  almoxarifados. (Mas claro isso é só nomenclatura, nada
  impediria a utilização com este nome);

Concordo.

   *


* Outra coisa que vejo que poderia ser unificado é o cadastro
  de Pedidos. O pedido pode ser de Venda, mas também um pedido
  de Compra. Além disso uma venda também é feita a partir de
  um produto e não vi chave estrangeira do produto para o seu
  item de pedido.

Também concordo, mas também com calma.

   *


* A sua tabela Estoque também não tem produto associado.
  Creio que todo controle de estoque deve ser feito baseado
  nos produtos (matéria-prima, intermediários, produtos de venda).

Veja que de estoque posso chegar a produtos e cheguei a fazer como 
você sugere, acontece que fechou-se um círculo de relacionamentos. Não 
há necessidade, pois se de estoque vou a compra-itens e desta vou a 
produto, tá resolvido, ou não?



Bom, essas são minhas sugestões, espero que não as leve a mal.
As intenções são boas, e talvez eu esteja enxergando as formas de
implementação de Estoque que já trabalhei, que foram sempre
semelhantes ao que expus acima.

Aguardo as considerações do pessoal da lista... e mais uma vez
parabenizo o Ribamar pela iniciativa.


Grato Alex e se for por min eu levo muito a bem, pois foi essa a 
intenção, gerar debate para que isso venha a motivar os colegas (e a 
min) a encararem o assunto com mais seriedade. Geralmente quando se 
vai desenvolver um sistema, criar um banco, simplesmente abrimos o 
psql ou pgadmin e o criamos. As consequências futuras algumas vezes 
são bem chatas. Ainda tem mais, geralmente o sistema ou banco

Re: [pgbr-geral] Modelando um Controle de Estoque

2008-06-24 Por tôpico jfchaves

Quoting Alexsandro Haag [EMAIL PROTECTED]:

Sim, me refiro a uma referência conceitual, um ponto de partida universal.
Não algo rígido, seria uma sugestão livre de modelo ER para
implementação de ERP.

Existem sim situações muito específicas, mas há outras que são
conceituais, como MRP, MPS, etc.

(??) Preciso estudar mais, não tenho a mínima idéia do que seja isso :) .

Isso permitiria também que surgissem diversos projetos de software
com um mesmo ponto de partida que pudessem se integrar pela camada
de dados facilmente. Algo como um Kernel ER.

Já pensei nisso, e apresentei a idéia (núcleo, em lugar de kernel) na
antiga postgresql-br, mas como não não enviei nada palpável como o
Ribamar, não houve muito interesse, minhas idéias estavam em um
blog, mas parece que a atualização do meu hosting para o php5 jogou
o para um limbo (espero que temporário), essa é um cópia em cache
do google:

http://64.233.169.104/search?q=cache:JN-jOcBkt24J:www.brdados.com.br/nuke/index.php+brdados.com.br+nucleo+qt+c%2B%2B+javahl=pt-BRct=clnkcd=1lr=lang_ptclient=iceweasel-a

as 3 primeiras notícias que estão logo abaixo foram um local que usei
para um bookmark na web (não conhecia del.icio.us), a última, foi meu
último suspiro.

Espero, quando estiver em casa poder dar meus pitacos, sobre essa discução.

...

[]'s
--
Johnny Taylor

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

Re: [pgbr-geral] Modelando um Controle de Estoque

Existe um projeto nacional de código aberto chamado stoq 
(www.stoq.com.br) modelado em Postgres e desenvolvido em Python.


Tem um espanhol chamado Openbravo e o Adempiére já citado.

O Compiére me parece que foi fechado novamente o código.

A motivação poderia ser não o fato de não existirem bons softwares nesta 
área, mas sim pelo aprendizado em si.


Ou poderíamos ainda auxiliar na evolução de alguns destes projetos. O 
Stoq por exemplo, acharia muito interessante uma interface WEB para ele. 
Poderia se usar o Django pelo fato do projeto já ser em Python ou talvez 
JSP e seus frameworks.


Além é claro, de estender suas funcionalidades.



Rudinei Dias escreveu:

Sugestão.

Visto a dificuldade de achar software de estoque bom e aberto na net, 
e a vontade do Ribamar em liberar seu esforço de modelagem, poderíamos 
fazer um grupo para desenvolver o core do negócio, todo com 
implementação m pl/pgsql.
Assim ficaria facil de desenvolver a interface em qualquer linguagem 
de programação, seja web ou desktop.

Ai sim pensar em algo abrangente, bem genérico.

É uma sugestão e me candidado para fazer parte do projeto.

Rudinei Dias


___
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] Modelando um Controle de Estoque

Existe um projeto nacional de código aberto chamado stoq 
(www.stoq.com.br) modelado em Postgres e desenvolvido em Python.


Tem um espanhol chamado Openbravo e o Adempiére já citado.

O Compiére me parece que foi fechado novamente o código.

A motivação poderia ser não o fato de não existirem bons softwares nesta 
área, mas sim pelo aprendizado em si.


Ou poderíamos ainda auxiliar na evolução de alguns destes projetos. O 
Stoq por exemplo, acharia muito interessante uma interface WEB para ele. 
Poderia se usar o Django pelo fato do projeto já ser em Python ou talvez 
JSP e seus frameworks.


Além é claro, de estender suas funcionalidades.



Rudinei Dias escreveu:

Sugestão.

Visto a dificuldade de achar software de estoque bom e aberto na net, 
e a vontade do Ribamar em liberar seu esforço de modelagem, poderíamos 
fazer um grupo para desenvolver o core do negócio, todo com 
implementação m pl/pgsql.
Assim ficaria facil de desenvolver a interface em qualquer linguagem 
de programação, seja web ou desktop.

Ai sim pensar em algo abrangente, bem genérico.

É uma sugestão e me candidado para fazer parte do projeto.

Rudinei Dias


___
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] Modelando um Controle de Estoque

2008-06-24 Por tôpico Leandro DUTRA

2008/6/24 Alexsandro Haag [EMAIL PROTECTED]:

 Que seja, mas como faria uma transferência de uma empresa para a mesma?

Tem de haver então dois locais de estoque na mesma empresa.  Simples.


 Não se trata de Gambiarra, pois estamos garantindo a integridade
 através do ID sequencial.

ID seqüencial não garante integridade nenhuma.  Eu posso simplesmente
colocar o mesmo dado quantas vezes quiser, se não houver chaves
naturais.


 Outro detalhe... Será que existe CNPJ/CPF em outros países?

Ótima pergunta.

De fato, não há.

Mas há equivalentes.  E aí a gente cai de novo na normalização e no
uso de visões para integrar os dados.


-- 
skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra
+55 (11) 3040 7300 r155 gTalk: xmpp:[EMAIL PROTECTED]
+55 (11) 9406 7191 ICQ/AIM: aim:GoIM?screenname=61287803
+55 (11) 5685 2219 MSN: msnim:[EMAIL PROTECTED]
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Modelando um Controle de Estoque




Leandro DUTRA escreveu:

2008/6/24 Alexsandro Haag [EMAIL PROTECTED]:
  

Pode ser sim. Dá prá fazer separado. Mas normalmente é uma mesma tabela,
pois é tudo movimento de estoque.



Então há uma tabela com movimento de estoque, e outra específica para
cada tipo de movimento de estoque.  Se não, vira bagunça.

  
   Não entendi por que bagunça? teria apenas uma campo indicando a CFOP 
e dentro da tabela de CFOPs um qualificador de saída ou entrada.
  

Em nenhum momento me referi a que fosse utilizado um mesmo CPF/CNPJ para
pessoas diferentes, mas em alguns casos para variações da mesma pessoa.



Mais uma vez, então tem de haver uma tabela pessoa, outras duas
pessoas física e jurídica, com respectivamente chaves CNPF e CNPJ (por
exemplo), e aí derivando dessas outras mais específicas para essas
variações.
  

   Sim, concordo. Nada do que falei impede esta configuração.
   Só para eu entender melhor o que falou acima... Qual seria a chave 
da tabela Pessoa? E qual seria a chave das tabelas Pessoa_fisica e 
Pessoa_juridica?

O que não se pode jamais mudar é a chave forte e natural, mesmo que,
por algum acaso, não natural.
  
   Mais uma vez reforço que a chave CNPJ ou CPF não é forte o 
suficiente para ser a principal, visto que serviria apenas para 
realidade nacional entre outras questões já levantadas. Ainda não vejo 
razão para utilizá-la ao invés de um ID sequencial.


  

A questão de Regras Rígidas pode engessar o sistema. Temos que ter este
cuidado, do contrário um usuário vai acabar optando por retirar algo do
estoque sem passar pelo sistema devido a dificuldade e burocracia para
fazê-lo. E desta forma nenhum controle de estoque funciona.



Esse problema é o do modelo incompleto, não de regras rígidas.
  


Acho que seria mais produtivo se trabalharmos em cima do modelo do 
Ribamar e fazer como ele já fez no início, publicar nele nossas 
sugestões, aí se percebe visualmente do que se está falando.


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

Re: [pgbr-geral] Modelando um Controle de Estoque




Leandro DUTRA escreveu:

2008/6/24 Alexsandro Haag [EMAIL PROTECTED]:
  

Tenho que concordar.



Obrigado!


  

Mas o fato de se fazer separado não chega a estar errado, apenas a mim
parece um pouco desnecessário e em alguns momentos vai gerar maior
dificuldade de controle.



Pelo contrário, está certo e é necessário: nem todos os atributos são comuns.
  

Sim, mas o que não é comum são tabelas complementares.

A 'maior dificuldade' é justamente a de fazer um sistema genérico,
robusto e escalável.

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

Re: [pgbr-geral] Modelando um Controle de Estoque

Se a idéia evoluir talvez seja o caso de criarmos uma lista a parte,
para não fugirmos do foco do Postgres na que estamos agora.

[EMAIL PROTECTED] escreveu:

Quoting Alexsandro Haag [EMAIL PROTECTED]:

Sim, me refiro a uma referência conceitual, um ponto de partida universal.
Não algo rígido, seria uma sugestão livre de modelo ER para
implementação de ERP.

Existem sim situações muito específicas, mas há outras que são
conceituais, como MRP, MPS, etc.

(??) Preciso estudar mais, não tenho a mínima idéia do que seja isso :) .

Isso permitiria também que surgissem diversos projetos de software
com um mesmo ponto de partida que pudessem se integrar pela camada
de dados facilmente. Algo como um Kernel ER.

http://64.233.169.104/search?q=cache:JN-jOcBkt24J:www.brdados.com.br/nuke/index.php+brdados.com.br+nucleo+qt+c%2B%2B+javahl=pt-BRct=clnkcd=1lr=lang_ptclient=iceweasel-a

as 3 primeiras notícias que estão logo abaixo foram um local que usei
para um bookmark na web (não conhecia del.icio.us), a última, foi meu
último suspiro.

Espero, quando estiver em casa poder dar meus pitacos, sobre essa discução.

...

[]'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] Modelando um Controle de Estoque

2008-06-24 Por tôpico Evandro Ricardo Silvestre

Leandro DUTRA wrote:
 2008/6/24 Alexsandro Haag [EMAIL PROTECTED]:
   
 Que seja, mas como faria uma transferência de uma empresa para a mesma?
 

 Tem de haver então dois locais de estoque na mesma empresa.  Simples.

   
Ou unidades de negocio diferentes. O nosso ERP é possível os 2 casos, 
transferências entre UN ou Locais de Estoque.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Modelando um Controle de Estoque