Ainda não tem acesso? Estude com a gente! Matricule-se
Ainda não tem acesso? Estude com a gente! Matricule-se

Solucionado (ver solução)

Melhor estrutura para vários tipos de operações

Por gentileza, gostaria de trocar ideias sobre a estrutura de banco de dados de um sistema de operações. Tenho cinco tipos de operações com campos diferentes e é inviável deixar tudo em uma mesma tabela. ( mais de 40 campos) Então penso que devo unir os poucos campos comuns e criar 5 tabelas para incluir as diferenças. O que me deixa em dúvida são duas questões: há campos que cabem em duas ou mais situações, se eu criar uma tabela de relacionamento para cada uma delas vou também ter dezenas de tabelas que particularmente acho ruim. Tenho que tomar cuidado na gravação porque não pode gravar parte dos dados.

Tabela dados comuns ( id_operacao,empresa,valor1,status,obs,origem,area,ativo)

Tb_situação 1 ( id_operacao,valor1,valor2,valor4,codigo3,codigo5,data1,data2,data3)

Tb_situacao 2 ( id_operacao,codigo1,codigo2,valor1,valor4,valor5,data2,data5,texto1,texto2)

tb situacao 3 ( id_operacao,codigo5,data1,texto1,texto2)

Tb situacao 4 ( id_operacao,valor10,codigo1,data2,data3,texto1)

tb situacao 5 ( id_operacao,valor2,codigo3,data1,data3,data5,data9,texto2)

Se eu quiser somar/quantificar as operacoes em um periodo vou precisar fazer union das tabela:

SELECT * FROM Tb_dados_comuns LEFT JOIN tb_dados_comuns.id_operacao=tb_situacao1.id_operacao UNION SELECT * FROM Tb_dados_comuns LEFT JOIN tb_dados_comuns.id_operacao=tb_situacao2.id_operacao ......

E quando for gravar: ( pode acontecer de gravar endereco e não gravar o cliente no código abaixo? public void adicionarCliente(Cliente cliente) { System.out.println("ClienteDAO executando função adicionarCliente"); String sql1 = "INSERT INTO endereco (cidade,rua) VALUES (?,?)"; System.out.println(sql1);

    try {
        stmt = conexao.prepareStatement(sql1);

        stmt.setString(1, cliente.endereco.getRua());
        stmt.setString(2, cliente.endereco.getCidade());

        stmt.executeUpdate(sql1);
    } catch (SQLException u) {
        throw new RuntimeException(u);
    }

    String sql2 = "INSERT INTO clientes (nome,rg,cpf,telefone,Endereco_codigo) VALUES (?,?,?,?,LAST_INSERT_ID())";
    System.out.println(sql2);

    try {
        stmt = conexao.prepareStatement(sql2);

        stmt.setString(1, cliente.getNome());
        stmt.setString(2, cliente.getRg());
        stmt.setString(3, cliente.getCpf());
        stmt.setString(4, cliente.getTelefone());

        stmt.executeUpdate(sql2);
        stmt.close();
        conexao.close();
        System.out.println("Conexão 2 adicionarCliente fechada!");
    } catch (SQLException u) {
        throw new RuntimeException(u);
    }
}

}


Obrigada a quem puder me ajudar.

2 respostas

Olá maryhelenasilva, posso de falar um pouco da experiência que eu tive, é que na pratica tabelas podem ser enormes mesmo, é claro que 40 campos já é muita coisa, você seguiu uma ideia muito boa de separar e tentar juntar o comum porem, muitas tabelas podem ser mais prejudiciais ao seu sistema... Quanto ao ponto de garantir a transação completa dos dados utilize begin, commit e rollback já que você está provavelmente utilizando um banco transacional.

solução

Primeiro, gostaria de recomendar para estudar um pouco mais de conteúdo de modelagem de bases de dados, principalmente entidade-relacionamento, e então ter clareza de suas entidades e como elas se comunicam.

Mas te dando uma opinião mais pessoal, posso te falar pela minha experiência, que vale a pena ter menos tabelas para representar uma entidade ou um grupo. Já trabalhei com bancos com tabelas com muito mais de 40 campos e com quantidades absurdas de tabelas, porque era necessário para o negócio, e isso é normal. É a sua necessidade que dita esses números.

Mas imagina, agora, que você quer montar um relatório simples. Você acharia mais fácil, trazer as informações com um simples select e where em uma tabela apenas ou fazer uns 7 joins para trazer informações de 7 tabelas diferentes? Imagina a pessoa que for dar manutenção disso depois?

Já precisei dar manutenção em procedures com querys SQL de mais de 5 mil linhas, com muitos joins e muitas regras, com muitas lógicas de exclusões ou inclusões, para trazer apenas as informações que eu queria e que estavam espalhadas em muitas tabelas. Então a principal vantagem de ter menos tabelas é essa: ter menor complexidade.

Mas qual o balanço certo? porque não colocar tudo em tabela só então? a gente sabe que a separação em tabelas serve para organizar os dados que devem estar juntos e facilitar consultas, mas para isso não aumentar desnecessariamente a complexidade do banco, é necessário saber o layout ideal para o sua base de dados. Para isso, é necessário fazer uma modelagem que identifique as entidades e analisar qual nível de complexidade vale a pena para você.

Então a principal dica que eu te dou, é: já pense no que você vai precisar fazer com esse banco, as consultas que você pretende fazer e o que pretende calcular. Com isso em mente, você vai tomar decisões de maneira muito mais acertada.