Array
(
)

Chave Primaria Composta ?

Renatacoimbra
   - 23 fev 2006

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.


Motta
   - 23 fev 2006

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.


Renatacoimbra
   - 23 fev 2006

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.


Motta
   - 23 fev 2006

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 ) ?


Renatacoimbra
   - 23 fev 2006

Oi Motta !

o id_loja ficou como atributo comum ?

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.

o estoque é centralizado, distribuído ou ambos ?

Ambos.

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

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.


Emerson
   - 23 fev 2006

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.


Renatacoimbra
   - 23 fev 2006

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.


Andremuller
   - 23 fev 2006

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.


Andremuller
   - 23 fev 2006

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.


Renatacoimbra
   - 23 fev 2006

Obrigada andremuller !

vou analisar as sugestões de todos os colegas.

[]´s


Emerson
   - 24 fev 2006

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


Renatacoimbra
   - 24 fev 2006

Obrigada a todos pelas dicas.

[]´s


Motta
   - 24 fev 2006


Citação:
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 ...


Renatacoimbra
   - 24 fev 2006

Oi Motta !

Não entendir essa sua abordagem,

(codempresa,codloja,codprod)

codEmpresa e Codloja não é a mesma coisa ?

no meu caso dar na mesma.

[]´s


Emerson
   - 24 fev 2006


Citação:

Citação:
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 ...

posso estar falando besteira, mas nesse caso a empresa estaria implícita na loja.
#Código

[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)


Renatacoimbra
   - 24 fev 2006

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


Motta
   - 24 fev 2006

Um exemplo :

O grupo XPTO tem varias empresas :

SilverSurfer (roupas de praia)
Ao rigor (roupas de festas)
Girl (Moda feminina)

Cada uma desta empresa tem varias lojas ,e a contabilidade de cada uma é separada.

_______________________________