Porque precisa de ter um id em toda tabela?

[Ricardo Fressa 0]

Olá, meu amigo criou um banco de dados que tem varias tabelas e ele nao colocou nenhum campo id do tipo int... exemplo na tabela clientes dele a Primary Key é o CPF do cliente, na tabela empresa é o campo CNPJ...

 

e sempre vejo varias pessoas sempre colocando um id ou codigo do tipo int na tabela, mesmo contendo cpf, cnpj ou algo que possa diferencias um cadastro de outro...

 

no banco dele também existe a tabela login cuja a primary key é um campo varchar(100) e ele disse que nao seria possivel ter dois logins no sistema dele...

 

alguém pode me explicar essas situações? tem ou nao precisa de um campo id, ou codigo na tabela do tipo int auto increment? Por que?

 

abraços

[Fernando Silveira 1]

Ricardo Fressa

 

Teu amigo nunca ouviu falar em normalização de dados...rs

 

Trabalhar numa estrutura como essa é sem dúvida, se me permite, muito ruim.

 

Recomendo que você pesquise e aplique a normalização de dados assim que possível. Pensando nisso, vou deixar um link aqui para você entender melhor o que é isso.

 

http://pt.wikipedia.org/wiki/Normaliza%C3%..._banco_de_dados

 

Quanto aos problemas que podem ser causados podemos mencionar:

 

• Falha na integridade dos dados

• Consumo em disco desnecessário

• Consulta muito lenta com o passar do tempo

• Grandes dificuldades em futuras alterações na estrutura de dados para atender novas demandas de software

 

Isso são apenas alguns exemplos do que você poderá ter de problemas no futuro.

 

A recomendação é efetuar a normalização dos dados para evitar esses problemas e acima de tudo, ter um banco de dados integro e confiável.

 

Respondendo a sua pergunta, o normal é que uma tabela tenha uma coluna chave primária. Isso é um identificador único da tabela e normalmente são essas colunas que você citou como ID do tipo inteiro (INT). Em raras exceções são utilizados o tipo texto (varchar).

 

Espero que eu tenha ajudado a compreender melhor.

 

Ter integridade e confiança dos dados armazenados é tudo para a empresa!

 

[]’s

 

Fernando Silveira

[Ricardo Fressa 0]

beleza dei uma olhada la no wikipedia e vi... mas o problema que nao tem o porque disso

• Falha na integridade dos dados

• Consumo em disco desnecessário

• Consulta muito lenta com o passar do tempo

• Grandes dificuldades em futuras alterações na estrutura de dados para atender novas demandas de software

??

 

e queria saber porque é ruim ?

 

poderia me explicar mais detalhadamente porque acontece falha, o consumo desnecessario, a consulta lenta, etc....

[Fernando Silveira 1]

Ricardo Fressa

 

Olha, normalização de dados é o princípio "básico" para um boa estrutura de armazenamento de dados. Por isso mencionei que seria necessário estudar melhor isso e aplicar no seu cenário de banco de dados.

 

Quanto as suas dúvidas:

 

• Falha na integridade dos dados. R: Quando você trabalha com uma estrutura que não possui chaves para evitar duplicidade e relacionamento entre as tabelas, você poderá ter um endereço sem um cliente. Isso é um exemplo. O fato de você não poder criar mais de um usuário, como você mesmo mencionou, é outro motivo devido a falta de normalização dos dados.

 

• Consumo em disco desnecessário. R: O consumo em disco desnecessário ocorre devido a falta de normalização novamente. Vou explicar melhor, quando você tem uma tabela que possui uma chave de varchar(100), como você mesmo mencionou, você poderá consumir em disco 100Bytes + 2Bytes por cabeçalho + 2Bytes por ser uma coluna do tipo de dados variável, então você poderá ter até 104bytes por registro se a coluna for toda preenchida, se fosse um registro do tipo INT, você iria consumir no máximo 4Bytes por registro. Agora multiplica 104bytes pela quantidade de registros que você tem na tabela, para piorar, multiplica pela média de registros novos que são cadastrados por mês. Entendeu? Isso porque estamos falando de uma coluna apenas.

 

• Consulta muito lenta com o passar do tempo. R: Sem normalização de dados, ocorre de você não ter chave primária em algumas tabelas e consequentemente não haverá os índices necessários para a realização de uma consulta rápida. Com o tempo, a quantidade de registros na tabela que será maior + a falta de índices, fará com certeza que seu sistema seja bem lento.

 

• Grandes dificuldades em futuras alterações na estrutura de dados para atender novas demandas de software; R: O fato de você não conseguir cadastrar mais de um usuário já é um bom motivo.

 

Acredite, estude sobre normalização e aplique no banco de dados.

 

[]'s

 

Fernando Silveira

[Mário Monteiro 179]

Ricardo, como o Fernando falou a forma como é usada no sistema do seu amigo pode até a principio parecer que estar economizando por ter um campo a menos mas na pratica é a pior coisa que fará pelo seu sistema, pricipalmente pela falta de indices e pelo consumo

 

Recomendo urgentemente alterar isso e aplicar as regras de normalização até a 3ª FN