Tenho uma pergunta sobre modelagem:
Qual a vantagem de relacionar tabelas (usando chave estrangeira) se nunca for preciso usar cláusulas como UPDATE, DELETE… (pra promover efeitos de cascata etc) ? Nesse caso (tabelas que se relacionam mas não são dependentes umas das outras), não seria melhor deixar desconectado?
Por exemplo: Se eu tiver uma entidade chamada RELATÓRIO e outra chamada ALUNO. Em RELATÓRIO, deve haver um campo chamado Criador que deve fazer referência ao nome de algum ALUNO. Mas se algum dia esse aluno for descadastrado do banco, não vou querer apagar os relatórios que ele fez. Eles podem continuar existindo, com um registro do nome do aluno, mesmo que esse nome não signifique nada pro banco.
Portanto, não seria melhor deixar o “relacionamento” a nível de aplicação, fazendo o campo Criador ser um VARCHAR? A aplicação vai setar Criador com um nome de aluno, sem que o banco precise saber disso… então eles estariam relacionados, mas a existência de um não dependeria do outro…
Oi,
Leia esse Livro!
Fazer o que você tá sugerindo vai de encontro a regras como Normalização, Integridade de Dados…coisas que os fabricantes de SGDB se esfoçaram muito para tornar possíveis…por favor, nunca faça isso em nenhuma aplicação, existem formas mais “usáveis” de desabilitar um Aluno como criar um atributo como: ATIVO (SIM/NAO).
[quote=rafaelglauber]Oi,
Leia esse Livro!
Fazer o que você tá sugerindo vai de encontro a regras como Normalização, Integridade de Dados…coisas que os fabricantes de SGDB se esfoçaram muito para tornar possíveis…por favor, nunca faça isso em nenhuma aplicação, existem formas mais “usáveis” de desabilitar um Aluno como criar um atributo como: ATIVO (SIM/NAO).[/quote]
Obrigado pela resposta, Rafael. Eu já tinha pensado nessa possibilidade do campo ATIVO, mas achei que a outra forma que eu falei daria nas mesmas consequências, com menos esforço. Mas se é realmente importante estabelecer essas conexões no banco, então vou fazer o ATIVO mesmo.
Sem querer abusar do tópico, mas já abusando, queria perguntar uma outra coisa básica:
Alguém me falou uma vez que é bom sempre criar IDs para as chaves primárias, por questão de otimização, porque valores INT são comparados mais rapidamente, aproveitando melhor a indexação. Isso compensa mesmo?
Por exemplo, no exemplo que eu dei, seria bom eu criar um Id para ALUNO mesmo que ele tenha o nome como chave candidata?
Nesse caso, eu deixaria o campo Nome com a cláusula UNIQUE (pra certificar que é única, mesmo sem ser chave) e o campo Criador de RELATÓRIO seria um INT (referenciando Id de ALUNO).
Isso procede?
Oi,
É extremamente recomandado que todas as tabelas tenham chave primária…Seguindo essa linha é ainda recomendado que seja uma chave simples e que o campo seja um inteiro, logo o que você afirmou procede sim. Chaves compostas são ruins pois o banco tem que indexar mais de uma coluna (perde um pouco do desempenho nas inserções), além de obrigar o programador a testar mais de uma coluna para realizar junções (sempre alguem esquece alguma das colunas ou mesmo trocam as ordens).
Sempre é bom utilizar as ditas “boas práticas”, elas são chamadas assim por que dão certo!