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 cont
Você não quer usar chave composta?
Bruno E. A. Silva.
2011/7/6 Fellipe Henrique
> 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
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 out
2011/7/6 Fellipe Henrique :
> 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.
--
Skype:leandro.gfc.dutra?chat
Hum.. acredito que o problema esteja além da modelagem.. imagina o seguinte:
Tenho um cadastro de Cliente, onde como PK eu incluo um INT sempre
sequencial.. vamos a um pequeno exemplo:
Máquina 1 (Empresa X)
- Cadastro cliente Cód: 1
- Cadastro Cliente Cód 2
Máquina 2 (Empresa Y)
- Cadastro Client
2011/7/6 Fellipe Henrique :
> 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 genérica.
A mais esp
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 :
> 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 naturais, talve
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 d
Em 6 de julho de 2011 16:37, Fellipe Henrique 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?
>
>
Você está e
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 e
Em 6 de julho de 2011 16:56, Fellipe Henrique 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 e os tipos de
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 escreveu:
> Em 6 de julho de 2011
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 escreveu:
> Entendi... só uma outra coisa.. como iniciante que sou... como
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 c
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 re
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 ch
>>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 reusado
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" (geralmen
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 sen
2011/7/11 Alexsander Rosa :
>
> …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
> ṕublicos compartilham o
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 excelentes chaves naturais -- mas não PK. Não aconselho ninguém
2011/7/11 Alexsander Rosa :
> 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 excelentes chaves naturais -
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
2011/7/11 Alexsander Rosa :
> 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 ou
> não, são quase
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
> 2011/7/11 Alexsander Rosa :
> > Sim, obviamente, mas quem
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 :
> Peraí A técnica/teoria implementa as duas. As duas são feitas para serem
> usadas. Use-as, inclusive no mesmo projeto,
Comentários no texto:
Em 11 de julho de 2011 17:50, Leandro DUTRA
escreveu:
> 2011/7/11 Alexsander Rosa :
> > 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.
>
O ex
2011/7/12 Alexsander Rosa :
> Comentários no texto:
Ufa, obrigado.
> Em 11 de julho de 2011 17:50, Leandro DUTRA
> escreveu:
>>
>> Péssimo exemplo, visto que essa definitivamente não é uma chave natural
>> válida.
>
> O exemplo CPF + NOME como chave natural foi sugerido aqui mesmo neste
> tópic
Em 12 de julho de 2011 13:02, Leandro DUTRA
escreveu:
> > (...) 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 compartilhado por marido e
2011/7/13 Alexsander Rosa :
>
> 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 novo confusão. Se có
Em 13 de julho de 2011 13:28, Leandro DUTRA
escreveu:
> 2011/7/13 Alexsander Rosa :
> >
> > 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 c
2011/7/13 Alexsander Rosa :
>
> 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 que disse que não preci
Em seg 11 jul 2011, às 17:50:24, Leandro DUTRA escreveu:
> 2011/7/11 Alexsander Rosa :
> > 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
Em 19 de julho de 2011 17:49, Johnny Chaves escreveu:
>
> 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á foram
> apresentados m
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 Rosa:
>>> 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 que seria mui
Em 19 de julho de 2011 22:26, Euler Taveira de Oliveira
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? Aqui está o seu pedido. Do
> que: Número? 7..9..5..7..2..3..9..5..8..2..3..7. Aqui está o seu pedido.
>
>
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.
E
Em 19-07-2011 22:57, Fabrízio de Royes Mello escreveu:
> Em 19 de julho de 2011 22:26, Euler Taveira de Oliveira
> 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? Aqui está o
Comentários no texto.
Em 19 de julho de 2011 22:26, 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 Rosa:
> >>> As pessoas estão acostumadas a receber um "número de pedido" qu
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
2011/7/19 Johnny Chaves
>
> 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 motivo ou vantagem d
Em 20 de julho de 2011 01:54, Euler Taveira de Oliveira
escreveu:
> 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 m
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 Rosa:
> >>> As pessoas estão acostumadas a receber um "número de pedido" quando
> >>> compram al
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
>
> 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? Aqui está o seu pedido.
> > D
Em qua 20 jul 2011, às 09:45:26, Roberto Mello escreveu:
> 2011/7/19 Johnny Chaves
>
> > 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 que
Em qua 20 jul 2011, às 09:56:39, Alexsander Rosa escreveu:
> Em 20 de julho de 2011 01:54, Euler Taveira de Oliveira
>
> escreveu:
> > 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 d
Em 20 de julho de 2011 11:38, Johnny Chaves escreveu:
>
> *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, fui
> eu
> quem perd
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!: ymsg
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
escreveu:
> 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
> requ
52 matches
Mail list logo
