Donde poner el cdigo?

[jose.luis]

Hola,
Esta mañana mientras me divertía diseñando una base de datos para una
aplicación de gestión comercial me paré a pensar en procesos que ocurren
cuando, por ejemplo, añadimos una linea a un albarán de venta.
Simplificando, esos procesos son:
a. Actualizar movimiento de almacén en tabla mov_artirculos
b. Actualizar stocks por almacén en tabla stocks_almacen
c. Actualizar estadísticas de venta en tabla articulo
d. ...
Y me puse a valorar cual podría ser la mejor opción: sin incluirlos en la
base de datos o no. Para este tipo de operaciones (que son siempre las
mismas y no son sensibles a cambios)... ¿que opináis? ¿mejor en la base de
datos? ¿mejor por código de programa?
Saludos,
José Luis Capel

[Xevi]

José Luis,
Antes, con Clipper, siempre ponía las constantes que necesitaba utilizar en
mi aplicación en una DBF, pero desde que he aprendido a utilizar la clase
TIni, creo mi etiqueta [Xevi] y las entradas que total... me sirven para
agilizar mi aplicación...
ConfirmarBajas=S
PantallaBienvenida=N
....
y cargo estos valores en la clase TAppData con unos valores predeterminados
si no existen las entradas, para utilizarlos en toda mi aplicación.
Un Saludo,
Xevi.
"José Luis Capel - Aicom" <jose.luis@iaicom.com> escribió en el mensaje
news:45e7efb0$[email=1@news.xailer.com...]1@news.xailer.com...[/email]
> Hola,
>
> Esta mañana mientras me divertía diseñando una base de datos para una
> aplicación de gestión comercial me paré a pensar en procesos que ocurren
> cuando, por ejemplo, añadimos una linea a un albarán de venta.
> Simplificando, esos procesos son:
>
> a. Actualizar movimiento de almacén en tabla mov_artirculos
> b. Actualizar stocks por almacén en tabla stocks_almacen
> c. Actualizar estadísticas de venta en tabla articulo
> d. ...
>
> Y me puse a valorar cual podría ser la mejor opción: sin incluirlos en la
> base de datos o no. Para este tipo de operaciones (que son siempre las
> mismas y no son sensibles a cambios)... ¿que opináis? ¿mejor en la base de
> datos? ¿mejor por código de programa?
>
> Saludos,
> José Luis Capel
>
>

[jose.luis]

Xevi,
>
> Antes, con Clipper, siempre ponía las constantes que necesitaba utilizar
> en mi aplicación en una DBF, pero desde que he aprendido a utilizar la
> clase TIni, creo mi etiqueta [Xevi] y las entradas que total... me sirven
> para agilizar mi aplicación...
> ConfirmarBajas=S
> PantallaBienvenida=N
> ...
> y cargo estos valores en la clase TAppData con unos valores
> predeterminados si no existen las entradas, para utilizarlos en toda mi
> aplicación.
>
>
Me refiero a si usar los disparadores de Sql o poner el código en PRG.
Saludos,
José Luis Capel

[miguel]

Jose Luis, yo me inclino a usar los disparadores, de esta forma aseguras
la robustez en cuanto a que posteriormente puedas hacer algo sobre la
misma tabla ej. en php y no tengas en cuenta algún tema de actualización
que ahora tienes fresco en tu mente, por otra parte una vez hecho
simplificas mucho la labor de desarrollo. Yo siempre que puedo a si lo
hago a no ser que sea algo muy puntual.
Saludos. Miguel A. Torrellas
José Luis Capel - Aicom escribió:
> Xevi,
>
>> Antes, con Clipper, siempre poní­a las constantes que necesitaba utilizar
>> en mi aplicación en una DBF, pero desde que he aprendido a utilizar la
>> clase TIni, creo mi etiqueta [Xevi] y las entradas que total... me sirven
>> para agilizar mi aplicación...
>> ConfirmarBajas=S
>> PantallaBienvenida=N
>> ...
>> y cargo estos valores en la clase TAppData con unos valores
>> predeterminados si no existen las entradas, para utilizarlos en toda mi
>> aplicación.
>>
>>
>
> Me refiero a si usar los disparadores de Sql o poner el código en PRG.
>
> Saludos,
> José Luis Capel
>
>

[jasm]

Disparadores sin lugar a dudas. A no ser que existan cosas puntuales.

[antonio.ortega]

En el Sistema informático de E-Bay por ejm. se descarto la posibilidad de
usar este tipo de herramienta porque tenian la prevision de que podrían
tener que llegar a cambiar de Motor de Base de Datos, y con esto te quedas
muy comprometido con un fabricante, prefierieron ponerlo en sus "prg's".
Claro está que como todo, depende de las características del desarrollo.
Antonio F. Ortega

[jasm]

Antonio,
Si empezamos con las dudas de si vamos a cambiar de motor de bases de
datos con un proyecto en producción mal vamos. De todas formas, se haga
como se haga, si se hace un cambio de motor de datos de un proyecto en
producción, habrá que retocar código de la base de datos y código del
programa (y si alguien dice lo contrario no sabe de lo que habla ).
Saludos
Jose A. Suarez

[miguel]

Antonio,
En caso de cambiar de motor, yo pienso que siempre será mejor volver a
reprogramar la BD que todos los programas que manejen la misma, de una
atacada tienes toda la operativa de nuevo en marcha, es mi opinión
particular, por que como dice Jose Alfonso de tocar el código no te
salva nadie y siempre será mejor retocar una sola cosa que 163 posibles
programas que estén atacando a la misma Base de Datos.
Saludos. Miguel A. Torrellas
Antonio F. Ortega escribió:
> En el Sistema informático de E-Bay por ejm. se descarto la posibilidad de
> usar este tipo de herramienta porque tenian la prevision de que podrí­an
> tener que llegar a cambiar de Motor de Base de Datos, y con esto te quedas
> muy comprometido con un fabricante, prefierieron ponerlo en sus "prg's".
> Claro está que como todo, depende de las caracterí­sticas del desarrollo.
>
> Antonio F. Ortega
>
>
>
>
>

[antonio.ortega]

Solo comentaba el caso del e-bay, que imagino sabrán lo que hacen. , no
obstante supongo que lo de poner el código en la base de datos debe ser
conveniente, porque por algo lo habrán hecho, y respecto de modificar muchos
programas no lo tengo muy claro, porque supongo que se puede estructurar un
programa de manera que sea una sola función la que haga determindado
"trabajo", por lo que si decido cambiar algo, solo deberé tocar esa única
función, que sería lo mismo que tocar la función almacenada en la base de
datos.
Antonio F. Ortega

[Rolando]

Hola:
Para mi sin ninguna duda hay que utilizar tanto los disparadores
como los procedimientos almacenados, en cualquier sistema cliente-servidor
indudablemente la parte mas débil es la conexión, cuanto menos la utilicemos
mejor va a funcionar todo el sistema, esa es mi opinión.
Saludos.
"José Luis Capel - Aicom" <jose.luis@iaicom.com> escribió en el mensaje
news:45e7efb0$[email=1@news.xailer.com...]1@news.xailer.com...[/email]
> Hola,
>
> Esta mañana mientras me divertía diseñando una base de datos para una
> aplicación de gestión comercial me paré a pensar en procesos que ocurren
> cuando, por ejemplo, añadimos una linea a un albarán de venta.
> Simplificando, esos procesos son:
>
> a. Actualizar movimiento de almacén en tabla mov_artirculos
> b. Actualizar stocks por almacén en tabla stocks_almacen
> c. Actualizar estadísticas de venta en tabla articulo
> d. ...
>
> Y me puse a valorar cual podría ser la mejor opción: sin incluirlos en la
> base de datos o no. Para este tipo de operaciones (que son siempre las
> mismas y no son sensibles a cambios)... ¿que opináis? ¿mejor en la base de
> datos? ¿mejor por código de programa?
>
> Saludos,
> José Luis Capel
>
>

[miguel]

Rolando,
Totalmente de acuerdo, balancear los dos sistemas con un buen criterio
sin duda será la decisión mas acertada, pero en la medida que se pueda
cuantas mas cosas haga el servidor menos se utilizará la conexión, claro
está que también habrá que tener en cuenta no sobrecargarlo contemplando
siempre la cantidad de conexiones simultaneas tenga este.
Saludos. Miguel A. Torrellas
Rolando Sarrailh escribió:
> Hola:
> Para mi sin ninguna duda hay que utilizar tanto los disparadores
> como los procedimientos almacenados, en cualquier sistema cliente-servidor
> indudablemente la parte mas débil es la conexión, cuanto menos la utilicemos
> mejor va a funcionar todo el sistema, esa es mi opinión.
> Saludos.
>
> "José Luis Capel - Aicom" <jose.luis@iaicom.com> escribió en el mensaje
> news:45e7efb0$[email=1@news.xailer.com...]1@news.xailer.com...[/email]
>> Hola,
>>
>> Esta mañana mientras me divertí­a diseñando una base de datos para una
>> aplicación de gestión comercial me paré a pensar en procesos que ocurren
>> cuando, por ejemplo, añadimos una linea a un albarán de venta.
>> Simplificando, esos procesos son:
>>
>> a. Actualizar movimiento de almacén en tabla mov_artirculos
>> b. Actualizar stocks por almacén en tabla stocks_almacen
>> c. Actualizar estadí­sticas de venta en tabla articulo
>> d. ...
>>
>> Y me puse a valorar cual podrí­a ser la mejor opción: sin incluirlos en la
>> base de datos o no. Para este tipo de operaciones (que son siempre las
>> mismas y no son sensibles a cambios)... ¿que opináis? ¿mejor en la base de
>> datos? ¿mejor por código de programa?
>>
>> Saludos,
>> José Luis Capel
>>
>>
>
>

[jasm]

Antonio,
> Solo comentaba el caso del e-bay, que imagino sabrán lo que hacen. ...
Me permito recordarte que nadie es infalible y los de e-bay no son la
excepción
Saludos
Jose A. Suarez