Dúvida em arquitetura de BD / Construção de classes e Relacionamento

Não sei mas, pra mim, ficou a mesma coisa

E sim, funcionário ou alguma classe de negócio vai ter um método pra te retornar as cargas de determinado funcionário, assim como carga ou outra classe de negócio terá o método que retorna o funcionário e a empresa da carga que você quiser.

davidpadilha:

Opa

To montando um BD que tem 3 entidades: Empresa, Funcionarios e Cargas.

Até agora o relacionamento deles está da seguinte maneira:

1 Empresa - N Funcionarios
1 Empresa - N Cargas

Porém eu preciso relacionar q Carga cadastrada com o Funcionário que cadastrou, eu pensei em fazer:

1 Empresa - N Funcionarios
1 Funcionario - N Cargas

Só que eu comecei a codificicar e por Funcionario ser uma lista, eu iria precisar percorrer essa lista toda vez que entrasse na tela e, creio eu que, isso é um processo custoso e por isso eu pensei em mudar para:

Peraí… mas a duvida não era com a arquitetura do banco ? o que têm a haver “lista implementada” com isso ?

Eu não manjo disso mas, banco e codigo são duas coisas diferentes.
Nos relacionamentos das classes existe um conceito chamado navegação. No banco isso não existe.
A classe carga tem um funcionário, ou seja , da carga eu sei quem é o fucnionario. então carga é navegável até funcionário.
MAs e da classe funcionário ? eu tenho navegação até às cargas ?
Ou seja, eu tenho um método Collection getCargas() em funcionário ?
Se tenho, porque eu tenho ?

1. Porque é um requisito ?
2. Porque é um truque de perfornance
3. porque é mais facil de usar programáticamente ?

A menos que a resposta seja (1) ha que colocar em causa se é necessário esse método.
Se for necessário ha que colocar em causa a implementação. Colocar uma lista de cargas no funcionário nem sempre funciona.

O modelo do banco

1 Empresa - N Funcionarios
1 Funcionario - N Cargas

parece ok. A construção das classes é outra conversa.

sergiotaborda:

davidpadilha:

Opa

To montando um BD que tem 3 entidades: Empresa, Funcionarios e Cargas.

Até agora o relacionamento deles está da seguinte maneira:

1 Empresa - N Funcionarios
1 Empresa - N Cargas

Porém eu preciso relacionar q Carga cadastrada com o Funcionário que cadastrou, eu pensei em fazer:

1 Empresa - N Funcionarios
1 Funcionario - N Cargas

Só que eu comecei a codificicar e por Funcionario ser uma lista, eu iria precisar percorrer essa lista toda vez que entrasse na tela e, creio eu que, isso é um processo custoso e por isso eu pensei em mudar para:

Peraí… mas a duvida não era com a arquitetura do banco ? o que têm a haver “lista implementada” com isso ?

Eu não manjo disso mas, banco e codigo são duas coisas diferentes.
Nos relacionamentos das classes existe um conceito chamado navegação. No banco isso não existe.
A classe carga tem um funcionário, ou seja , da carga eu sei quem é o fucnionario. então carga é navegável até funcionário.
MAs e da classe funcionário ? eu tenho navegação até às cargas ?
Ou seja, eu tenho um método Collection getCargas() em funcionário ?
Se tenho, porque eu tenho ?

1. Porque é um requisito ?
2. Porque é um truque de perfornance
3. porque é mais facil de usar programáticamente ?

A menos que a resposta seja (1) ha que colocar em causa se é necessário esse método.
Se for necessário ha que colocar em causa a implementação. Colocar uma lista de cargas no funcionário nem sempre funciona.

O modelo do banco

1 Empresa - N Funcionarios
1 Funcionario - N Cargas

parece ok. A construção das classes é outra conversa.

Acho que a dúvida seria na construção de classes mesmo, eu desenhei o modelo:

1 Empresa - N Funcionarios
1 Funcionario - N Cargas

E achei meio porquinho, porém funcional…só que não achei legal ficar colocando listas dentro dos beans pq na hora de salvar uma carga, por exemplo, não vou ter o ID do Funcionário de uma maneira prática e vou precisar percorrer a lista de funcionarios da empresa até encontrar aquele funcionário que esteja logado. Então eu criei:

Empresa - Carga : 1 - N
Empresa - Funcionario : 1 - N
Funcionario - Carga: 1 - N

Pq dentro do funcionário, eu teria uma lista das proprias cargas dele, mas tb acho meio porco isso.

O que sugere?

[]'s

começe pela interfaces das classes ( o que vc quer que elas façam)

class Carga {

   public Funcionario getFuncionario(){}
}

class Funcionario {

   public Collection<Cargas> getCargas(){}
}


class Empresa{

   public Collection<Funcionario> getFuncionarios(){}
}

Agora vc analiza as relações entre eles.
para os que retornam coleções vc não precisa ter coleções no objeto.
Vc pode ler do banco

class Empresa{

   FuncionarioRep frep;

   public Collection<Funcionario> getFuncionarios(){
         return frep.getFuncionariosDaEmpresa(this);
   }
}

class FuncionarioRep {
 Collection<Funcionario> getFuncionariosDaEmpresa(Empresa empresa){

       // executa um sql assim  Select * from Funcionario where Empresa = ? 
       // onde ? é o ID da empresa.
        
       // lê o resultset e cria uma coleção de funcioários

       // retorna uma coleção imutável

       return Collections.unmodifiableCollection (coleccaoFuncionarios);
  }

}

Pode fazer o mesmo para empresa e para obter o funcionario a partir da carga

class Carga { FuncionarioRep frep public Funcionario getFuncionario(){ return frep.descobreFuncionarioParaCarga(this); } }

Mas esses métodos são read-only.
Quando vc quiser setar o funcionário na carga (via set) isso tem que ser compativel com aquela leitura, então vc pode fazer assim

class Carga {
   Funcionario funcionario;

   FuncionarioRep  frep
   public Funcionario getFuncionario(){
          if (funcionario==null){
                funcionario = frep.descobreFuncionarioParaCarga(this);
         }
          return funcionario;
   }

   public void setFuncionario(Funcionario f){
       this.funcionario= f;
   }
}