2011/7/19 Johnny Chaves jfcha...@brdados.com.br
Parece que esse é o maior problema *cultural*, tive resistência nesse
ponto,
incluindo a tentativa de não deixar buracos na sequência, até que o
Roberto
Melo (Mello?), da antiga lista me questionou (e há vários outros ao mesmo
tempo), o
Em 20 de julho de 2011 01:54, Euler Taveira de Oliveira
eu...@timbira.comescreveu:
Em 20-07-2011 01:11, Alexsander Rosa escreveu:
É muito mais fácil identificar o pedido 876232 do que o pedido João da
Silva + CPF + timestamp (como disse o Fabrizio, o João da Silva pode
fazer mais de um
Em ter 19 jul 2011, às 22:26:23, Euler Taveira de Oliveira escreveu:
Em 19-07-2011 17:49, Johnny Chaves escreveu:
Em seg 11 jul 2011, às 17:50:24, Leandro DUTRA escreveu:
2011/7/11 Alexsander Rosaalexsander.r...@gmail.com:
As pessoas estão acostumadas a receber um número de pedido quando
Em ter 19 jul 2011, às 22:57:37, Fabrízio de Royes Mello escreveu:
Em 19 de julho de 2011 22:26, Euler Taveira de Oliveira
eu...@timbira.comescreveu:
E por que não o pedido do João da Silva + CPF? Acho que seria muito mais
elegante o funcionário dizer: Seu João da Silva? Aqui está o seu
Em qua 20 jul 2011, às 09:45:26, Roberto Mello escreveu:
2011/7/19 Johnny Chaves jfcha...@brdados.com.br
Parece que esse é o maior problema *cultural*, tive resistência nesse
ponto,
incluindo a tentativa de não deixar buracos na sequência, até que o
Roberto
Melo (Mello?), da antiga
Em qua 20 jul 2011, às 09:56:39, Alexsander Rosa escreveu:
Em 20 de julho de 2011 01:54, Euler Taveira de Oliveira
eu...@timbira.comescreveu:
Em 20-07-2011 01:11, Alexsander Rosa escreveu:
É muito mais fácil identificar o pedido 876232 do que o pedido João da
Silva + CPF + timestamp
Em 20 de julho de 2011 11:38, Johnny Chaves jfcha...@brdados.com.brescreveu:
*Se* existir o tal talão isso é verdade, já passei por isso, e enquanto a
empresa usava as Fichas Brancas como eram chamadas, funcionava bem.
Quando decidiram eliminar as fichas e manter a mesma forma de trabalho,
Le 2011.J.20 11h31, Johnny Chaves a écrit :
Você e o Leandro me deram alguns choques na minha transição dbf-
SQL~relacional, que me ajudaram a acelerar os passos :) .
Muito obrigado! É muito bom se sentir um pouco útil de quando em vez…
--
Skype:leandro.gfc.dutra?chat Yahoo!:
Em 20-07-2011 09:56, Alexsander Rosa escreveu:
*Número de pedido é chave natural* desde antes do primeiro software de
automação comercial.
E quem disse que ao automatizar não podemos mudar o processo? Todos os
requisitos mudam (vide engenharia de requisitos) ao longo do tempo.
--
Euler
Em 20 de julho de 2011 13:45, Euler Taveira de Oliveira
eu...@timbira.comescreveu:
Em 20-07-2011 09:56, Alexsander Rosa escreveu:
*Número de pedido é chave natural* desde antes do primeiro software de
automação comercial.
E quem disse que ao automatizar não podemos mudar o processo? Todos
Em seg 11 jul 2011, às 17:50:24, Leandro DUTRA escreveu:
2011/7/11 Alexsander Rosa alexsander.r...@gmail.com:
Sim, obviamente, mas quem usaria CPF + NOME como chave primária de
CLIENTE (ou PESSOA)?
Péssimo exemplo, visto que essa definitivamente não é uma chave natural
válida.
Chaves
Em 19 de julho de 2011 17:49, Johnny Chaves jfcha...@brdados.com.brescreveu:
Alexsander, não quero ser grosso, mas como disse em outra mensagem esse
assunto já foi discutido dezenas de vezes na lista, mais na antiga do yahoo
do
que nessa, e os argumentos (racionais) que você apresenta já
Em 19-07-2011 17:49, Johnny Chaves escreveu:
Em seg 11 jul 2011, às 17:50:24, Leandro DUTRA escreveu:
2011/7/11 Alexsander Rosaalexsander.r...@gmail.com:
As pessoas estão acostumadas a receber um número de pedido quando
compram alguma coisa.
E por que não o pedido do João da Silva + CPF? Acho
Em 19 de julho de 2011 22:26, Euler Taveira de Oliveira
eu...@timbira.comescreveu:
E por que não o pedido do João da Silva + CPF? Acho que seria muito mais
elegante o funcionário dizer: Seu João da Silva? Aqui está o seu pedido. Do
que: Número? 7..9..5..7..2..3..9..5..8..2..3..7. Aqui está o
Le 2011.J.19 21h30, Alexsander Rosa a écrit :
A questão é: cada um faz o que quiser com as bases que administra. Se
alguém quiser usar CPF ou CNPJ como PK de pessoa (ou qualquer
especialização como cliente ou fornecedor) em nome da pureza
teórica, pode usar que estou me lixando.
Estás
Em 19-07-2011 22:57, Fabrízio de Royes Mello escreveu:
Em 19 de julho de 2011 22:26, Euler Taveira de Oliveira
eu...@timbira.com mailto:eu...@timbira.com escreveu:
E por que não o pedido do João da Silva + CPF? Acho que seria muito mais
elegante o funcionário dizer: Seu João da Silva?
Comentários no texto.
Em 19 de julho de 2011 22:26, Euler Taveira de Oliveira
eu...@timbira.comescreveu:
Em 19-07-2011 17:49, Johnny Chaves escreveu:
Em seg 11 jul 2011, às 17:50:24, Leandro DUTRA escreveu:
2011/7/11 Alexsander Rosaalexsander.r...@gmail.com:
As pessoas estão acostumadas a
Em 20-07-2011 01:11, Alexsander Rosa escreveu:
É muito mais fácil identificar o pedido 876232 do que o pedido João da
Silva + CPF + timestamp (como disse o Fabrizio, o João da Silva pode
fazer mais de um pedido). E mais: todo mundo sabe escrever João da
Silva após ter ouvido o nome por
Em 12 de julho de 2011 13:02, Leandro DUTRA
leandro.gfc.du...@gmail.comescreveu:
(...) CPF e CNPJ, por outro lado, podem ser chaves naturais (compostas,
se
necessário), mas não são boas chaves primárias pelos motivos expostos
anteriormente.
Motivos esses todos inválidos.
1) CPF
2011/7/13 Alexsander Rosa alexsander.r...@gmail.com:
1) CPF compartilhado por marido e esposa. O marido é um cliente, a esposa é
outro cliente. Se a chave primária simples for o CPF, um deles não poderá se
cadastrar. Neste caso é melhor usar uma chave artificial como código do
cliente.
De
Em 13 de julho de 2011 13:28, Leandro DUTRA
leandro.gfc.du...@gmail.comescreveu:
2011/7/13 Alexsander Rosa alexsander.r...@gmail.com:
1) CPF compartilhado por marido e esposa. O marido é um cliente, a esposa
é
outro cliente. Se a chave primária simples for o CPF, um deles não poderá
se
2011/7/13 Alexsander Rosa alexsander.r...@gmail.com:
Assim fica difícil manter o debate, você argumenta contra seus próprios
espantalhos... :-)
Minha impressão é que ainda não entendeste nada…
Encerrei por aqui, siga usando CPF e CNPJ como chave primária simples se
quiser.
Exatamente o
Comentários no texto:
Em 11 de julho de 2011 17:50, Leandro DUTRA
leandro.gfc.du...@gmail.comescreveu:
2011/7/11 Alexsander Rosa alexsander.r...@gmail.com:
Sim, obviamente, mas quem usaria CPF + NOME como chave primária de
CLIENTE
(ou PESSOA)?
Péssimo exemplo, visto que essa
2011/7/12 Alexsander Rosa alexsander.r...@gmail.com:
Comentários no texto:
Ufa, obrigado.
Em 11 de julho de 2011 17:50, Leandro DUTRA leandro.gfc.du...@gmail.com
escreveu:
Péssimo exemplo, visto que essa definitivamente não é uma chave natural
válida.
O exemplo CPF + NOME como chave
No meu ERP uso um parâmetro digitos_empresa (geralmente 4) para montar a
chave. Exemplo: o 1º cliente cadastrado na filial 7 fica com código 10007
que é mostrado como 1/7 no sistema. O cliente nº 357 da filial 24 fica com
código 3570024 e assim por diante. Como já foi discutido aqui antes, a chave
o CPF é reusado alguns anos depois do falecimento do titular e muitos
órgãos ṕublicos compartilham o mesmo CNPJ -- por exemplo, TODAS as escolas
estaduais do RS usam o CNPJ da Secretaria da Educação do estado.
Nada a ver com a discussão em questão.. acredito que CPF e CNPJ não podem
ser
diante. Mesmo se uma filial fechar, aquele numero fica inutilizado.
Eduardo Az
Dep.TI
EMBRASIS
+55(11)8125-3845 TIM
eduard...@embrasis.com.br
From: Fellipe Henrique
Sent: Monday, July 11, 2011 10:56 AM
To: Comunidade PostgreSQL Brasileira
Subject: Re: [pgbr-geral]Novato com uma dúvida, campo PK
Olá, não recebi as mensagens anteriores, parece que havia sido removido da
lista (bouncing(ss)?), então talvez repita algo que já foi dito... (peço
desculpas antecipadas)
Em seg 11 jul 2011, às 09:54:35, Alexsander Rosa escreveu:
No meu ERP uso um parâmetro digitos_empresa (geralmente 4)
*From:* Fellipe Henrique felli...@gmail.com
*Sent:* Monday, July 11, 2011 10:56 AM
*To:* Comunidade PostgreSQL Brasileirapgbr-geral@listas.postgresql.org.br
*Subject:* Re: [pgbr-geral]Novato com uma dúvida, campo PK sendo GUID
--
Atenciosamente,
Alexsander da Rosa
http://rednaxel.com
2011/7/11 Alexsander Rosa alexsander.r...@gmail.com:
…nem CPF nem CNPJ servem como PK: o CPF é
reusado alguns anos depois do falecimento do titular
Portanto, a chave natural inclui uma dimensão temporal. E bases de
dados temporais são um problema, digamos, interessante.
e muitos órgãos
2011/7/11 Alexsander Rosa alexsander.r...@gmail.com:
Sim, mas o OP estava falando sobre PK; o meu argumento é que CPF e CNPJ não
servem como PK há duplicidade nos dois: esposas com CPF de maridos, escolas
estaduais com CNPJ da Secretaria de Educação, etc. Com algo mais (nome,
etc) são
Sim, obviamente, mas quem usaria CPF + NOME como chave primária de CLIENTE
(ou PESSOA)?
Chaves primárias como código de cliente e número de pedido, compostas ou
não, são quase inevitáveis.
As pessoas estão acostumadas a receber um número de pedido quando compram
alguma coisa.
Em 11 de julho de
2011/7/11 Alexsander Rosa alexsander.r...@gmail.com:
Sim, obviamente, mas quem usaria CPF + NOME como chave primária de CLIENTE
(ou PESSOA)?
Péssimo exemplo, visto que essa definitivamente não é uma chave natural válida.
Chaves primárias como código de cliente e número de pedido, compostas
Peraí A técnica/teoria implementa as duas. As duas são feitas para serem
usadas. Use-as, inclusive no mesmo projeto, pois a adoção de uma não exclui
a adoção da outra. Ambas podem conviver em total harmonia.
2011/7/11 Leandro DUTRA leandro.gfc.du...@gmail.com
2011/7/11 Alexsander Rosa
Por favor, vamos seguir a netiqueta, RFC 1855… cortar os trechos da
mensagem a que não se respondeu, e colocar a resposta após o texto
relevante.
2011/7/11 Aldemir Vieira alde...@gmail.com:
Peraí A técnica/teoria implementa as duas. As duas são feitas para serem
usadas. Use-as, inclusive
Pelo que estou vendo vc quer trabalhar com uma aplicação off-line que
quando entre on-line faça o upload das informações trabalhadas localmente,
correto?
O campo serial nada mais é que uma constraint ON INSERT que busca o nextval
da sequence a ele associado. Você poderia simplesmente criar uma
Ah sim, note que a idéia do identificador de instalação e id de usuário são
para ajudar a evitar que a chave se repita em outra máquina. Nesse caso, seu
servidor central deveria ter uma tabela para ir registrando os
identificadores já utilizados para que quando vc instalasse a aplicação, ela
não
Entendi... só uma outra coisa.. como iniciante que sou... como faço pra usar
essa contrib ?
T.·.F.·.A.·. S+F
*Fellipe Henrique P. Soares*
Analista e Desenvolvedor de Softwares for Win32
Linux Administrator
Em 6 de julho de 2011 18:33, Dickson S. Guedes lis...@guedesoft.netescreveu:
Blz amigos, achei onde fazer o download da DLL...
T.·.F.·.A.·. S+F
*Fellipe Henrique P. Soares*
Analista e Desenvolvedor de Softwares for Win32
Linux Administrator
Em 8 de julho de 2011 17:04, Fellipe Henrique felli...@gmail.com escreveu:
Entendi... só uma outra coisa.. como
Bom dia amigos,
Sou desenvolvedor Delphi, e estou iniciando um projeto grande em que teremos
um banco multi-cliente e multi-empresa, com possíveis importação/exportação
de dados entre as empresas.
Em Firebird, que é o que eu uso, eu uso como PK um código integer.. o que dá
muito trabalho pra
Você não quer usar chave composta?
Bruno E. A. Silva.
2011/7/6 Fellipe Henrique felli...@gmail.com
Bom dia amigos,
Sou desenvolvedor Delphi, e estou iniciando um projeto grande em que
teremos um banco multi-cliente e multi-empresa, com possíveis
importação/exportação de dados entre as
Sim, a idéia é usar Chave Composta, mas usando integer seria complicado
quando fosse fazer a importação, pra ter que refazer os conflitos das FK...
usando GUID ele seria único no banco de dados inteiro, entao seria mais
fácil eu controlar as FK ao fazer as importacoes..
Bom, será que existe um
2011/7/6 Fellipe Henrique felli...@gmail.com:
Sim, a idéia é usar Chave Composta, mas usando integer seria complicado
quando fosse fazer a importação, pra ter que refazer os conflitos das FK...
Teu problema é de modelagem. Usar chaves naturais evitaria todo esse problema.
--
2011/7/6 Fellipe Henrique felli...@gmail.com:
Hum.. acredito que o problema esteja além da modelagem.
Não, é exatamente modelagem. Todo o problema que delineias é
decorrente do uso de chaves artificiais. Chaves naturais resolveriam
o problema. Há outras soluções, chaves naturais são a mais
Rapaz.. to meio lento ainda.. pensei, pensei, mas não consegui achar uma
forma de usar Chaves Naturais eliminar esse problema... voce poderia dar um
pequeno exemplo?
T.·.F.·.A.·. S+F
*Fellipe Henrique P. Soares*
Analista e Desenvolvedor de Softwares for Win32
Linux Administrator
Em 6 de
2011/7/6 Fellipe Henrique felli...@gmail.com:
Rapaz.. to meio lento ainda.. pensei, pensei, mas não consegui achar uma
forma de usar Chaves Naturais eliminar esse problema... voce poderia dar um
pequeno exemplo?
Desculpa, não posso parar para fazer isso. Mas sugiro leitura básica
sobre chaves
Uma questão sobre UUID, o Postgre não existe uma função nativa pra criar ele
não? Busquei no google e achei menção à: uuid_generate_v4 mas não aceita
na última versão... vou ter que criar uma função externa pra isso?
T.·.F.·.A.·. S+F
*Fellipe Henrique P. Soares*
Analista e Desenvolvedor de
Em 6 de julho de 2011 16:37, Fellipe Henrique felli...@gmail.com escreveu:
Uma questão sobre UUID, o Postgre não existe uma função nativa pra criar
ele não? Busquei no google e achei menção à: uuid_generate_v4 mas não
aceita na última versão... vou ter que criar uma função externa pra isso?
Hum.. então estou fazendo algo de errado... select uuid_generate_v4()
ERRO: função uuid_generate_v4() não existe
LINE 1: select uuid_generate_v4()
^
HINT: Nenhuma função corresponde com o nome e os tipos de argumentos
informados. Você precisa adicionar conversões de tipo
Em 6 de julho de 2011 16:56, Fellipe Henrique felli...@gmail.com escreveu:
Hum.. então estou fazendo algo de errado... select uuid_generate_v4()
ERRO: função uuid_generate_v4() não existe
LINE 1: select uuid_generate_v4()
^
HINT: Nenhuma função corresponde com o nome
50 matches
Mail list logo
