Iniciar sesiónCerrar
Correo:
Contraseña:
Entrar
Recordar sesión en este navegador
Iniciar sesiónIniciar sesiónCrear cuentaCrear cuenta
LWP » Foros » SQL » Uso de disparador

SQL - Uso de disparador

Volver
Nuevo Tema
<<>>
 
Vista:

Uso de disparador

Publicado por Alejandro (2 intervenciones) el 08/05/2017 03:10:30
Muy buenas noches, tengo una duda y me gustaría saber si alguien me puede ayudar en este tema.
Aún no soy muy bueno en esto de las base de datos.

Les platico un poco, tengo un proyecto de una empresa que se dedica a dar créditos en línea, y tengo una tabla en la base que se llama cliente, al momento de ser registrado, se le da un estatus a la solicitud, pre aprobado , aprobado, rechazado y cancelado, el problema es que en caso de que sea rechazado y/o cancelado, se debe agregar una razón de rechazo/cancelación.

Mi pregunta es la siguiente ¿Es mejor crear tres tablas en las que se especifique el estatus? ej: clientes_rechazados, clientes_aprobados, etc, si es así, los clientes que se encuentres como pre aprobados pueden cambiar de status, y el gran problema es , ¿Se puede hacer un disparador que elimine la tupla en la tabla actual y lo agregue a la tabla del status correspondiente?, si se puede ¿Cómo se hace?.

Muchas gracias por leer y espero que me puedan ayudar.
Valora esta pregunta
Me gusta: Está pregunta es útil y esta claraNo me gusta: Está pregunta no esta clara o no es útil
0
Responder
sin imagen de perfil
Val: 806
Bronce
Ha mantenido su posición en SQL (en relación al último mes)
Gráfica de SQL

Uso de disparador

Publicado por leonardo_josue (1175 intervenciones) el 08/05/2017 16:00:41
Hola Alejandro:

En el modelado de Base de Datos no hay una "mejor" forma de hacer las cosas, sino que el modelo simplemente se debe adaptar a lo que necesitas y si cumple con eso entonces es el modelo Ideal, sin embargo vale la pena que tomes en cuenta algunos puntos de vista y/o consejos:

1
¿Es mejor crear tres tablas en las que se especifique el estatus? ej: clientes_rechazados, clientes_aprobados, etc,

No es recomendable que tengas la información en tablas separadas, sino que es mejor que la tengas en una sola, y la razón es muy simple: ¿qué pasaría si el día de mañana la empresa en la que trabajas decide agregar 1 o más estatus? pues que tendrías que agregar 1 o n tablas para mantener el modelo funcional. Lo correcto es simplemente tener un modelo con tres tablas: CLIENTES con los nombres de cada uno de los clientes, ESTATUS como un catálogo con todos los estatus que puede tener un ciente y CLIENTES-ESTATUS que sería una relación entre ambas tablas... ¿se entiende?

1
¿Se puede hacer un disparador que elimine la tupla en la tabla actual y lo agregue a la tabla del status correspondiente?

Imagina que a pesar de lo que puse arriba decides tener tus tablas por separado, entonces lo que quieres hacer lo puedes hacer mediante "TRIGGERS" o "DISPADADORES" aunque en realidad este no es el propósito con el que fueron creados. Además, por experiencia te digo que NO ES RECOMENDABLE HACER ELIMINACIONES COMO LAS QUE PLANTEAS... Las empresas por lo general les interesa tener un HISTÓRICO de cada uno de sus CLIENTES ya que esta es información que resulta de utilidad... con el modelo como lo estás planteando entonces NO PUEDES SABER POR QUÉ ESTÁTUS HA PASADO UNA SOLICITUD... de tal suerte que no se puede dar un seguimiento.

Con el modelo que propongo al inicio, simplemente basta con agregar un campo de FECHA para saber en qué momento ocurrió un cambio de estatus y así llevar el histórico de manera implícita, checa este ejemplo:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
CLIENTES
+----------+------+
|id_cliente|nombre|
+----------+------+
|         1|uno   |
+----------+------+
|         2|dos   |
+----------+------+
|         3|tres  |
+----------+------+
 
ESTATUS
+----------+-----------+
|id_estatus|descripcion|
+----------+-----------+
|         1|preaprobado|
+----------+-----------+
|         2|aprobado   |
+----------+-----------+
|         3|rechazado  |
+----------+-----------+
|         4|cancelado  |
+----------+-----------+
 
CLIENTES_ESTATUS
+-------------------+----------+----------+----------+
|id_clientes_estatus|id_cliente|id_estatus|fecha     |
+-------------------+----------+----------+----------+
|                  1|         1|         1|2017-05-01|
+-------------------+----------+----------+----------+
|                  2|         1|         2|2017-05-05|
+-------------------+----------+----------+----------+
|                  3|         2|         1|2017-05-02|
+-------------------+----------+----------+----------+
|                  4|         2|         4|2017-05-03|
+-------------------+----------+----------+----------+
|                  5|         1|         3|2017-05-08|
+-------------------+----------+----------+----------+

Observa que los clientes pueden tener más de un estatus (como el caso de los clientes UNO y DOS), para obtener el estatus "ACTUAL" simplemente obtienes el que tenga la fecha más reciente (MAX fecha).

Si la empresa decidiera agregar un nuevo ESTATUS, entonces simplemente SE AGREGA UN REGISTRO A TU TABLA CATÁLOGO, pero no tienes que hacer absolutamente ninguna modificación a la estructura de tus tablas ni mucho menos crear nuevas tablas... Dale un vistazo y nos comentas.

Saludos
Leo.
Valora esta respuesta
Me gusta: Está respuesta es útil y esta claraNo me gusta: Está respuesta no esta clara o no es útil
0
Comentar

Uso de disparador

Publicado por Alejandro (2 intervenciones) el 10/05/2017 06:56:42
Hola Leo, muchas gracias por tomarte el tiempo para ayudarme y por la sugerencia, no había pensado en realizar de esa manera el estatus, pero creo que tienes razón, solo hay algo que me continua conflictuando, si realizo una sola tabla de clientes, solo se pondría razón de rechazo y/o cancelación en caso de que el cliente se haya rechazado y/o cancelado, no me parece optimo el agregar un Id_razon_rechazo a la tabla clientes_estatus, si solo se va a utilizar para casos específicos, sin embargo me pregunto si se puede usar una condicional, (reitero que aun no soy bueno en BD), para de alguna manera agregar esa razón únicamente en esos dos estatus, ya que de cualquier manera (desde mi punto de vista) se tendría que usar un registro que en muchos casos no tendría sentido,

Ejemplo:

Si tenemos dos clientes, el primero con un estado de pre_aprobado y el segundo con un estatus de rechazado,
al primero no se le pondrá ninguna razón de rechazo , a menos que en un futuro sea rechazado, pero por el contrario si el cliente es aprobado, esa razón jamás se utilizará, sin embargo para el segundo caso nos interesa saber por que razón se esta rechazando a este cliente (si es un posible fraude, o tal vez esta en buró de crédito con mal historial)

Nuevamente muchas gracias por la ayuda y espero que me de a entender
Saludos
Valora esta respuesta
Me gusta: Está respuesta es útil y esta claraNo me gusta: Está respuesta no esta clara o no es útil
0
Comentar
sin imagen de perfil
Val: 37
Ha mantenido su posición en SQL (en relación al último mes)
Gráfica de SQL

Uso de disparador

Publicado por Jorge (19 intervenciones) el 10/05/2017 16:49:44
no sería eso con una tabla extra, digamos clientes_rechazados

además de las 3 tablas CLIENTES, ESTATUS, CLIENTES_ESTATUS se agregaría una CLIENTES_RECHAZADOS
digamos

1
2
3
4
5
6
7
8
CLIENTES_RECHAZADOS
+-------------------+----------+------------------------+----------+
|id_clientes_rechazo|id_cliente|Motivo                  |fecha     |
+-------------------+----------+------------------------+----------+
|                  1|         1|fraude                  |2017-05-01|
+-------------------+----------+------------------------+----------+
|                  2|         3|documentación incompleta|2017-05-05|
+-------------------+----------+------------------------+----------+

y en la aplicación que utilizas si se rechaza entonces se abre un campo para escribir solo el motivo
que se insertará en la tabla usando el id_cliente y fecha de CLIENTES_ESTATUS
sin necesidad de mover el cliente de una tabla a otra

y digamos que a la hora de llenar o consultar la ficha del cliente se hace una consulta a la tabla CLIENTES_RECHAZADOS
ordenada por fecha para saber si en algún momento ha sido rechazado por algún motivo
y ya si no encuentra el cliente en la tabla, pues es porque no ha sido rechazado nunca

ahora si quisieras que cada estado tuviese su motivo especificado NO sería buena idea crear una tabla por cada estatus, ahora tienes 4 estados que pasaría si en el futuro aparecen 3 estados más entonces meter mano a la BD y crear 3 tablas más, si después hay 10 estados más entonces 10 tablas más a la BD, pues no

en ese caso nos olvidamos de la tabla anterior de Clientes_rechazados y hacemos una tabla cruzada
de esta forma
1
2
3
4
CLIENTE ------- ESTATUS
     \           /
      \         /
    CLIE_EST_MOTIVO

quedando así:
1
2
3
4
5
6
7
8
9
10
CLIE_EST_MOTIVO
+----------+----------+------------------------+----------+
|id_cliente|id_estatus|Motivo                  |fecha     |
+----------+----------+------------------------+----------+
|         1|         3|fraude                  |2017-05-01|
+----------+----------+------------------------+----------+
|         3|         3|documentación incompleta|2017-05-05|
+----------+----------+------------------------+----------+
|         3|         4|problemas personales    |2017-05-10|
+----------+----------+------------------------+----------+

como ves en la nueva tabla están los motivos para el estatus rechazado (3) y cancelado (4) y si en el futuro quieren saber el motivo de porque un cliente está pre-aprobado, entonces se añade en esta tabla y luego se hace la consulta
si aparece un nuevo estatus digamos de "en espera" y queremos saber porque está en espera
se añade un nuevo registro a la tabla ESTATUS
1
2
|         5|en espera  |
+----------+-----------+
y en la tabla CLIE_EST_MOTIVO se añade el código del cliente, el código del estado "en espera" y se escribe el motivo
1
2
|         2|         5|esperando firma de jefe |2017-05-11|
+----------+----------+------------------------+----------+
y eso

Saludos.
Valora esta respuesta
Me gusta: Está respuesta es útil y esta claraNo me gusta: Está respuesta no esta clara o no es útil
0
Comentar