Resolução de tabela mensagem

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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.