Estrutura tabelas e Insert SQL de forma correta

08/05/2016

0

Eaew galerinha.

Tenho uma dúvida sobre o modo se usa o comando INSERT dentro de um banco de dados (já que estou aprendendo SQL sózinho e os tutoriais que achei não me clarearam as idéias).

Estou fazendo um programa em Lazarus (programa estilo Delphi) e ele é basicamente um punhado de inserções e leituras dentro do banco de dados, porém meu banco de dados tem tabelas relacionadas 1 para 1, 1 para muitos e muitos para muitos e estou em dúvida como faço o SQL do INSERT de forma correta.

Segue um exemplo aproximado da estrutura que tenho:

tbl_usuario (ID INT NOT NULL PK, nome, sexo, dataNascimento, estadocivil, endereço FK (endereço id), cidade FK (cidade id), estado FK (estado id))

tbl_endereço (ID INT NOT NULL PK, endereco)

tbl_cidade (ID INT NOT NULL PK, estado_id PK (estado id), nome_cidade)

tbl_estado (ID INT NOT NULL PK, estado_uf, estado_nome)

tbl_telefones (ID INT NOT NULL PK, id_usuario FK (usuario id), numero)

tbl_interesses (ID INT NOT NULL PK, id_usuario FK (usuario id), interesse)

Gostaria de saber se no caso de interesses onde eu vou ter uma duplicade de registros do id do usuario eu devo ou não criar uma referencia através de uma FK ou se as consultas do tipo join ou multiplos selects ao mesmo tempo dão conta disso.

Também gostaria de saber qual o processo correto do INSERT dentro das tabelas, até o momento tenho o seguinte conhecimento para cadastrar valores na tbl_usuario:

START TRANSACTION;
INSERT INTO tbl_usuario (nome, sexo, dataNascimento, estadocivil, endereco, cidade, estado) VALUES ('Tina', 'F', '10-10-1989', 10, 9, 1, 'S');
SELECT LAST_INSERT_ID() INTO @ID;
INSERT INTO telefones (id_usuario, numero) VALUES (@ID, '(+5555) 55555-5555');
INSERT INTO telefones (id_usuario, numero) VALUES (@ID, '(+5555) 44444-4444');
COMMIT;


Mas e se eu precisar por exemplo criar uma FK do telefone dentro da tbl_usuario que não possa ser preenchida de inicio já que a tabela de telefones e interesses são muitos para 1, neste caso eu teria de fazer um SELECT da id do telefone e usar o UPDATE pra atualiar o campo?

Pergunto isso porque na divisão final da tabela usuŕio fiquei com várias tabelas com esse tipo de relacionamento, como sou novo nisso gostaria de opinião dos experientes.
Douglas Silvestre

Douglas Silvestre

Responder

Posts

09/05/2016

Marcos P

Douglas,

Gostaria de saber se no caso de interesses onde eu vou ter uma duplicade de registros do id do usuario eu devo ou não criar uma referencia através de uma FK ou se as consultas do tipo join ou multiplos selects ao mesmo tempo dão conta disso.


Ambas as abordagens são funcionais. A melhor prática, contudo, é isolar esses relacionamentos em uma tabela específica, isso vai lhe dar a melhor performance em tempo de manipulação do dados. Minha sugestão é :

tbl_interesses (ID INT NOT NULL PK, 
                descricao_interesse)       
                
tbl_interesses_usuarios (ID_Usuario FK (tbl_usuario.ID),                
                        ID_Interesse FK (tbl_interesses.ID))       


Fazendo assim, você poderá ter múltiplas combinações de interesses por usuário...

Mas e se eu precisar por exemplo criar uma FK do telefone dentro da tbl_usuario que não possa ser preenchida de inicio já que a tabela de telefones e interesses são muitos para 1, neste caso eu teria de fazer um SELECT da id do telefone e usar o UPDATE pra atualizar o campo?


Se você deseja suportar diversos telefones para um mesmo usuário, não cabe colocar a chave da tabela de telefone na tabela de usuarios. Repita a arquitetura que sugeri para "Interesses", fazendo : tbl_usuario x tbl_usuario_telefones x tbl_telefones.

Espero que isso lhe ajude..
Responder

14/05/2016

Douglas Silvestre

Mas no caso de tabelas 1x1 é necessário manter esse relacionameto PK x FK? Meu bd tem uma tabela para imagens já que nem todos usuários irão ganhar uma imagem (bem provavel que não), nesse tipo de relação seria interessante fazer uma coluna fk do usuario para pk imagem?
Responder

Utilizamos cookies para fornecer uma melhor experiência para nossos usuários, consulte nossa política de privacidade.

Aceitar