consulta sobre fecha

El Sat, 18 Oct 2008 12:51:16 -0400, Pedro escribió:

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 ?

Creas dos vistas actualizables, una para cada tipo de factura, que tiren de
la misma tabla, y no les das permiso a los usuarios para ver la tabla. Así
los usuarios nunca podrán ver los nulos y no se necesita hacer ningún join.



Saludos

Hola Pedro,

El Sat, 18 Oct 2008 15:10:22 -0400, Pedro escribió:

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.

La normalización es un concepto lógico y por lo tanto no tendría por que
implicar cambios físicos.

En la práctica muchas veces si los implica por que la tecnología actual no
es como para tirar cohetes. Pero en este caso es bastante fácil evitar la
partición física como te explico en el otro mensaje.

Ademas me imagino que Luis se referiría a la tabla física, sino habría dicho
lo contrario.

Más bien habría que suponer lo contrario.

Si la dejamos igual (una sola física) y hacemos dos vistas, estamos
normalizando realmente ?

Por supuesto que si, siempre que le ocultemos la tabla a los usuarios.


Saludos
Alfredo

Hola Pedro,

On 18 okt, 21:10, "Pedro" wrote:

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.

Esquema lógico: conjunto de tablas que expone la estructura
de los datos al mundo exterior. Tablas pueden ser tablas base
o vistas (tablas derivadas, virtuales).

Esquema físico: conjunto de 'archivos' en los que se guardan los
datos. Fíjate que digo 'archivos' en vez de tablas aunque puede
haber una correspondencia directa.

Normalizar, que es de lo que hablamos en este caso cuando hablamos
de partición vertical, es un concepto a nivel lógico.

Ademas me imagino que Luis se referiría a la tabla física, sino habría dicho
lo contrario.

La tabla original antes de la partición vertical es una tabla a
nivel lógico. Si esa tabla base la substituimos por otras dos tablas
base, el mapeo de nivel lógico a físico es de uno a uno.

Esa partición también la podemos hacer con vistas sobre la tabla
original. Entonces las dos tablas a nivel lógico son las vistas
y la tabla original pasa a formar parte del nivel físico. El mapeo
de nivel lógico a nivel físico es de dos a uno. Dos tablas (vistas)
a nivel lógico son representadas a nivel físico en el mismo
'archivo', la tabla base original.

Para los dos casos el esquema a nivel lógico es el mismo, dos tablas.

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) ?

No. A nivel lógico teníamos una tabla y ahora dos.
Eso, independientemente de si tenemos dos tablas base o dos tablas
derivadas (vistas).
Además normalización es un concepto a nivel lógico.

Si la dejamos igual (una sola física) y hacemos dos vistas, estamos
normalizando realmente ?

Si. A nivel lógico el resultado es el mismo: dos tablas.

No sé si me he explidado bien. Te aconsejo el libro de
C. Date (An Introduction to Database Systems).

Saludos,
Carlos

No sé si me he explidado bien.

Mas o menos pero para resumir: en ese caso del que hablamos el campo
FechaVencimiento seguirá de todos modos existiendo en la tabla de la que
habló Luis ? O sea que el "nivel físico" sigue tal cual él lo planteó?

Oye gracias por la explicacion.

Hola Alfredo,

On 18 okt, 22:18, Alfredo Novoa wrote:

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.

Bueno, yo digo por qué no esta definido y tu me dices que no está
definido. :-)

Y claro que puedo definir lo que me dé la gana pero tendrá que
tener algún sentido y seguro que no será sin consecuencias.

> 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' :-)

Pero yo decía que 0 no es especial sino la operación /. Pero bueno,
lo dije pensando solo en +,-,x que no tienen ese probema con el 0, ni
con cualquier otro número y claro que se pueden encontrar mas casos
así.

> 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.

No.. ya! Pero eso tiene consecuencias para las operaciones.

Podemos considerar que:

- null=null es True, null<>null es False, otro_valor = null es false,
etc
- y ademas que null es implícitamente un valor para todos los tipos

y ya todos los tipos son opcionales.

No creo que eso vaya a solucionar satisfactoriamente el problema
de la falta de información. Mas bien conduciría a que se normalize
mucho menos que ahora.
Para satisfacer a Luis ese null no será null sino '' o // :-)

> 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.

Me gustaría quedarme con esto que sigue ...

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.

... porque es donde está explicado de otra forma una de las
soluciones que se le dieron a Luis, pero sin crear nuevos tipos
sino convirtiendo nulos y fechas a varchar en vistas. Evidentemente
esas vistas tienen que ser actualizables para hacer la conversión
inversa.

Saludos,
Carlos