consulta sobre fecha

Aquí lo lógico sería partir la tabla verticalmente a nivel lógico, aunque
si quieres puedes seguir teniendo solo una a nivel físico.

Cómo sería eso ?

Hola Alfredo,

On 18 okt, 17:08, Alfredo Novoa wrote:

Hola Carlos,

El Sat, 18 Oct 2008 05:05:56 -0700 (PDT), Carlos M. Calvelo escribió:

> Los operadores que van con ese tipo (day, month, year, dateadd,
> datediff, <, =, >, etc) tendrán que tener en cuenta ese valor y
> todas las operaciones tendrán hacer algo sensato con él.

Las operaciones que incluyesen un '//' podrían provocar una excepción.
Excepto los operadores '=' y '<>', que esos si que deberían de funcionar
siempre para que un tipo sea un tipo de verdad.

Cierto. Con esta difinicion:
// = 1-1-2008 False
// <> 1-1-2008 True
// = // True
// <> // False

O sea, sin meterse a la lógica de tres valores como con los nulos.
Pero este ya no es el tipo Date, sino el tipo OptionalDate del que
hablas mas adelante.

Hacer un datediff de una fecha con un blanco no es muy diferente a hacer
una división por 0 en medio de una consulta.

A mi si me parece diferente. En concreto 0 es tan número como otro
cualquiera independientemente de la operanción división. En cambio
fecha_en_blanco no es una fecha.

Sería bastante lógico que la
consulta no devolviese ningún resultado. Otra opción es tener un valor
'Indefinido', pero es bastante más complicado.

El paralelo que tratas de hacer con 0 y con la división de números
no me parece del todo tan obvio, aunque yo también pensé en eso.
a/0 es indefinido porque no podemos encontrar un b tal que a = 0 x b,
o si a también es 0 cualquier b valdría.
El que es especial aquí no es el 0 sino la operación /.
Ni eso implica que indefinido sea un valor normal, sino una
excepción.

> Si de todo eso sacas algo consistente, compártelo con la comunidad,
> porque con los nulos no nos va muy bien y quizás tengamos que
> considerar 'el valor vacío'. Te harás famoso si lo consigues.

Pues tampoco me parece muy difícil, lo malo es que los tipos CLR parecen
bastante incómodos de usar.

Yo estoy pensando seriamente crear un tipo "OptionalDate" para mi "RDBMS
Middleware".

Qué sea o no difícil/posible hacer algo no es a lo que me refiero.
Me refiero a si tiene sentido y donde está la diferencia fundamental
entre 'tengo una fecha vacía' y 'no tengo fecha' (null)

Quizás tu middelware no conoze el concepto de null pero para ciertos
tipos necesitas un valor especial, sin tener que introducir ese
concepto para todos los tipos. Entonces tendrás un tipo Date y otro
OptionalDate, pero no solo uno. Quizás podría heredar Date de
OptionalDate. Y eso sería paralelo a tener un tipo Integer y otro
distinto OptionalInteger; este ultimo con un valor especial que no
es 0.

Saludos,
Carlos

Hola Pedro,

On 18 okt, 18:51, "Pedro" wrote:

> Aquí lo lógico sería partir la tabla verticalmente a nivel lógico, aunque
> si quieres puedes seguir teniendo solo una a nivel físico.

Cómo sería eso ?

Es la tercera opción que le doy yo a Luis en mi primer reacción
implementada de esta manera:
la tabla original no es accesible (nivel físico) y se definen dos
vistas sobre esa tabla que son las que representan la partición
vertical (nivel lógico).

Saludos,
Carlos

Me disculpan la ignorancia en ese tema pero es que no entiendo bien. En la
tercera opcion que dices hablas de normalizar la tabla y pensaba que
implicaba la partición física vertical.
Ademas me imagino que Luis se referiría a la tabla física, sino habría dicho
lo contrario.
Pero pregunto, cuando se habla de normalizar para dividir esa tabla en dos,
no estamos hablando, entre otras cosas, de obtener dos tablas (físicas) ?
Si la dejamos igual (una sola física) y hacemos dos vistas, estamos
normalizando realmente ?


"Carlos M. Calvelo" escribió en el mensaje
news:
Hola Pedro,

On 18 okt, 18:51, "Pedro" wrote:

> Aquí lo lógico sería partir la tabla verticalmente a nivel lógico,
> aunque
> si quieres puedes seguir teniendo solo una a nivel físico.

Cómo sería eso ?

Es la tercera opción que le doy yo a Luis en mi primer reacción
implementada de esta manera:
la tabla original no es accesible (nivel físico) y se definen dos
vistas sobre esa tabla que son las que representan la partición
vertical (nivel lógico).

Saludos,
Carlos

Hola Carlos,

El Sat, 18 Oct 2008 11:17:30 -0700 (PDT), Carlos M. Calvelo escribió:

Hacer un datediff de una fecha con un blanco no es muy diferente a hacer
una división por 0 en medio de una consulta.

A mi si me parece diferente. En concreto 0 es tan número como otro
cualquiera independientemente de la operanción división. En cambio
fecha_en_blanco no es una fecha.

Bueno, me refería a una vez incluida la fecha en blanco en un tipo como el
OptionalDate. Un 'blanco' sería tan fecha opcional como cualquier otra :-)

El paralelo que tratas de hacer con 0 y con la división de números
no me parece del todo tan obvio, aunque yo también pensé en eso.
a/0 es indefinido porque no podemos encontrar un b tal que a = 0 x b,
o si a también es 0 cualquier b valdría.

a/0 es indefinido por que el operador '/' no está definido cuando el
divisor es 0. Tu puedes definir operadores para los valores que te da la
gana.

El que es especial aquí no es el 0 sino la operación /.

Pues yo no le veo nada especial. Por ejemplo el operador raiz cuadrada que
devuelve números reales no está definido para numeros negativos, y entonces
ya serían infinitos valores 'especiales' :-)

Qué sea o no difícil/posible hacer algo no es a lo que me refiero.
Me refiero a si tiene sentido y donde está la diferencia fundamental
entre 'tengo una fecha vacía' y 'no tengo fecha' (null)

Pues en que con el nulo te sales de la lógica de predicados y con la fecha
vacía no.

Quizás tu middelware no conoze el concepto de null pero para ciertos
tipos necesitas un valor especial, sin tener que introducir ese
concepto para todos los tipos. Entonces tendrás un tipo Date y otro
OptionalDate, pero no solo uno. Quizás podría heredar Date de
OptionalDate. Y eso sería paralelo a tener un tipo Integer y otro
distinto OptionalInteger; este ultimo con un valor especial que no
es 0.

Pues de eso se trata, lo malo es que esos tipos son casi tan peligrosos
como los nulos, y yo no los usaría más que para la presentación.

Por ejemplo puedes tener tablas separadas como siempre y para presentar en
un grid haces una vista actualizable con un outer join rellenando los
huecos con el valor "en blanco" de ese tipo. Así puedes conseguir que si
intentas introducir una letra en una fecha opcional no te deje.

Así necesitas definir menos operadores y ya no habría excepciones. Por
ejemplo DateDiff, AddDays, Year, etc podrían no existir para las fechas
opcionales.

Tampoco se necesitaría usar herencia por que los tipos se podrían crear
fácilmente por composición.


Saludos
Alfredo