Chave Primaria Composta ?

23/02/2006

0

Olá Pessoal bom dia !

Estou projetando um sistema Mult-Empresa, me deparei com uma questão,
como seria definido a chave primária, eu teria algum problema de performance de BD com Chave Composta ?

Estou usando FireBird e Oracle,

Exemplo de uma tabela:

Produtos:

ID //Código sequencial
ID_LOJA // Código da loja, todas as tabelas tem esse campo.
CODIGO // Código do produto
Descricao
...

é aconselhavel definir os três campos como chave primaria ?

o Código do produto será o mesmo para todas as lojas, o que vai mudar aí é o ID e o ID_LOJA.


Alguém pode me dar uma ajudinha nisso ?

Obrigada.


Renatacoimbra

Renatacoimbra

Responder

Posts

23/02/2006

Motta

Renata , uma chave primaria simples e numérica é mais rápida que uma composta , mas nada que torne inviável um projeto , podendo evitar , evite , se não , não há grandes problemas.

Num sistema multi-empresa (ou lojas ??) é comum esta formacao de chave

cod_empresa
cod_loja
etc ...

Por multi-empresa entendo entidade jurídicas diferentes , cnpj raiz diferente , impostos recolhidos a parte etc, uma faz parte de uma empresa, tendo porém a questão da tributação local.Não entendi bem o que você quis dizer com multi-empresa x lojas.


Responder

23/02/2006

Renatacoimbra

Oi Motta !

Mult-empresa, é uma matriz e 3 filiais por exemplo, com estoques e movimentações diferentes, a base de dados será acessada remotamente pelas filiais.

dentro do BD tudo será separado pelo código da Loja, menos o cadastro de clientes que será para todas.

fiz uns testes aqui, da forma q eu tinha pensado não será possivel,

se na minha tabela eu tenho:

ID, ID_LOJA e CODIGO como chave primaria, fica dificil eu relacionar essa tabela em uma chave estrangeira para outra tabela.

então eu definir só o ID como Primary key e criei uma chave unica para os três campos.

Isso é válido ?

Obrigada.


Responder

23/02/2006

Motta

o id_loja ficou como atributo comum ?

eu faria com o id_loja nas tabebas em que isto se aplica l, o estoque é centralizado, distribuído ou ambos ?

será um bd p/ cada loja ou centralizado e acesso remoto , se distribuído como ficam as tabelas centrais (existem , nao ) ?


Responder

23/02/2006

Renatacoimbra

Oi Motta !

[color=blue:0ff57df4dc]o id_loja ficou como atributo comum ? [/color:0ff57df4dc]

Ficou assim:

ID
ID_LOJA
CODIGO
...

ID é a chave primaria da tabela, sequencial.

depois eu criei uma chave única com os três campos juntos.
pra evitar duplicidades, dois produto com o mesmo código para mesma empresa.

Todas as tabelas seguem o mesmo padrão.

[color=darkblue:0ff57df4dc]o estoque é centralizado, distribuído ou ambos ? [/color:0ff57df4dc]

Ambos.

[color=darkblue:0ff57df4dc]será um bd p/ cada loja ou centralizado e acesso remoto , se distribuído como ficam as tabelas centrais (existem , nao ) ?[/color:0ff57df4dc]

A ideia inicial é um BD para cada loja replicando para a matriz.

Como seria essas tabelas centrais ?

A ideia é o BD igual em todas as lojas.


Responder

23/02/2006

Emerson Nascimento

Renata, no seu caso, creio que a tabela de produtos não deva se referenciar a loja, visto que os produtos são comuns à todo o grupo. É necessário uma melhor análise, mas em princípio deveria ser algo assim:

Produto
---------------------------------------
ID //Código sequencial (PK)
CODIGO // Código do produto
Descricao
etc...

Estoque
---------------------------------------
ID // sequencial (PK)
ID_PRODUTO // (FK - tabela de produto) (UK)
ID_LOJA // (FK - tabela de loja) (UK)
ID_LOCAL // local/almoxarifado (FK - tabela de locais)
SALDO
RESERVADO
etc...

Movimento
---------------------------------------
ID // sequencial (PK)
ID_PRODUTO // (FK - tabela de produto) (UK)
ID_LOJA // (FK - tabela de loja) (UK)
ID_LOCAL // local/almoxarifado (FK - tabela de locais)
TIPODEMOVIMENTO // entrada/saida
QUANTIDADE
DATA
DOCUMENTO
etc...

assim você terá os produtos vistos por todas as filiais, mas os saldos em estoque e as movimentações do produto estarão dividos por loja.

foi uma análise a grosso modo... conhecendo suas necessidades a resposta poderá ser mais precisa.


Responder

23/02/2006

Renatacoimbra

emerson.en, mais tem lojas que trabalham com produtos diferentes das outras, da forma que vc colocou, as lojas vão exergar todos os produtos.


Responder

23/02/2006

Andremuller

Caso crie uma tabela de produto para cada loja é visível que teu ER não vai estar normalizado.

Deves criar uma Produto e uma ProdutoLoja, onde tu referencia quais produtos são disponibilizados naquela loja.

Referente as PKs, crie PKs sempre únicas, depois crie índices únicos compostos se necessário.


Responder

23/02/2006

Andremuller

Caso coloques o código da loja na tabela de produtos é visível que teu ER não vai estar normalizado.

Deves criar uma Produto e uma ProdutoLoja, onde tu referencia quais produtos são disponibilizados naquela loja.

Referente as PKs, crie PKs sempre únicas, depois crie índices únicos compostos se necessário.


Responder

23/02/2006

Renatacoimbra

Obrigada andremuller !

vou analisar as sugestões de todos os colegas.

[]´s


Responder

24/02/2006

Emerson Nascimento

a sugestão do [b:de33bf03a0]andremuller[/b:de33bf03a0] é muito boa. assim você terá um cadastro único de produtos, e nessa tabela ProdutoLoja estarão os produtos comercializados em cada loja.


Responder

24/02/2006

Renatacoimbra

Obrigada a todos pelas dicas.

[]´s


Responder

24/02/2006

Motta

Referente as PKs, crie PKs sempre únicas, depois crie índices únicos compostos se necessário.


Que vantagens vê neste método andremuller ? Eu tento sempre evitar chaves artificiais, mesmo tendo de trabalhar com pk´s compostas.No caso da RenataCoimbra , faria como você sugeriu uma tabela de produto e uma de produtoloja mas faria a chave ser algo do tipo (codempresa,codloja,codprod) e (codempresa,codloja,codprod,codloja) , já pensaria em fazer o Sistema multi-empresa , vai que os caras tem uma butique feminina e decidem abrir uma masculina ...


Responder

24/02/2006

Renatacoimbra

Oi Motta !

Não entendir essa sua abordagem,

[color=red:acdd9c7fc8](codempresa,codloja,codprod)[/color:acdd9c7fc8]

codEmpresa e Codloja não é a mesma coisa ?

no meu caso dar na mesma.

[]´s


Responder

24/02/2006

Emerson Nascimento

[quote:1810c0a6fa=´andremuller´]Referente as PKs, crie PKs sempre únicas, depois crie índices únicos compostos se necessário.


Que vantagens vê neste método andremuller ? Eu tento sempre evitar chaves artificiais, mesmo tendo de trabalhar com pk´s compostas.No caso da RenataCoimbra , faria como você sugeriu uma tabela de produto e uma de produtoloja mas faria a chave ser algo do tipo (codempresa,codloja,codprod) e (codempresa,codloja,codprod,codloja) , já pensaria em fazer o Sistema multi-empresa , vai que os caras tem uma butique feminina e decidem abrir uma masculina ...[/quote:1810c0a6fa]
posso estar falando besteira, mas nesse caso a empresa estaria implícita na loja.
[EMPRESA]
ID (PK)
CNPJ (UK)
RAZAOSOCIAL
ENDERECO
etc...

[LOJA]
ID (PK)
ID_EMPRESA (FK)
CNPJ (UK)
RAZAOSOCIAL
FANTASIA
etc...

[PRODUTO]
ID (PK)
CODIGO (UK)
DESCRICAO
etc...

[PRODUTOLOJA]
ID_PRODUTO (PK, FK)
ID_LOJA (PK, FK)
PRECO
SALDO
etc...

[LOJA]
ID   ID_EMPRESA  RAZAOSOCIAL    FANTASIA           
---- ----------- -------------- ------------------
1    1           LOJA X         FILIAL FARIA LIMA
2    1           LOJA Y         FILIAL SANTANA
3    1           LOJA Z         FILIAL CENTRO

ou seja: se eu indicar a loja cujo ID é 2, implicitamente eu estaria informando a empresa de ID = 1.
sendo assim, a chave da tabela ProdutoLoja poderia ser apenas PK(ID_PRODUTO, ID_LOJA), e obviamente não seria necessária uma chave única.

obs.: isso num sistema multi-empresa (geralmente há confusão entre sistemas multi-empresa e multi-filiais)


Responder

24/02/2006

Renatacoimbra

Hun, entendir !

No meu caso não vou controlar as empresas X Filiais.
Se o empresario tiver 3 Lojas, sendo uma Matriz e duas Filiais,
no sistema vai ser cadastrado 3 empresas (Lojas), posso até identificar quem é a matriz e quem é as Filiais, mais só pra saber, para o controle gerencial.


[]´s


Responder

Assista grátis a nossa aula inaugural

Assitir aula

Saiba por que programar é uma questão de
sobrevivência e como aprender sem riscos

Assistir agora

Utilizamos cookies para fornecer uma melhor experiência para nossos usuários, consulte nossa política de privacidade.

Aceitar