| Autor |
Mensagem |
![[Post New]](/templates/default/images/icon_minipost_new.gif) 11/07/2005 14:37:46
|
Thiago Senna
GUJ Master
![[Avatar]](/images/avatar/78719f11fa2df9917de3110133506521.jpg)
Membro desde: 11/02/2005 08:08:02
Mensagens: 1595
Offline
|
Bom renato, truncate é um comando SQL mesmo!
Ele faz algo muito similar ao comando
Mas se não me engano, o truncate é mais poderoso, pois ele afeta a estrutura da tabela, e quando se usa InnoDB deu um erro comigo que custou para descobrir!
DELETE FROM TABLE não gera a tabela novamente, mas, ao invés diato, deleta todas as linhas, uma a uma, o que não é rápido. Em versões futuras do MySQL você poderá usar TRUNCATE que é mais rápido.
A fonte deste texto está aqui: http://netmirror.org/mirror/mysql.com/doc/mysql/pt/innodb-restrictions.html
A fonte está esquisita, mas dá para entender, acho!
Abraços!
Thiago Senna
|
|
|
 |
|
|
11/07/2005 18:18:22
|
renatosilva
GUJ Master
Membro desde: 16/12/2004 17:09:19
Mensagens: 1787
Offline
|
Esse truncate esvazia a tabela de registros, tipo o delete, acho que a diferença é que ele é um comando mais direto, e portanto mais rápido. Eu usei isso via PHPMyAdmin, aparentemente tá tudo ok...
|
|
|
|
11/07/2005 18:19:59
|
renatosilva
GUJ Master
Membro desde: 16/12/2004 17:09:19
Mensagens: 1787
Offline
|
 Opa! O que é isso?
Aviso: NÃO converta o sistema de tabelas MySQL de MyISAM PARA InnoDB! Isto não é suportado; se você fizer isto o MySQL não reiniciará até que você restaure o sistema de tabelas antigo de um backup ou os regenere com o script mysql_install_db.
Num intendi, meu colega fez isso hoje, mas não deu problema nenhum!
|
|
|
|
11/07/2005 19:22:37
|
Thiago Senna
GUJ Master
Membro desde: 11/02/2005 08:08:02
Mensagens: 1595
Offline
|
renato3110 wrote: Opa! O que é isso?
Aviso: NÃO converta o sistema de tabelas MySQL de MyISAM PARA InnoDB! Isto não é suportado; se você fizer isto o MySQL não reiniciará até que você restaure o sistema de tabelas antigo de um backup ou os regenere com o script mysql_install_db.
Num intendi, meu colega fez isso hoje, mas não deu problema nenhum!
Bom.. comigo naum tive este tipo de problema. Talvez dependa da versão do mysql q vc está usando!
Abraços!
Thiagoi
|
|
|
|
11/07/2005 22:35:35
|
ZehOliveira
GUJ Ranger
Membro desde: 12/12/2003 22:13:49
Mensagens: 964
Localização: Maceio-AL
Offline
|
É bom você fazer backup dos dados, quando tá brincando com essas besteirinhas. PRINCIPALMENTE, se for dados em produção.
|
|
|
|
12/07/2005 09:15:50
|
renatosilva
GUJ Master
Membro desde: 16/12/2004 17:09:19
Mensagens: 1787
Offline
|
O próximo passo é descobrir como fazer backup no MySQL, principalmente agendado...
|
|
|
|
12/07/2005 09:33:59
|
Rodrigo Carvalho Auler
Virtual Machine Man
Membro desde: 14/02/2003 15:59:17
Mensagens: 576
Localização: Rio de Janeiro
Offline
|
renato3110 wrote:O próximo passo é descobrir como fazer backup no MySQL, principalmente agendado...
Ué... é só agendar uma tarefa no cron que executa uma linhazinha de comando...
[]'s
Rodrigo C. A.
|
|
|
|
12/07/2005 10:08:47
|
Thiago Senna
GUJ Master
Membro desde: 11/02/2005 08:08:02
Mensagens: 1595
Offline
|
aff...
[off topic + desabafo]
Alguém tá de marcação comigo!
Estão arrancando minhas poucas estrelas que suei tanto para conseguir!
Vêde meus dois posts acima!
O que eu fiz de tão errado???
[off topic + desabafo] 
This message was edited 1 time. Last update was at 12/07/2005 10:09:19
|
|
|
|
12/07/2005 10:43:55
|
renatosilva
GUJ Master
Membro desde: 16/12/2004 17:09:19
Mensagens: 1787
Offline
|
Rodrigo, deve ter algum utilitário via shell que posso usar no Linux pra mandar fazer o backup né? Vou pesquisar entaum... valeu.
|
|
|
|
12/07/2005 12:50:38
|
Rodrigo Carvalho Auler
Virtual Machine Man
Membro desde: 14/02/2003 15:59:17
Mensagens: 576
Localização: Rio de Janeiro
Offline
|
renato3110 wrote:Rodrigo, deve ter algum utilitário via shell que posso usar no Linux pra mandar fazer o backup né? Vou pesquisar entaum... valeu.
Tá na mão
[]'s
Rodrigo
|
|
|
|
12/07/2005 14:53:06
|
renatosilva
GUJ Master
Membro desde: 16/12/2004 17:09:19
Mensagens: 1787
Offline
|
Valeu Rodrigo, vou dar uma olhada...
|
|
|
|
02/07/2008 18:39:02
|
webermarques
Smalltalk
Membro desde: 02/07/2008 18:22:31
Mensagens: 1
Offline
|
Caros colegas!
Estou gostando da conversa de vcs! Realmente nos faz pensar um pouco...
Estou com um problema em um projeto.
Estou pegando um sistema de terceiros (desenvolvido em Microsoft SQL Server + Delphi + Cristal Reports) e passando esse sistema para PHP + MySQL.
Missão impossível? Nem tanto...rs
Mas agora que já modelei o novo sistema para ser compatível com o antigo (pois o cliente não pode perder os dados atuais) esbarrei num problema:
Tenho uma tabela chamada empresas, que obviamente tem campos do tipo: codigoEmpresa, razaoSocial, endereco, cnpj, inscricaoEstadual, etc...
O campo codigoEmpresa é auto incremento e chave primária.
O campo cnpj é um índice único.
O campo inscricaoEstadual é um índice único, porém podendo ser nulo.
Quando tentei executar o SQL para importar os dados, uma surpresa desagradável. O programador que desenvolveu o sistema antigo não tomou o cuidado de modelar o banco de dados, de maneira que tenho mais de uma empresa com o mesmo cnpj, causando erro de duplicidade.
Analisando os dados duplicados na chave cnpj, me veio a seguinte indagação:
CNPJ deve ser mesmo usado como campo chave única? 
Se existir uma empresa com filiais, cada um terá seu cnpj, ou o cnpj é o mesmo para as filiais? E no caso da inscricaoEstadual e inscricaoMunicipal, como ficam?
Espero contar com a ajuda de vcs!
Forte abraço,
Weber
|
|
|
|
|
|
![[Up]](/templates/default/images/icon_up.gif){kind=icon}
![[Email]](/templates/default/images/icon_email.gif){kind=icon}