Início / dba / Perguntas / 27353
Accepted
codecool
Asked: 2012-10-23 02:30:45 +0800 CST

Projeto de banco de dados com diferentes funções de usuário conectadas por diferentes relacionamentos a uma tabela de organização

  • 772

Um usuário está conectado a uma organização por alguma função. Digamos que haja 2 funções freelancer e funcionário.

Um funcionário só pode fazer parte de uma organização e, se for funcionário, não pode ser freelancer. Considerando que um freelancer pode estar conectado a várias organizações e também não pode ser um funcionário.

Resumindo, Freelancer e Funcionário são usuários. O Freelancer está conectado à Organização por meio de um relacionamento de muitos para muitos. O funcionário está conectado à organização por meio de um relacionamento de um para muitos.

O que eu pensei:

user{
   id,
   name,
   other_fields,
}

organization{
    id,
    other_fields
}

freelancer{
    user_id,
    organization_id,
    Primary_Key(user_id, organization_id)
}

employee{
    user_id,
    organization_id,
    Primary_key(user_id),
}

Há um problema aqui, no entanto. A restrição de ser freelancer ou funcionário, mas não ambos, deve ser implementada no nível do aplicativo.

  1. Quais são os prós e contras do esquema acima?
  2. Quais são as outras alternativas possíveis para o esquema de design?
  3. E se houver mais categorias de usuários? O esquema atual requer a adição de uma nova tabela se uma nova função de usuário for criada. Está tudo bem ou ruim?
  4. A manutenção do banco de dados também é uma preocupação de fazer um esquema que não deve tornar a manutenção um problema
database-design performance

1 respostas

  1. Best Answer

    Quais são os prós e contras do esquema acima?

    A principal desvantagem que vejo é que freelancere employeetêm os mesmos campos, mas são tabelas diferentes. A diferença é o que primary_keyé composto, mas eu me pergunto se você poderia normalizar isso como

    emplpoyee
{
    user_id,
    employee_type, (could be "FREELANCER" or "FULLTIMEEMPLOYEE")
    organization_id,
    Primary_key
}

    Para primary_key, você pode precisar de alguma lógica de aplicativo para criar uma string baseada em user_ide employee_type, e opcionalmente incluir o valor de organization_idse o funcionário for um freelancer.

    Você pode até ir um passo além e ter uma tabela employee_type:

    employee_type
{
    id,
    description
}

    e, em seguida, faça referência a esse ID em employee.employee_type. Isso resolveria seu problema de adicionar novas tabelas toda vez que houver um novo tipo de usuário.

    Além disso, você já pensou em se fundir employeecom user? Isso simplificaria ainda mais seu esquema, mas você perderia a capacidade de ter um user_idassociado a vários funcionários, o que acho importante para este caso.

    • 2

relate perguntas