Será que todas as tabelas precisam de uma Primary Key?

Quando criamos uma tabela, por exemplo no MySQL, executamos o comando:

CREATE TABLE aw_tipo_produto (

id_tipo_produto varchar(1) NOT NULL,

dt_cria timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,

desc_tipo_produto  varchar(100) DEFAULT NULL

);

Depois alteramos a tabela para adicionar a chave primária, ou Primary Key:

ALTER TABLE aw_tipo_produto

ADD PRIMARY KEY (id_tipo_produto);

Inserimos alguns registros, por exemplo:

INSERT INTO aw_tipo_produto

(id_tipo_produto, dt_cria, desc_tipo_produto)

VALUES

('T', '2018-09-11 01:28:01', 'Treinamento on line - Curso'),

('C', '2018-09-11 01:28:01', 'Consultoria - Apoio'),

('L', '2018-09-11 01:28:01', 'Livro on line');

E temos os seguintes registros inseridos:

SELECT * FROM aw_tipo_produto;
id_tipo_produto dt_cria desc_tipo_produto
T 2018-09-11 01:28:01 Treinamento on line – Curso
C 2018-09-11 01:28:01 Consultoria – Apoio
L 2018-09-11 01:28:01 Livro on line

Uma Primary Key do tipo varchar? Sim, podemos criar uma Primary Key do tipo varchar.

Porém é usual? É pratico? Não.

Uma coluna Primary Key não deve fazer parte da regra de negócio, ao contrário, a Primary Key deve ser INsignificante para o negócio em si, pois será utilizada na performance do banco, nos relacionamentos internos entre as tabelas. Regras de negócios podem ser alteradas no decorrer do tempo, e caso a Primary Key não esteja vinculada, ótimo, menos uma dor de cabeça.

Então, vamos remover e recriar a tabela anterior:

DROP TABLE aw_tipo_produto;
CREATE TABLE aw_tipo_produto (

id_produto  int(5) NOT NULL AUTO_INCREMENT PRIMARY KEY,

dt_cria timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,

sigla_tipo_produto varchar(1) NOT NULL,

desc_tipo_produto  varchar(100) DEFAULT NULL

);

Percebam que eu já criei a Primary Key no CREATE TABLE. Ou então, basta alterarmos a tabela para adicionar a Primary Key:

ALTER TABLE aw_tipo_produto

ADD PRIMARY KEY (id_tipo_produto);

Inserimos alguns registros, por exemplo:

INSERT INTO aw_tipo_produto

(sigla_tipo_produto, desc_tipo_produto)

VALUES

('T', 'Treinamento on line - Curso'),

('C', 'Consultoria - Apoio'),

('L', 'Livro on line');

E temos os seguintes registros inseridos:

SELECT * FROM aw_tipo_produto;
id_produto dt_cria sigla_tipo_produto desc_ctipo_produto
1 2018-10-18 22:55:50 T Treinamento on line – Curso
2 2018-10-18 22:55:50 C Consultoria – Apoio
3 2018-10-18 22:55:50 L Livro on line

Ou seja, essa tabela terá um indice criado na coluna id_tipo_produto, o valor nesta coluna não poderá ser repetido e nem nulo (vazio).

É possivel criar apenas 1 Primary Key por tabela, a qual pode ser composta por uma ou várias colunas.

Caso a tabela já tenha uma Primary Key definida e seja necessário que outra coluna tenha um indice que não permita dados repetidos, basta criar nessa coluna um indice do tipo único.

Outro exemplo:

CREATE TABLE aw_produto (

id_produto  int(5) NOT NULL AUTO_INCREMENT PRIMARY KEY,

id_tipo_produto int(5) NOT NULL,

dt_cria timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,

nome_produto  varchar(100) DEFAULT NULL,

desc_produto  varchar(255) DEFAULT NULL,

preco         decimal(9,2)  DEFAULT NULL

);

E em seguida alteramos a tabela acrescentando um indice:

ALTER TABLE aw_produto

ADD KEY nome_idx (nome_produto);

E inserimos alguns registros:

INSERT INTO aw_produto (nome_produto,id_tipo_produto, desc_produto) VALUES

('Curso técnico 01' ,1, 'Conceitos básicos de Modelagem Relacional'),

('Especificacao Startup' ,2, 'Especificacao do zero para Startup'),

('Revisão e Consultoria' ,2, 'Revisão geral e elaboração da Especificação'),

('Qualidade de Vida e Respiraçao' ,3, 'Respiração e Qualidade de vida profissional');

E temos os seguintes registros inseridos:

SELECT * FROM aw_produto;
id_produto id_tipo_produto dt_cria nome_produto desc_produto preco
1 1 2018-10-18 23:13:00 Curso técnico 01 Conceitos básicos de Modelagem Relacional NULL
2 2 2018-10-18 23:13:00 Especificacao Startup Especificacao do zero para Startup NULL
3 2 2018-10-18 23:13:00 Revisão e Consultoria Revisão geral e elaboração da Especificação NULL
4 3 2018-10-18 23:13:00 Qualidade de Vida e Respiraçao Respiração e Qualidade de vida profissional NULL

Neste caso essa tabela terá um indice criado na coluna id_produto e o valor nesta coluna não poderá ser repetido e nem nulo (vazio). Além disso, foi criado um indice na coluna nome_produto.

Mas o que significa ter um índice em uma coluna?

Existem alguns tipos de index, porém o indice mais utilizado num banco de dados é o B+ Tree. Quando a tabela atingir inúmeros registros, por exemplo, 5mil linhas, e for preciso buscar um ou mais registros específicos, ao invés do banco de dados realizer um “full table scan”, ou, pesquisar em cada um dos 5mil registros, quais atendem ao filtro de pesquisa, será executado um processo mais eficiente, através da utilização do índice.

O indice é uma cópia física da coluna original, porém com as informações em ordem alfabética ou numérica, mais o endereço físico daquela linha na tabela original. Caso seja pesquisado a palavra ‘Consultoria’ em uma coluna indexada, a pesquisa irá direto no meio dos registros da coluna organizada (indice), no caso na linha 2.500 e verificará se o valor daquela linha é maior ou menor do que ‘Consultoria’. Se for menor, a pesquisa irá no meio dos registros do primeiro bloco, o qual seria a linha 1.250 e fará a mesma pergunta, afunilando até chegar na resposta. O mesmo ocorre caso ‘Consultoria’ seja maior, a pesquisa irá direto no meio dos registros do segundo bloco, o qual seria a linha 3.750 e fará a mesma pergunda, afunilando até chegar na resposta. Uma vez que a pesquisa identificar a linha correta no indice, esse também  terá o endereço físico do registro na tabela original e irá direto nele, fazendo apenas um acesso direto na tabela original.

Assim, o indice diminui o acesso na tabela de origem para 1 e oferece um tempo de resposta mais rápido.

Então toda Primary Key tem um indice automaticamente criado? Sim.

Mas qual é a diferença entre Primary Key e indice?

A Primary Key, nada mais é do um indice único criado na tabela, o qual pode ser composto por uma ou mais colunas. Será essa coluna, ou conjunto de colunas, que dará a identidade técnica à tabela.

Já os indices podem ser criados independentemente em quantas colunas quisermos, e podem ser índices unicos, não-unicos, entre outros.

Mas se eu não definir uma Primary Key na tabela, dará erro? Não.

Porém…

Para seguir um padrão normativo e garantir a consistência nos dados, é recomendado que seja definido uma Primary Key em cada tabela, e assim, garantir a singularidade de cada registro, para que seja selecionado os registros necessários de forma eficiente. Sem a Primary Key nas tabelas, um banco de dados relacional simplesmente não funciona.

“Uma vez eu criei uma tabela e decidi não definir uma Primary Key, pois não seria necessário… Um tempo depois, voltei na mesma tabela para definir a Primary Key, pois surgiu a necessidade.”

 

“Chegou um certo momento em que eu precisei copiar os registros mais antigo de uma tabela, para outra tabela de backup, e em seguida, remover os mesmos da tabela principal. Minha tabela não tinha nenhuma coluna que identificasse a data em que cada linha havia sido criada… Porém, como eu havia definido uma Primary Key numérica, eu consegui filtrar as linhas mais antigas .”

É isso pessoal! Criem uma Primary Key em TODAS as tabelas do banco de dados de vocês, no mater what! E corram pro abraço 🙂

Flavia Grohmann – AmpliaWeb

 

Um comentário em “Será que todas as tabelas precisam de uma Primary Key?”

  1. Normally I don’t learn article on blogs, however I wish to say that this write-up very
    forced me to try and do it! Your writing style has been surprised me.
    Thanks, very nice article.

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *