PostgreSQL - uso de trigger

Saludos tengo una duda, estoy diseñando una base de datos en postgres 8.0 y hay unas tablas que tienen unos campos de estado y status, en los cuales tiene solo dos valores 1 o 0 pero en un futro estos podiran cambiar o anumentar, por ejemplo

el campo estatus tiene actualmente 0- inactivo 1-en ejecucion

pero en un futuro pueden haber status como en espera, parcialmemte ejecutada, etc...

mis supervisor no le gusta la idea de hacer una "tablita" para estos campos porque sereia ineficiente por as cantidda de join a estas tablas que contendrian dos o tres registros con al ta probabilidad, asi se estab tomado la idea de simplemente dejar campos con valores numericos y desde la programacion se da la logina de lo que significa, es decir se graba el 1 o el 0 o el 2 y en ekl codigo y documentacion se indica que significa.... pero pense en crear una cmpo adiconal que guarde el valor que lo que significa esto, es decir un trigger que al insertar o actualizar este valor por ejmplo 1 guarde lo que significa que es "en ejecucion" en otro campo y de esta manera la logica del negociuo se mantendria en la base de datos.... mi objetivo es teste que el negocio este en bd y nada en el codigo.

el problema es que no se si seria recommendable usra tantos trigger para esta accion que no es tan escenciual, de verda esperod e sus opiniones. muchas gracias

Hola

Si lo que quieres es separar la aplicación por capas, en la base de datos devería ser la capa de datos, no de lógica del negocio.

la idea de una tabal adicional es buena, pero tu supervisor tiene razón, para que una tabla que devuelva 1 o 0?, tambien tiene razón diciendo que mejor hacer el campo numérico y que desde la aplicación se le da el sentido para visualizarlo, pero el punto donde tu supervisor puede estar fallando es que si se prevé crecimiento es mejor hacer la tabla de una vez, ya que va a ahorrar el tiempo que vaya a tomar cambiar el código para que visualice los nuevos valores, simplemente los va a mostrar y ya en lugar de tener que ir a ala aplicación, cambiar el if por un case y decirle a la aplicación que visualizar en cada caso y luego ir y probar que funcione bien. En cambio con una tabla solo lo probarás para estos dos registros y listo! si luego quieren agregar 10 estados mas ya la aplicación contemplaba eso y los va a visualizar sin tener que agregar una línea de código, eso si, va a requerir un poco mas de esfuerzo al principio que hacer un if para visualizar, pero definitivamente mucho menos que hacer los cambios en el código cuando decidan poner mas estados.

Espero haberte ayudado.

Saludos

Franklin Gamboa

si gracias por tu respuesta, como lo dices si puede ser que cambie pero muy poco probable que sean mas de dos estados adicionales ahora son dos, cpuede ser que sean maaximo 5, por eso no se usuaria una tabla, pero mi pregunta seria que es mejor como buena practica de programacion, asignarle el valor logico desde el codigo, hacer una tabla, o con un trigger que lo haga en la bd?

En el caso que expones desde el código me parece mejor, ya que la base de datos es para almacenar datos del negocio, no reglas del negocio ni el negocio como tal; para esto ya están las capas superiores que modifican la forma en que se visualiza la información para que sea congruente a las reglas de negocio.

La verdad con la idea del trigger me parece que, y te digo esto con todo el respeto del mundo, te estas complicando mas de la cuenta. Recuerda que a fin de cuentas estas son cosas que los usuarios dan por sentadas, y no vale la pena desgastarse mucho como programador en algo que al final ni siquiera van a notar y que inclusive puede generar problemas a futuro (imaginate un ambiente distribuido, donde tu trigger bloqueee la tabla que está haciendo la inserción y que hayan otros cien usuarios haciendo lecto-escrituras al mismo tiempo a esa misma tabla, generando deadlocks y trayendose al piso el rendimiento del servidor si fueran muchisimos usuarios concurrentes; entonces con esto último en cuenta, cuanto dañará este trigger el performance de la aplicación?); y a fin de cuentas el usuario nada mas quiere saber si esta durmiendo o corriendo.

Yo la verdad te recomiendo que entre mas simple sea, mas fácil es, tanto para ti como para el usuario.

Espero haberte ayudado.

Saludos,

Franklin Gamboa

Es simplemente seguir las reglas de normalización, no las reglas de tu supervisor.
Si el campo en cuestion va a crecer en un fututo cercano o lejano, no importa, simplemente si el campo tiene probabilidades de crecer, entonces se crea una tabla extra.