Estou com uma dúvida. Criei uma classe abstract Cadastros, ou seja, essa classe não pode ser instanciada, certo?
Criei outras duas classes Cliente e Fornecedor, que herdam os atributos em comum da classe Cadastro.
Minha duvida é, como ficaria no banco de dados e o Insert usando JDBC?
Teria 3 tabelas (Cadastros, Cliente e Fornecedor) ligadas por chave? a chave de cadastros seria FK de cliente e fornecedor?
e como ficaria o Insert, por exemplo, só na classe fornecedor tem CNPJ
Já o nome e data de Cadastro ficam na classe Cadastros.
Quando o cara chamar o cadastro de fornecedor, teria que ter um insert em fornecedor no CNPJ, e os demais campos na tabela de Cadastro.
String sql = "insert into Cadastros (nome, dataCadatros) values (?,?)";
Teria que ter outro para fornecedor?
String sql = "insert into Fornecedor (CNPJ, cod_cadastro) values (?,?)";
Bom, você está confundindo as coisas.
Herança, embora seja parecida com o conceito de especialização-generalização, não segue o mesmo fluxo.
Quando uma única classe possui atributos que podem e são dispostos em mais de uma tabela, a query deve contemplar ambas, simples assim.
Acontece que na generalização de tabelas, você terá a PK de cadastros em Fornecedor, logo, precisa inserir primeiro em cadastros e depois em fornecedor, para já informar a pk do “dono” destes dados.
Calma, muita calma. Sim, uma classe abstrata realmente não pode ser instanciada, tu somente precisa ter certeza que quer uma classe abstrata e não uma interface, por exemplo. Você pode criar uma classe concreta e fazer com que outras classes a extendam, sem necessariamente obriga-la a ser abstrata.
As tuas outras dúvidas estão totalmente relacionadas a modelagem de banco de dados. Como estamos falando em JDBC e não JPA, você é obrigado a fazer o setter na mão e não simplesmente mandar dar um em.merge(objeto), como seria usando JPA. Sendo assim, as tuas perguntas só podem ser respondidas após tu ter modelado o banco. Uns preferem modelar os objetos e a partir deles as tabelas, outros o contrário. Ai vai da sua experiência, ponto de vista, necessidade e etc.
Você pode ou não repetir colunas em diferentes colunas, pode fazer uma chave estrangeira para buscar evitar isso e relacionar uma a outra, enfim…
Abraços.
Mas Interface não é para forçar uma classe a executar tal método? Só atributos o melhor não abstract mesmo?
Então, mas não existe cadastro de cadastro, existe cadastro de fornecedor. Quando chamar o cadastro de fornecedor, qual seria o procedimento para da insert primeiro na tabela de cadastro, para só depois o insert em fornecedor?
Sei que existe jeitos melhores de fazer conexão com o banco de dados, como o Hibernete, mas estou seguindo o curso FJ21 a risca
[quote=BtAquino]Mas Interface não é para forçar uma classe a executar tal método? Só atributos o melhor não abstract mesmo?
Então, mas não existe cadastro de cadastro, existe cadastro de fornecedor. Quando chamar o cadastro de fornecedor, qual seria o procedimento para da insert primeiro na tabela de cadastro, para só depois o insert em fornecedor?
Sei que existe jeitos melhores de fazer conexão com o banco de dados, como o Hibernete, mas estou seguindo o curso FJ21 a risca
[/quote]
Claro, se aprende sem pressas, uma excelente base será muito útil á você. Depende de como tu fará o relacionamento do cadastro com o fornecedor, é isso que estou dizendo. Tu terá de inserir primeiro a tabela “pai”, se houver, e depois a filha. Nesse caso, primeiro a tabela que vai gerar o ID para tu usar na tabela que irá possuir a chave estrangeira, afinal, como tu terá referência da tabela X sem que tenha sido inserido registro na tabela X, certo ?
Ou seja, se o Fornecedor vai armazenar um referência a um registro do Cadastro, primeiro insere o cadastro, recupera o ID gerado e em seguida, insere o Fornecedor e dessa forma tu pode setar a chave do Cadastro sem problemas.
Não confunda o Diagrama de Classes com o Diagrama de Entidade Relacionamento.
Uma maneira de se fazer a modelagem desse seu exemplo no banco de dados é criar duas tabelas, uma para Cliente e outra para Fornecedor.
A classe Cadastro vai servir só para você evitar de reescrever os campos em comum nas classes Cliente e Fornecedor, ela não precisa ser uma tabela no seu banco de dados. As classes Cliente e Fornecedor herdam os campos dela…
Na prática, não existe uma única maneira correta para mapear classes em tabelas. Basicamente, existem 3 abordagens que podem ser usadas:
:arrow: criar uma tabela para cada classe concreta, repetindo os campos em cada tabela de classe concreta
:arrow: criar uma única tabela para toda a hierarquia, com um campo de tipo
:arrow: criar uma tabela para a classe abstrata, com os campos comuns e criar tabelas para as classes concretas, com as PK’s das tabelas de classe concretas sendo FK’s para a tabela da classe abstrata.
