Trigger, do inglês “gatilho”, é o nome dado a procedimentos armazenados numa base de dados e activados por eventos específicos numa tabela. No conhecido SGBD MySQL (agora da Sun) foram introduzidos na versão 5.0.2.
Toda a documentação relativa ao uso de Triggers poderá ser consultada no site do MySQL, devendo dedicar-se especial atenção à Secção D.1. “Restrictions on Stored Routines, Triggers, and Events” relativa às restrições a que estes estão sujeitos.
Estas linhas devem-se ao tempo que perdi ao tentar justificar o erro: “Not allowed to return a result set from a trigger“.
À semelhança dos procedimentos, qualquer operação de extracção de informação, entre outras (ver restrições), tem obrigatoriamente de ser feita para variáveis definidas pelo utilizador (incluo nestas a possibilidade de os dados serem enviados para ficheiro).
Estando agora consciente destas restrições deixo um exemplo para aqueles que depararem com esta limitação:
1 2 3 4 5 6 | CREATE TRIGGER teste AFTER INSERT ON tabela FOR EACH ROW BEGIN SET @newID; SELECT @newID:=NEW.id; END; |
Embora o valor de NEW.id seja armazenado na variável previamente definida, o resultado da execução do trigger será um set com o elemento @newID.
A fórmula de sucesso segue abaixo:
1 2 3 4 5 6 | CREATE TRIGGER teste AFTER INSERT ON tabela FOR EACH ROW BEGIN SET @newID; SELECT NEW.id INTO @newID; END; |
Wow, esse ‘for each row’ dá muito mais jeito que abrir, configurar e fechar cursores no sql server =S
em jeito de devaneio..
isto fez-me pensardos id’s e o auto-increment. que por sua vez me fez pensar nos guids.
ao inserir um registo podemos ter um id já feito e deixamos de precisar de auto-increment.. bla bla
já vistes isto?
http://pt.wikipedia.org/wiki/GUID
http://pt2.php.net/manual/en/function.com-create-guid.php
@Paulo Afonso: Sinto-me honrado em ter-te por cá.
Regra geral tenho o cuidado de avaliar a real necessidade de ter um identificador único por registo, mas reconheço em muitas situações que, para muitos, é apenas mais um “campo” numa tabela. No entanto, tendo como referência o MySQL e uma tabela MyISAM, representa 4bytes “extra” a armazenar pelo que é um factor de crescimento considerável.
Se preciso numerar documentos sequencialmente então não penso duas vezes, tendo no entanto o cuidado de o “rentabilizar”, definindo-o como unsigned int.
Quando aos GUIDs deixaste-me a pensar se serão uma alternativa vantajosa. Daqui surgiu a questão do seu armazenamento numa base de dados, num atributo do tipo String? O Inteiro sai claramente a ganhar. Em binário? O GUID são 16bytes (128-bit).
Gostava que desenvolvesses, se possível aqui :), o teu “devaneio” porque achei interessante.
Deixo só uma referência à entrada[1] da en.wikipedia.org pois está bem mais completa.
[1] http://en.wikipedia.org/wiki/GUID
Cada caso é um caso. De certeza que ambas soluções têm vantagens dependente da aplicação.
A respeito de tamanho e sequência unsigned int com auto increment sai a ganhar destacado.
Os guid podem ser gerados sem aceder à base de dados, isto traz enumeras vantagens por podes criar um novo id sem estares directamente dependente dos anteriores. Por exemplo imagina um 1000 comerciais com os seus pda’s a criar registos novos e ao fim do dia sincronizar com a base de dados central..
Ou então que não estavas interessado em revelar aos teus clientes quantos registos de clientes tinhas, com o id autoincrement com um bocado de vontade e astucia podes fazer até médias de quantas pessoas se registam etc..
Isto foi alguns casos que me ocorreram à medida que ia escrevendo, mas à muito mais. É googlar hehe.
Links
http://www.codinghorror.com/blog/archives/000817.html
http://krow.livejournal.com/497839.html