Triggers y SP

[Cañones]

Hola a todos.
Esta consulta no se si ira aca o en SQL, pero lo que quiero saber es si no hay problemas de que para tres tablas, cree tres Trigger para pasar a Mayusculas el campo nombre asi es mas facil para las futuras busquedas y quede mas prolijo a la hora de mostar los datos.
Tambien me gustaria saber hasta que punto se pueden crear SP en la base, porque a mi me gusta tratar de hacer todo en el servidor, tampoco son cosas del otro mundo.
Yo hice una aplicacion con Delphi 6 y Firebird 1.5 trabajando localmente.

Saludos a todos.

[TJose]

Hola Cañones

yo he utilizado ese modelo que planteas, el de introducir toda las reglas de negocio en el servidor (Firebird en mi caso) a través de procedimientos, triggers y udfs. Nunca he tenido problemas, es más te da la flexibilidad de realizar correcciones o modificaciones sin necesidad de compilar y distribuir el exe.

Hace un tiempo planteaba en el la sección debates el tema de donde colocar las reglas de negocio, pero no se bien que pasó con el hilo, creo que se perdió porque se corrompió la base de datos.

La contra de introducir las RN en la base de datos es que te haces muy dependiente de ésta. Si bien los diferentes lenguajes sql son muy parecidos implica volver ha escribir todos los procedimientos y triggers (si es que son soportados), si se desea migrar a otra base de datos.

Saludos
TJose

[Cañones]

Gracias por tu pronta respuesta.
Mira, Yo utilice SQL estandar 3 y trato de no usar muchas funciones.
Ahora, Firebird para las cosas que yo hago, me sobra, ¿por que se migra de una BD o otra?
Saludos.

[[Lepe]]

Empezado por Cañones

¿por que se migra de una BD o otra?
Saludos.

¿por qué cambiaste de pascal a Delphi?, pues por eso se cambia :P

jeje. O también porque te lo imponen (tu jefe)... eso ya fastidia más juas juas

Saludos

[TJose]

Ahora, Firebird para las cosas que yo hago, me sobra, ¿por que se migra de una BD o otra?
Saludos.

A mi también me sobra, pero respecto a la necesidad de migrar imagino que pueden haber muchos motivos. En el caso de Firebird estos motivos se reducen bastante ya que escala muy bien tanto hacia arriba (windows, freebsd, solaris, linux, os x, 32bits, 64bits, etc) como hacia abajo (embebido).

Cuento dos motivos de migración que se presentaron:

1) Desarrollé un sistema de liquidación de haberes (sueldos) con C++Builder y Firebird 1.5.x para un cliente, este ya tiene funcionando casi 4 años. Toda la logica está en la base. Se me dió la posibilidad de venderlo a otro cliente, y esto implica poner en marcha un servidor (FB), administrarlo (si bien no necesita casi nada de mantenimiento), etc. Ahora estoy pensando de hacer un enlatado y poder venderlo a otros clientes.
Una alternativa para no tener que instalar el servidor con cada venta podría haber sido usar la versión embebida, pero sólo corre en windows, y yo quiero que sea multiplataforma (voy a utilizar python con sqlite)

2) Tengo otra aplicación (también firebird y c++builder), a mi ex-jefe le interesó, pero quiere que corra contra SQL-Server.

Has visto, dos motivos de migración y ninguno técnico, más bien un aspecto comercial.

Saludos
TJose