Usuário com melhor resposta
Resolução de tabela mensagem

Pergunta
-
Boas amigos, estou com uma duvida de resolução de tabelas.
Estou desenvolvendo um sistema de ticket cliente - empresa, empresa - cliente
Dentro disso vai ter regras de permissão de alteração e etc, essas validações farei via C#
Minha duvida se encontra no seguinte problema:
Como é um sistema de postagem continua, preciso ordenar as postagens em ordem cronológica, sendo que as postagens do lado empresa ( colaborador ) podem ou não ser invisíveis ( somente colaboradores veem essas mensagens ).
Minha duvida se encontra no seguinte, qual das duas opções seria melhor?
Uma unica tabela de mensagem com fk de colaborador e empresa ou 2 tabelas distintas, um para colaborador e um para cliente?
Como ainda me encontro nas etapas de DER ( Diagrama de entidade e relacionamento ) e model do banco de dados, postarei como está a estrutura, não gosto de pedir ajuda sem ao menos ter me esforçado, talvez alguem possa ajuda.
Obrigado pela atenção.
Respostas
-
Eu imagino 2 FK's no caso, uma para colaborador e uma para empresa, podendo ser nullable
Uma FK pode ser NULL, o que faz um relacionamento 1..0:N. Em outras palavras, um registro filho pode (mas não é pré requisito)ter um pai.
Uma FK NOT NULL segue a modelagem 1:N. Em outras palavras, todo filho deve ter um pai.
Se a sugestão resolver o problema, favor marcar como Resposta.
- Marcado como Resposta Dietrich Prg terça-feira, 11 de março de 2014 11:08
Todas as Respostas
-
A meu ver, uma única tabela é o suficiente
Nessa tabela pelo visto você armazenaria mais colunas contendo ID's (chaves estrangeiras, e chaves primárias) do que algo que caracterize uma empresa ou um colaborador, então sempre que usar essa tabela, a meu ver, você usaria junto com um JOIN para poder relaciona-la a uma tabela que contenha as informações de um colaborador, como por exemplo o Nome dele, e se você particionar em 2 tabelas, você teria 2 JOIN's dependendo do caso, e isso só para cruzar informações para recuperar Nomes de usuários ou empresas, etc.
Lembrando que haveria índices para melhorar a performance na recuperação da informação onde for Chave primária e estrangeira, e sua tabela seria composta na grande maioria das colunas, de chaves estrangeiras, então ratificando, a meu ver 1 tabela bastaria
Se a sugestão resolver o problema, favor marcar como Resposta.
- Editado Lucas_Santos sexta-feira, 7 de março de 2014 21:32
- Sugerido como Resposta piratazzz terça-feira, 11 de março de 2014 17:44
-
no caso, a validação seria, se tiver no fk colaborador ou empresa.
ao meu ver foi isso que consegui imaginar em cima do que vc me falou.
- Editado Dietrich Prg segunda-feira, 10 de março de 2014 11:05 corrigi concordancia.
-
Eu imagino 2 FK's no caso, uma para colaborador e uma para empresa, podendo ser nullable
Uma FK pode ser NULL, o que faz um relacionamento 1..0:N. Em outras palavras, um registro filho pode (mas não é pré requisito)ter um pai.
Uma FK NOT NULL segue a modelagem 1:N. Em outras palavras, todo filho deve ter um pai.
Se a sugestão resolver o problema, favor marcar como Resposta.
- Marcado como Resposta Dietrich Prg terça-feira, 11 de março de 2014 11:08