Olá!
rossine escreveu:Neste caso, há a necessidade de se criar este index "indice_princ" para agilizar as pesquisas, ou não precisa disto ?
Não, não precisa. Se você criar uma primary key para a tua tabela, o que é altamente recomendável, isto já será seu Ãndice principal. Criar a primary key e um Ãndice adicional com as mesmas colunas da PK será uma redundância e desperdÃcio de recursos do sistema...
JoséQuintas escreveu:Então:
1) Acostume a criar um Ãndice pela chave primária SEMPRE, de preferência um campo incremental.
Isto não ficou claro para mim. Você recomenda criar a PK e o Ãndice? Ou "criar um Ãndice pela chave primária" quer dizer criar a PK?
Lembrando que uma primary key não aceita valores duplicados ou NULL e que cada tabela pode ter apenas uma primary key. Prymary keys são semelhantes aos unique indexes mas, estes últimos podem conter NULL e uma tabela pode ter mais de um unique index. Procure evitar primary keys compostas (formadas por mais de uma coluna).
rossine escreveu:Já vi que existe duas formas que são o "replace" e o "insert ... on duplicate key"
Além das formas que você citou, existe o INSERT IGNORE, citado anteriormente.
Evite usar REPLACE. Este comando, quando necessário (quando já existe a linha desejada), ele faz um DELETE
E depois um INSERT, consumindo mais recursos que um INSERT ... ON DUPLICATE KEY UPDATE que faz um INSERT
OU UPDATE, como no exemplo abaixo.
INSERT INTO books
(id, title, author, year_published)
VALUES
(@id, @title, @author, @year_published)
ON DUPLICATE KEY UPDATE
title = @title,
author = @author,
year_published = @year_published;