Al hilo del hilo de "Programo bien?": Programación declarativa

09/02/2007 - 12:19 por Juan Diego Bueno | Informe spam
Hola gente:

A propósito de esas polémicas que surgen constantemente en este
grupo... y tratando de hacer las cosas como se plantean en muchos de
los posts, me encuentro ante una serie de dudas en la creación de una
tabla del proyecto en el que estoy. Me gustaría saber como puedo
resolver declarativamente esta situación ( y pido perdón de antemano
por no haberme documentado más, pero es que no se por donde empezar, y
solo necesito un punto de partida)

Se trata de crear una tabla que va a guardar las vacaciones del
personal. Muchas de las situaciones ya están declaradas en
constraints, como cuidar que los intervalos de fechas sean correctos,
y otras asignaciones a campos, pero hay dos situaciones que no se como
resolver declarativamente. Son las siguientes:

1. La tabla va a tener dos claves principales, el NIF de la persona, y
la fecha de inicio del periodo vacacional. También se guarda la fecha
fin. ¿Cómo puedo hacer que no haya incongruencia entre los diferentes
registros?. Es decir, para que un empleado al insertar un intervalo de
fechas, no se solape con otro ya existente en esa misma tabla

2. En otra tabla se almacenan el número de días de vacaciones a los
que tiene derecho el personal. Por lo tanto, necesito que la suma de
días solicitados en esta tabla, no superen los días que ese personal
tiene asignado.

Para ambas situaciones, evidentemente, puedo utilizar SPs y triggers,
los cuales son eminentemente procedimentales, pero dada la premisa que
se ha planteado de hacer declarativamente lo más posible... ¿cómo
puedo resolver estas dos situaciones de esa forma?

Gracias de antemano

Saludos

Preguntas similare

Leer las respuestas

#6 Susana
09/02/2007 - 17:00 | Informe spam
Supongo que querias hacerte el graciosillo.
Pero lo único que has hecho, es el ridículo.

Saludos carlitos.

"Carlos" escribió en el mensaje
news:
Mostrar la cita
#7 Juan Diego Bueno
09/02/2007 - 17:02 | Informe spam
Muchas gracias, Hernán, revisaré el documento que me has propuesto.

Bien, desde luego, no es la primera vez que me enfrento a un problema así,
pero no le he afrontado hasta ahora porque he dejado la responsabilidad de
la fiabilidad de los datos al grabador, y de hecho, así sigue siendo, pero
eso no quita para que alguna vez, como es el caso actual, busque y piense en
la forma de implementarlo. Y tienes razón... no he tocado aún el tema del
historial de fechas de contratación (que obviamente se guarda en la base de
datos) porque eso era para nota, pero esto me parecía un buen comienzo

Saludos

"Hernan" escribió en el mensaje
news:
Lo que quieres modelar es una tabla con la variable tiempo.
Tiene truco y mucho. Desgraciadamente, y a pesar de que
hace 20 años se conoce el problema, los proveedores de BD
han hecho casi nada.

Si es la primera vez que te enfrentas con un problema así, antes que
nada
te recomiendo que *NO* pienses que las columnas FECHA_INI y FECHA_FIN
(o como las hayas llamado) son como cualquier otra del modelo.

Busca en la web sobre "Temporal Databases" que se ha escrito mogollón
al respecto (*). No trates de reinventar la rueda porque te vas a
estrellar.

Lo verdaderamente divertido comienza cuando el resto de tus entidades
le
empiezan a crecer estas dos columnitas. Por ejemplo: que los
intervalos
de vacaciones estén dentro del intervalo de alta del empleado y así.

Je... En este caso, decidir si usas CHECK o triggers para manterner
la consistencia de los datos será el MENOR de tus problemas.

Saludos,
-H.

(*) Si estás usando un gestor de los "normalitos" te recomiendo:
http://www.cs.arizona.edu/people/rts/tdbbook.pdf


Mostrar la cita
Estoy utilizando la versión gratuita de SPAMfighter para usuarios privados.
Ha eliminado 5435 correos spam hasta la fecha.
Los abonados no tienen este mensaje en sus correos.
¡Pruebe SPAMfighter gratis ya!
#8 Alfredo Novoa
09/02/2007 - 18:16 | Informe spam
On Fri, 9 Feb 2007 16:55:16 +0100, "Juan Diego Bueno Prieto"
wrote:

Mostrar la cita
Entonces mal por SQL Server. A Oracle le pasa lo mismo.

Mostrar la cita
Vamos a ver. Utilizar cualquier función ya programada en una consulta
es declarativo (where, join, select, etc también son funciones).

Programar una función es procedimental.

En este caso nos están obligando a dar un paso que debería de ser
innecesario: crear la UDF. Si pudiesemos crear la restricción en un
solo paso pues mejor.

La solución de la UDF no es 100% declarativa, pero es lo más
declarativa posible con SQL Server.


Saludos
#9 Alfredo Novoa
09/02/2007 - 18:21 | Informe spam
On 9 Feb 2007 07:54:27 -0800, "Hernan" wrote:

Mostrar la cita
Yo recomiendo especialmente leer los trabajos de Nikos Lorentzos.


Saludos
Alfredo
#10 Carlos
09/02/2007 - 21:05 | Informe spam
Mostrar la cita
Y vos tambien, Susanita De Novoa...

X-DDDDDDDDDDDDDDD

"Susana" escribió en el mensaje
news:
Mostrar la cita
Ads by Google
Search Busqueda sugerida