Una de desempeño Mejor aumentar campos? o hacer consultas mas complejas???

17/03/2005 - 20:51 por SergioT | Informe spam
Hola

Tengo una tabla que tiene ya como 20 campos por registro y aparentemente
necesito como 6 campos numeric(18,0) más
9 numeric(18,0)
8 smallint
1 tinyint
1 char(15)
1 datetime

Yo podira, en lugar de aumentar 6 campos mas een la tabla , hacer el calculo
de cada uno de estos 6 campos en las consultas que requiera, el calculo
implica la sentencia CASE anidada dentro de otra CASE por cada columna ,
ademas que cuando requiera sacar diferencias entre las columnas calculadas
la consulta se complica mucho mas.

La pregunta es:: Me recomiendan aumentar campos o pasarme el trabajo de
armar consultas mas complejas ? que creen que afecte mas a la velocidad de
respuesta???

GRacias por sus opiniones

Preguntas similare

Leer las respuestas

#6 Miguel Egea
18/03/2005 - 21:51 | Informe spam
Hola sergio, mi opinión es que guardes ambos o incluso el cambio, verás que
como el cambio varía es un lio ir a la tabla a encontrar el resultado en el
momento y te afectará en todos los listados
Además crear un campo money supondrán 2 MB de datos por año más, no parece
que sea demasiado (aunque creases índices por ese campo tampoco es un
disparate) y al final tienes el valor del cambio de la transacción en el
mismo registro no es ya que sea más sencillo es que me parece mejor solución
de negocio. Incluso algún campo más por si tienes gastos de change y esas
cosillas.

Saludos Cordiales
Miguel Egea


"SergioT" escribió en el mensaje
news:

La tabla crecerá un montón al rededor de 270 000 registros por año

Los campos calculados se usarán bastante, te explico el problema

Resulta que Es una aplicacion comercial bi-monetaria es decir que parte de
los items llevan sus costos en Dolares y otra parte en Moneda nacional, de
todas formas cuando se emite una factura o nota fiscal se la debe emitir
en Moneda nacional lo cual te implica conversiones de moneda, el tema es
que para los reportes de Costos y Ventas el usuario eligira la moneda en
la cual quiere ver el reporte por tanto hay conversiones, habran otros
casos en los que el usuario quiera ver en valores "historicos" es decir el
reflejo monetario del dia de la transaccion, por tanto se usara bastante
el tema este de las conversiones, Cuando se enganche con la contabilidad
( que tambien es bi monetaria) se necesita sacar diferencias de valores
por variacion cambiaria ( ajuste por inflacion )

Como puedes el tema se complica por que en mi pais usamos dolares hasta
para comprar cigarrillos o gasolina igual que usamos la moneda local
jejeje Ahora la mayoria de las empresas ven sus inventarios en dolares
pero nunca falta la necesidad de ver valores en moneda local ola
conversion de acuerdo a la necesidad

Esta es la idea, que te parece?

Salu2 y gracias por tu opinion
Sergio


"Maxi" wrote in message
news:OAjen%
Hola SegioT, deberiamos saber el tamaño de esta bdd, si me decis que es
pequeña entonces yo usaria campos si se justifica guardar el resultado
para algo, si no se necesita guardar el resultado entonces lo podrias
calcular muy bien en el SELECT


Salu2
Maxi


"SergioT" escribió en el mensaje
news:
Hola

Tengo una tabla que tiene ya como 20 campos por registro y aparentemente
necesito como 6 campos numeric(18,0) más
9 numeric(18,0)
8 smallint
1 tinyint
1 char(15)
1 datetime

Yo podira, en lugar de aumentar 6 campos mas een la tabla , hacer el
calculo de cada uno de estos 6 campos en las consultas que requiera, el
calculo implica la sentencia CASE anidada dentro de otra CASE por cada
columna , ademas que cuando requiera sacar diferencias entre las
columnas calculadas la consulta se complica mucho mas.

La pregunta es:: Me recomiendan aumentar campos o pasarme el trabajo de
armar consultas mas complejas ? que creen que afecte mas a la velocidad
de respuesta???

GRacias por sus opiniones












Respuesta Responder a este mensaje
#7 SergioT
21/03/2005 - 16:49 | Informe spam
Ok gracias por la opinion
al final de cuentas me he decidio por aumentar mas campos

gracias

"Miguel Egea" wrote in message
news:OBhd2w$
Hola sergio, mi opinión es que guardes ambos o incluso el cambio, verás
que como el cambio varía es un lio ir a la tabla a encontrar el resultado
en el momento y te afectará en todos los listados
Además crear un campo money supondrán 2 MB de datos por año más, no parece
que sea demasiado (aunque creases índices por ese campo tampoco es un
disparate) y al final tienes el valor del cambio de la transacción en el
mismo registro no es ya que sea más sencillo es que me parece mejor
solución de negocio. Incluso algún campo más por si tienes gastos de
change y esas cosillas.

Saludos Cordiales
Miguel Egea


"SergioT" escribió en el mensaje
news:

La tabla crecerá un montón al rededor de 270 000 registros por año

Los campos calculados se usarán bastante, te explico el problema

Resulta que Es una aplicacion comercial bi-monetaria es decir que parte
de los items llevan sus costos en Dolares y otra parte en Moneda
nacional, de todas formas cuando se emite una factura o nota fiscal se la
debe emitir en Moneda nacional lo cual te implica conversiones de moneda,
el tema es que para los reportes de Costos y Ventas el usuario eligira la
moneda en la cual quiere ver el reporte por tanto hay conversiones,
habran otros casos en los que el usuario quiera ver en valores
"historicos" es decir el reflejo monetario del dia de la transaccion, por
tanto se usara bastante el tema este de las conversiones, Cuando se
enganche con la contabilidad ( que tambien es bi monetaria) se necesita
sacar diferencias de valores por variacion cambiaria ( ajuste por
inflacion )

Como puedes el tema se complica por que en mi pais usamos dolares hasta
para comprar cigarrillos o gasolina igual que usamos la moneda local
jejeje Ahora la mayoria de las empresas ven sus inventarios en dolares
pero nunca falta la necesidad de ver valores en moneda local ola
conversion de acuerdo a la necesidad

Esta es la idea, que te parece?

Salu2 y gracias por tu opinion
Sergio


"Maxi" wrote in message
news:OAjen%
Hola SegioT, deberiamos saber el tamaño de esta bdd, si me decis que es
pequeña entonces yo usaria campos si se justifica guardar el resultado
para algo, si no se necesita guardar el resultado entonces lo podrias
calcular muy bien en el SELECT


Salu2
Maxi


"SergioT" escribió en el mensaje
news:
Hola

Tengo una tabla que tiene ya como 20 campos por registro y
aparentemente necesito como 6 campos numeric(18,0) más
9 numeric(18,0)
8 smallint
1 tinyint
1 char(15)
1 datetime

Yo podira, en lugar de aumentar 6 campos mas een la tabla , hacer el
calculo de cada uno de estos 6 campos en las consultas que requiera, el
calculo implica la sentencia CASE anidada dentro de otra CASE por
cada columna , ademas que cuando requiera sacar diferencias entre las
columnas calculadas la consulta se complica mucho mas.

La pregunta es:: Me recomiendan aumentar campos o pasarme el trabajo de
armar consultas mas complejas ? que creen que afecte mas a la velocidad
de respuesta???

GRacias por sus opiniones

















email Siga el debate Respuesta Responder a este mensaje
Ads by Google
Help Hacer una pregunta AnteriorRespuesta Tengo una respuesta
Search Busqueda sugerida