Se puede hacer esto en mysql, postgres??

[Carxl]

Hola a todos!!, una duda en DB, la respuesta me puede servir para mysql o postgres...

Siempre que he necesitado que ciertos campos tipo textos en una tabla no se repitan lo he validado mediante programación. Es decir, si tengo una tabla "usuarios", con campos nick y contraseña, la idea serìa que no duplicaran el nick.

Entonces para esto, siempre hago una consulta previa buscando ese nick, sino se encuentra sigo con el proceso y si sí, pues aviso que no se puede repetir.

Hay alguna manera de hacer esto directamente con la DB??, osea que al hacer un insert o un update, valide automàticamente que no se repita ese campo?? Creo que eso serìa un "disparador" (triggers). Alguien me puede dar una luz de como se harìa??

Muchas gracias de antemano Saludos

[matanga]

Hola,

No hay nada mas rapido que crear un indice unique sobre el campo, nick por seguir con el ejemplo, de esta manera cuando haces un insert o update, si el valor esta repetido, la base de datos te devuelve una excepcion.

Saludos

[Carxl]

Hola matanga, gracias por responder

Lo que necesito saber es si un trigger y/o un procedimiento almacenado me puede suplir esta necesidad.

Saludos

[matanga]

Hola,

Un trigger o un procedimiento lo pueden resolver sin problemas, pero la forma mas eficiente de hacerlo es a traves de un indice unique, por varias razones,

1. Para esto mismo estan pensados los indices unique, para validar que no existan valores repetidos.
2. El indice resuelve la unicidad mucho mas rapido que un bloque de programacion.
3. No necesitas programar nada, solo crear el indice.

Saludos

[Carxl]

Hola matanga, gracias por tu respuesta

El ejemplo que puse del nick fue un ejemplo para hablar sobre triggers realmente no lo necesito de esta manera, osea realmente no es que tenga un problema con esto, además utilizos pk numéricas

Puedes facilitarme un ejemplo de como sería con tiggers o un procedimiento?? O una página que lo explique??

De nuevo muchas gracias por tu ayuda

[seyko]

Carxl como te dice matanga para lo que quieres no te hace falta un trigger. Con UNIQUE te sobra y es lo más eficiente.
Si lo que quieres hacer es otra cosa, cuentala!

Un saludo

[Carxl]

Hola seyko, cómo vas??

Mira es que quiero comenzar con esto de los triggers y procedimientos almacenados. Quiero mirar primero triggers, por lo que puse ese ejemplo a manera "gràfica" no por que lo necesite

Sería bueno tener una idea de como realizar este tipo de cosas cuando las necesite... la idea es tener un ejemplo de como se harìa, y me diò por decir ese (el del nick), pero si tienen otro que me permita aclarar mi duda, pues no hay problem

Ahhh otra cosa, un trigger me permite hacer select? O sólo cálculos?? Es que las pàginas que he visto me muestran son cálculos y no consultas (selects)

Gracias de antemano

[seyko]

Buenas,
En realidad, en postgres, un trigger es una llamada a una funcion que devuelve un trigger.
Por tanto cualquier cosa que puedas hacer en una funcion, debería poder hacerse en un trigger.
Ahora, un trigger solo debe utilizarse cuando realmente sea necesario. Pero puedes insertar en otra tabla, registrar la accion, hacer select, update, etc. vamos que se puede hacer cualquier cosa.
Yo los utilizo sobre todo para añadir logica a la BD y detectar posibles errores en la logica de la aplicacion.

Un saludo

[Carxl]

Hola de nuevo seyko, gracias por tu respuesta! Me queda claro lo que se puede hacer con un trigger...

Ahora bien, por que lo de "un trigger solo debe utilizarse cuando realmente sea necesario"?? Por recursos de la Db?? mas demorados??

Saludos

[seyko]

Buenas,
Si haces algo con un trigger que se puede hacer con una caracteristica de la BD logicamente es más lento y más propenso a fallos.
Siguiento tu ejemplo, si en lugar de evitar valores duplicados con un UNIQUE lo haces con un select
es bastante más lento, y más si la tabla tiene muchos registros.

Otro punto, es que si llenas una BD de triggers, por ejemplo:
La tabla A tienen un trigger y al insertar el trigger inserta en la tabla B y esta a su vez tiene un trigger ......
El mantenimiento, la depuración de un error, etc se hace cada vez más insufrible.

Esto es más una opinión personal, pero creo que es una buena practica.

Un saludo

[matanga]

Hola,

Siguiento tu ejemplo, si en lugar de evitar valores duplicados con un UNIQUE lo haces con un select
es bastante más lento, y más si la tabla tiene muchos registros.

Otro punto, es que si llenas una BD de triggers, por ejemplo:
La tabla A tienen un trigger y al insertar el trigger inserta en la tabla B y esta a su vez tiene un trigger ......
El mantenimiento, la depuración de un error, etc se hace cada vez más insufrible.

Probablemente el consejo mas sabio que he visto desde que estoy registrado en este foro. Existen numerosas notas escritas por personas, a las que considero referentes en diseño bases de datos y reglas de negocio, que opinan sobre la mala implementacion de triggers.

Saludos

[Carxl]

Gracias por las respuestas... Una mas

Osea que en sus opiniones... los triggers no son aconsejables?? Y los procedimientos almacenados??

Saludos

[Gabo77]

como bien dicen por ahi, la solución es con una PK. Ahora si eres curioso y quieres hacer algo, puedes poner en un procedimiento almacenado algo como esto (conste que es solo un ejemplo)

Código:

Create Procedure SpAltaUsuario
(
    @Nick As VarChar(10),
    @Nombre As VarChar(50),
    @Error As VarChar(20) OutPut
)
As
If Exists(Select 1 From TbUsuarios Where Nick = @Nick) Begin
    --El Nick ya existe
    Set @Error = 'El Nick: ' + @Nick + ' ya está ocupado'
End
Else Begin
    --el Nick no existe, lo damos de alta
    Insert Into TbUsuarios(Nick, Nombre)
    Values(@Nick, @Nombre)

    Set @Error = ''
End

OJO: para que este código sea óptimo, la tabla usuarios debe tener un indice en el campo Nick, y además este debe ser la llave de tu tabla.

en tu aplicación solo deberás validar el retorno de la variable @Error, si es <> '' entonces es un error y lo presentas en tu APP.... el manejo de error es un ejemplo, pero hay mejores formas de tratarlo... solo te muestro la mas sencilla.

Saludos!

[Gabo77]

aahh por cierto.... yo no aconsejo los triggers para nada.... :p pero es solo mi punto de vista..

saludos!

[Carxl]

Hola Gabo77, muchas gracias por tu respuesta Ya me va quedando claro

Osea que en definitiva es mejor utilizar procedimientos almacenados que triggers... Pero es bueno aprenderlos para mirar el por que no

Saludos a todos y gracias nuevamente por la colaboración!!!

[seyko]

matanga me voy a poner :$

Osea que en definitiva es mejor utilizar procedimientos almacenados que triggers... Pero es bueno aprenderlos para mirar el por que no

No exactamente, son cosas distintas y tienen funciones distintas.

Por ejemplo, para rellenar campos de auditoria un trigger es la mejor opción.
Para crear un log de cambios realizados en una tabla en concreto, un trigger es la mejor opción.
....

Cada uno tiene su utilidad y su momento.

Un saludo

[Carxl]

Hola seyko, ya voy entendiendo...

Así como pusiste un ejemplo para los triggers... en que momento es mejor un procedimiento??

Saludos y gracias a todos

[seyko]

Yo los uso mucho para hacer cambios "grandes", por ejemplo tengo un registro que tengo que cambiar, pero el dato que conozco está en otra tabla con relaciones complejas, y hay que hacer una serie de comprobaciones y acotar el registro a modificar.

Para evitar repetir todo el proceso cada vez que quiero hacer una modificación, tengo una funcion a la que le paso un parametro.

Dentro de la funcion realizo una serie de comprobaciones y en caso de no pasar una comprobación lanzo una excepcion que luego es capturada en la aplicación.

Un procedimiento almacenado es una función, tiene las mismas caracteristicas que una funcion en cualquier lenguaje de programación.

Saludo