Control secuencia de fechas

En el caso mio era digitar unas facturas manuales prenumeradas de talonarios
que se llevaban los vendedores los cuales luego de vender llegaban con las
facturas a la oficina sin un orden determinado y los digitadores debian
darles de alta en el sistema de ventas con la misma numeracion que ya tenian
en los talonarios. La regla era para evitar saltos en los numeros cuando
se hiciesen consultas por un rango de fechas si por error digitaban una
fecha incorrecta los digitadores.


"Maxi" wrote in message
news:

Hola, puede ser, lo q me gustaria saber atras de esa regla si es tan asi,

o

sea, el cliente pidio una ragla tan asi o el programador transformo un
pedido del cliente en un modelo y eso es lo que quiere llevar adelante? No
veo porque un usuario deba ingresar un valor y que ese sea (parece) el
numerador de un documento, es extraño!!


Maxi - Buenos Aires - Argentina
Desarrollador 3 Estrellas

Msn_messager:
mail: Maxi.da[arroba]gmail.com

"Alonso" escribió en el mensaje
news:
>> tipo de reglas asi puede hacer muy lento el sistema, no entiendo porque
>> buscas una regla asi?
>>
>
> Me imagino que porque se lo pidió el cliente :). No creo que un
> programador por propia iniciativa va a querer hacer algo tan

complicado.

>
> A mi casualmente me pidieron algo parecido y tuve tambien que meterlo en
> un
> trigger pues a fin de cuentas hacer una funcion es funcionalmente casi

lo

> mismo.
>
>

Aja, que interesante ;) pero peguntas al aire no?

Si un vendedor se lleva un talonario y luego al terminar el dia debe
ingresar en un sistema las facturas, ya tenemos un dato importante, podemos
tener una tabla donde definamos ese talonario y ya sabemos los numeros
validos para un vendedor con lo cual ya tenemos controlado el tema. Ademas
hay otro temita, es resonsabilidad de la base de datos tener esta logica? o
no seria mas adecuado ponerla en la capa correspondiente?
Esto lop digo porque quizas estamos cargando a un motor con cosas que este
no debe hacer no. Es para pensarlo un poquito


Maxi - Buenos Aires - Argentina
Desarrollador 3 Estrellas

Msn_messager:
mail: Maxi.da[arroba]gmail.com

"Alonso" escribió en el mensaje
news:

En el caso mio era digitar unas facturas manuales prenumeradas de
talonarios
que se llevaban los vendedores los cuales luego de vender llegaban con las
facturas a la oficina sin un orden determinado y los digitadores debian
darles de alta en el sistema de ventas con la misma numeracion que ya
tenian
en los talonarios. La regla era para evitar saltos en los numeros cuando
se hiciesen consultas por un rango de fechas si por error digitaban una
fecha incorrecta los digitadores.


"Maxi" wrote in message
news:

Hola, puede ser, lo q me gustaria saber atras de esa regla si es tan asi,

o

sea, el cliente pidio una ragla tan asi o el programador transformo un
pedido del cliente en un modelo y eso es lo que quiere llevar adelante?
No
veo porque un usuario deba ingresar un valor y que ese sea (parece) el
numerador de un documento, es extraño!!


Maxi - Buenos Aires - Argentina
Desarrollador 3 Estrellas

Msn_messager:
mail: Maxi.da[arroba]gmail.com

"Alonso" escribió en el mensaje
news:
>> tipo de reglas asi puede hacer muy lento el sistema, no entiendo
>> porque
>> buscas una regla asi?
>>
>
> Me imagino que porque se lo pidió el cliente :). No creo que un
> programador por propia iniciativa va a querer hacer algo tan

complicado.

>
> A mi casualmente me pidieron algo parecido y tuve tambien que meterlo
> en
> un
> trigger pues a fin de cuentas hacer una funcion es funcionalmente casi

lo

> mismo.
>
>

Lo que pasa es que los numeros no llegan necesariamente en orden. Las
razones .. mmm..Es una situacion particular y que no viene al caso para
explicarla en este foro. El hecho es que cuando vendimos la aplicacion, el
cliente nos lo exigió a pesar de argumentarle en contra.

Por otro lado, no es el hecho de que tenga que estar en la capa de datos. Me
imagino que cuando dice "otra capa" se refiere a la aplicación, porque para
los fines las reglas de negocios también se definen en la propia BD. Si
se pone en la capa de la de la aplicacion pienso que como quiera hay que
extraer informacion desde la capa de datos , de los documentos anterior y
siguiente, para implementar esta regla con lo cual se harian mas llamadas al
servidor que si se pusiera toda la logica en un solo store proc o un
trigger.

Agradezco su opinión pero no la comparto mucho.

Saludos


"Maxi" wrote in message
news:

Aja, que interesante ;) pero peguntas al aire no?

Si un vendedor se lleva un talonario y luego al terminar el dia debe
ingresar en un sistema las facturas, ya tenemos un dato importante,

podemos

tener una tabla donde definamos ese talonario y ya sabemos los numeros
validos para un vendedor con lo cual ya tenemos controlado el tema. Ademas
hay otro temita, es resonsabilidad de la base de datos tener esta logica?

o

no seria mas adecuado ponerla en la capa correspondiente?
Esto lop digo porque quizas estamos cargando a un motor con cosas que este
no debe hacer no. Es para pensarlo un poquito


Maxi - Buenos Aires - Argentina
Desarrollador 3 Estrellas

Msn_messager:
mail: Maxi.da[arroba]gmail.com

"Alonso" escribió en el mensaje
news:
> En el caso mio era digitar unas facturas manuales prenumeradas de
> talonarios
> que se llevaban los vendedores los cuales luego de vender llegaban con

las

> facturas a la oficina sin un orden determinado y los digitadores debian
> darles de alta en el sistema de ventas con la misma numeracion que ya
> tenian
> en los talonarios. La regla era para evitar saltos en los numeros

cuando

> se hiciesen consultas por un rango de fechas si por error digitaban una
> fecha incorrecta los digitadores.
>
>
> "Maxi" wrote in message
> news:
>> Hola, puede ser, lo q me gustaria saber atras de esa regla si es tan

asi,

> o
>> sea, el cliente pidio una ragla tan asi o el programador transformo un
>> pedido del cliente en un modelo y eso es lo que quiere llevar adelante?
>> No
>> veo porque un usuario deba ingresar un valor y que ese sea (parece) el
>> numerador de un documento, es extraño!!
>>
>>
>> Maxi - Buenos Aires - Argentina
>> Desarrollador 3 Estrellas
>>
>> Msn_messager:
>> mail: Maxi.da[arroba]gmail.com
>>
>> "Alonso" escribió en el mensaje
>> news:
>> >> tipo de reglas asi puede hacer muy lento el sistema, no entiendo
>> >> porque
>> >> buscas una regla asi?
>> >>
>> >
>> > Me imagino que porque se lo pidió el cliente :). No creo que un
>> > programador por propia iniciativa va a querer hacer algo tan
> complicado.
>> >
>> > A mi casualmente me pidieron algo parecido y tuve tambien que meterlo
>> > en
>> > un
>> > trigger pues a fin de cuentas hacer una funcion es funcionalmente

casi

> lo
>> > mismo.
>> >
>> >
>>
>>
>
>

Hola, sip, si lo pones en otra capa lo debes extraer, el tema es que te
evitas el trigger que a mi mucho no me gusta ;-)


Maxi - Buenos Aires - Argentina
Desarrollador 3 Estrellas

Msn_messager:
mail: Maxi.da[arroba]gmail.com

"Alonso" escribió en el mensaje
news:u$

Lo que pasa es que los numeros no llegan necesariamente en orden. Las
razones .. mmm..Es una situacion particular y que no viene al caso para
explicarla en este foro. El hecho es que cuando vendimos la aplicacion,
el
cliente nos lo exigió a pesar de argumentarle en contra.

Por otro lado, no es el hecho de que tenga que estar en la capa de datos.
Me
imagino que cuando dice "otra capa" se refiere a la aplicación, porque
para
los fines las reglas de negocios también se definen en la propia BD. Si
se pone en la capa de la de la aplicacion pienso que como quiera hay que
extraer informacion desde la capa de datos , de los documentos anterior y
siguiente, para implementar esta regla con lo cual se harian mas llamadas
al
servidor que si se pusiera toda la logica en un solo store proc o un
trigger.

Agradezco su opinión pero no la comparto mucho.

Saludos


"Maxi" wrote in message
news:

Aja, que interesante ;) pero peguntas al aire no?

Si un vendedor se lleva un talonario y luego al terminar el dia debe
ingresar en un sistema las facturas, ya tenemos un dato importante,

podemos

tener una tabla donde definamos ese talonario y ya sabemos los numeros
validos para un vendedor con lo cual ya tenemos controlado el tema.
Ademas
hay otro temita, es resonsabilidad de la base de datos tener esta logica?

o

no seria mas adecuado ponerla en la capa correspondiente?
Esto lop digo porque quizas estamos cargando a un motor con cosas que
este
no debe hacer no. Es para pensarlo un poquito


Maxi - Buenos Aires - Argentina
Desarrollador 3 Estrellas

Msn_messager:
mail: Maxi.da[arroba]gmail.com

"Alonso" escribió en el mensaje
news:
> En el caso mio era digitar unas facturas manuales prenumeradas de
> talonarios
> que se llevaban los vendedores los cuales luego de vender llegaban con

las

> facturas a la oficina sin un orden determinado y los digitadores debian
> darles de alta en el sistema de ventas con la misma numeracion que ya
> tenian
> en los talonarios. La regla era para evitar saltos en los numeros

cuando

> se hiciesen consultas por un rango de fechas si por error digitaban una
> fecha incorrecta los digitadores.
>
>
> "Maxi" wrote in message
> news:
>> Hola, puede ser, lo q me gustaria saber atras de esa regla si es tan

asi,

> o
>> sea, el cliente pidio una ragla tan asi o el programador transformo un
>> pedido del cliente en un modelo y eso es lo que quiere llevar
>> adelante?
>> No
>> veo porque un usuario deba ingresar un valor y que ese sea (parece) el
>> numerador de un documento, es extraño!!
>>
>>
>> Maxi - Buenos Aires - Argentina
>> Desarrollador 3 Estrellas
>>
>> Msn_messager:
>> mail: Maxi.da[arroba]gmail.com
>>
>> "Alonso" escribió en el mensaje
>> news:
>> >> tipo de reglas asi puede hacer muy lento el sistema, no entiendo
>> >> porque
>> >> buscas una regla asi?
>> >>
>> >
>> > Me imagino que porque se lo pidió el cliente :). No creo que un
>> > programador por propia iniciativa va a querer hacer algo tan
> complicado.
>> >
>> > A mi casualmente me pidieron algo parecido y tuve tambien que
>> > meterlo
>> > en
>> > un
>> > trigger pues a fin de cuentas hacer una funcion es funcionalmente

casi

> lo
>> > mismo.
>> >
>> >
>>
>>
>
>

Una duda mas, en un ambiente de mucha digitacion concurrente no seria un
poco pesado ese control en un trigger ?

Claro que si, pero para estar seguro debes realizar pruebas antes de tomar
una decision. Otra alternativa seria poner la regla en una funcion de usuario
y usar esta funcion en una restricion CHECK en la definicion de la tabla. Con
esta ultima opcion corres el mismo riesgo que con la anterior y para ver cual
se adapta mejor debes, como dije antes, realizar pruebas de carga.


AMB

"Alfredo Crisostomo" wrote:

Muchas gracias Alejandro.

Una duda mas, en un ambiente de mucha digitacion concurrente no seria un
poco pesado ese control en un trigger ?

Gracias de nuevo


"Alejandro Mesa" escribió en el
mensaje news:
> Alfredo,
>
> Pudieras crear un trigger, por ejemplo para insert, que chequea la regla.
> Algo asi como.
>
> use northwind
> go
>
> create table t1 (
> c1 int not null unique,
> c2 datetime not null
> )
> go
>
> create trigger tr_t1_ins on t1
> for insert
> as
> set nocount on
>
> if exists(
> select
> *
> from
> inserted as i
> where
> exists(
> select
> *
> from
> t1 as a
> where
> a.c1 = (select max(b.c1) from t1 as b where b.c1 < i.c1)
> and a.c2 > i.c2
> )
>
> or
>
> exists(
> select
> *
> from
> t1 as a
> where
> a.c1 = (select min(b.c1) from t1 as b where b.c1 > i.c1)
> and a.c2 < i.c2
> )
> )
> begin
> rollback transaction
> raiserror('Fecha incorrecta.', 16, 1)
> return
> end
> go
>
> insert into t1(c1, c2) values(1, '20050715')
> insert into t1(c1, c2) values(3, '20050716')
> insert into t1(c1, c2) values(5, '20050717')
> go
>
> insert into t1(c1, c2) values(2, '20050714')
> go
>
> insert into t1(c1, c2) values(4, '20050718')
> go
>
> select * from t1 order by 1
> go
>
> drop table t1
> go
>
>
> AMB
>
> "Alfredo Crisostomo" wrote:
>
> > Hola, necesito una idea para implementar lo siguiente.
> >
> > Tengo una tabla de documentos numerados con un campo clave ID y otro
campo
> > FECHA, entre otros.. Este campo es numerico pero no es secuencial pues
los
> > usuarios lo deben introducir. El problema es que el sistema debe
controlar
> > que las fechas digitadas esten ordenadas en el orden de la PK, es decir:
> >
> > ID fecha
> > 0001 02/07/2005
> > 0002 07/07/2005
> > 0004 10/07/2005
> >
> > que la fecha de un nuevo ID que se digite no sea mayor que la de su ID
> > siguiente (si lo hay) y no sea menor que la del ID anterior (si lo hay).
> > Nota. Los ID's se digitan en orden aleatorio.
> >
> >
> >
> >
> >
> >
> >