Solucionado (ver solução)
Solucionado
(ver solução)
5
respostas

Dúvida na criação de tabela

quando tenho uma requisição(saída), eu seto a chave estrangeira requisicao_id e mantenho compra_id nula,assim também ficaria fácil saber se foi compra ou requisição, é só verificar qual campo está nulo, mas essa abordagem me preocupa em relação à integridade, performance, espaço em disco, não sei se um monte de campo null teria um impacto negativo em meu banco.


MOVIMENTO


MOVIMENTO_ID COMPRA_ID REQUISICAO_ID ITEM QUANTIDADE PRECO DATA


Na abordagem 2, eu teria um campo flag indicando se é entrada(E) ou saída (S) e guardaria o id da compra ou da requisição no campo COM_REQ_ID, esta abordagem fere alguma regra de modelagem?


MOVIMENTO


MOVIMENTO_ID COM_REQ_ID REQUISICAO_ID ITEMQUANTIDADE PRECOTIPO_MOVIMENTODATA


Qual das duas abordagens é melhor? existe outra maneira melhor de fazer?

5 respostas

Você está utilizando a técnica para vê os relacionamentos e ve como ficaria as tabelas antes de criação? e de extrema importância fazer as entidades relacionamentos para não ficar nesse questionamento com o banco criado..da um SHOW TABLES POSTA a estrutura e também as estruturas da tabela por favor..

Olá João, obrigado por responder, então fiz sim o DER, foi ai que surgiu essa dúvida, o editor bagunçou legal a estrutura da tabela, vou tentar colocar em html, a primeira tabela seria a tabela de movimentos com as colunas COMPRA_ID e REQUISICAO_ID, sendo que uma delas vai ser sempre nula visto que uma movimentação pode ser exclusivamente uma compra ou requisição

`

MOVIMENTO

Coluna

pk

MOVIMENTO_ID

fkCOMPRA_ID

fk

REQUISICAO_ID

fkITEM_ID

QUANTIDADE

PRECO

DATA A segunda tabela seria a tabela de movimentações com apenas uma coluna( COM_REQ_ID) que representa ou uma compra ou uma requisição e um campo tipo flag que diz se é uma compra ou requisição.

MOVIMENTO

Coluna

pk

MOVIMENTO_ID

fkCOM_REQ_ID

TIPO_MOVIMENTO

fkITEM_ID

QUANTIDADE

PRECO

DATA `

não seu quais seriam os pós ou contras de cada situação e nem qual a mais indicada, agradeço qualquer tipo de ajuda

solução!

Não seria melhor separar em mais tabelas? Uma compra tem uma movimentação, uma movimentação tem uma compra ou requisicao ou seja poderiamos criar uma Tabela para especificar o tipo de movimentação 1:1 outra para detalhar a venda porque tem que detalhar com o item N:N teria que criar outra tabela do relacionamento..

pensei também em criar uma tabela de entrada(compra) e uma de saída(requisições), acho que pra essa minha situação resolve. Sempre que aparece essas situações de generalização e especificação dão um certo nó na cabeça, uma situação semelhante é o cadastro de cliente que pode ser uma pessoa física ou pessoa jurídica, eu sei que seguindo os ensinamentos de normalização eu deveria criar uma tabela mãe para a tabela generalizada e criar tabelas para as especificações, só que uso java com JPA na outra ponta que não segue o modelo relacional, ai sempre eu me bagunço tentando resolver esse tipo de situação, obrigado por responder.

Tranquilo, qualquer coisa estamos aqui para ajudar.. Sofrir o mesmo problema só que em prova e sem os colegas para ajudar.. bem delicado..