none
Resolução de tabela mensagem RRS feed

  • 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.

    sexta-feira, 7 de março de 2014 20:15

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
    segunda-feira, 10 de março de 2014 20:54

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
    sexta-feira, 7 de março de 2014 21:31
  • 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.
    segunda-feira, 10 de março de 2014 01:32
  • 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
    segunda-feira, 10 de março de 2014 20:54