consulta sobre fecha

Hola Pedro,

On 18 okt, 23:02, "Pedro" wrote:

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

Si, pero a nivel lógico solo existirá en la tabla (vista)
VENTAS_CREDITO y no en la tabla VENTAS (digamos que así
se llaman las tablas después de la partición)

Pero eso es irrelevante a nivel lógico. Las dos vistas se podrán
convertir en tablas base, la tabla original se borra y las
aplicaciones no se enteran. Ese proceso es reversible: se crean
otra vez las vistas y una tabla a nivel físico y las aplicaciones
seguiran sin enterarse.
Lo más importante es haber diseñado (y normalizado) bien desde el
principio.

Saludos,
Carlos

Ok.

Entendido y gracias de nuevo.


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

On 18 okt, 23:02, "Pedro" wrote:

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

Si, pero a nivel lógico solo existirá en la tabla (vista)
VENTAS_CREDITO y no en la tabla VENTAS (digamos que así
se llaman las tablas después de la partición)

Pero eso es irrelevante a nivel lógico. Las dos vistas se podrán
convertir en tablas base, la tabla original se borra y las
aplicaciones no se enteran. Ese proceso es reversible: se crean
otra vez las vistas y una tabla a nivel físico y las aplicaciones
seguiran sin enterarse.
Lo más importante es haber diseñado (y normalizado) bien desde el
principio.

Saludos,
Carlos

Carlos M. Calvelo wrote:

Hola Luis,

[SNIP]

Y porque no está la fecha de vencimiento en esa tabla?
Para pagos en efectivo esa fecha no es aplicable. Cuando
un dato no es aplicable (que no es lo mismo que 'desconocido')
entonces no hace falta esa columna. Como lo estoy entendiendo
yo, tienes un poblema de diseño, no de nulos o 'en blancos'.

Yo creo eso también. El principal indicador es que el OP quiere meter un
valor en una columna que no admite dicho valor.

Quizás estés confundiendo ventas con pagos.

Saludos,
Carlos

Saludos.

Juan Diego Bueno wrote:

Hola Luis:

"Luis Mata" escribió en el mensaje
de noticias:

Hno respeto tu opinion, pero mi problema no se radica en el diseño
sino en el diseño si bien FoxPro el fecha vacia lo representa con //,
no solo he tenido problemas en este proceso sino en otros.

Lo de que tu problema no radique en el diseño sino en el diseño, no lo
acabo de pillar

la pregunta en si es: sino quiero colocar una fecha especifica en un
campo sea cual fuera la razon ¿Que es lo que le pongo? muy aparte de
si esta o no esta diseñado bien, que no todos tenemos el mismo
criterio ni logica lo cual no significa que este mal.

Pues un NULL, que no es lo mismo que una cadena vacía o '' ya que
entonces no sería fecha (lo que te han dicho en anteriores posts). Si
cara a la presentación no te gusta que salga NULL, convierte la fecha a
cadena y ponla como cadena vacía cuando sea nula,

El OP inclusive podría hacer algo como:

select isnull(mi_campo_fecha, ''), ... from ... etc

y cuando tengas que
grabar ese dato, haces la conversión inversa y vuelves a ponerla como
fecha. Sql server creo que te puede hacer la conversión automática de
una cadena a fecha si está en el formato correcto, pero dudo que
convierta '' en NULL así que eso deberías hacerlo tú.

Un saludo

Saludos.

Hola Fernando,

On 19 okt, 18:55, "Fernando A. Gómez F."
wrote:

El OP inclusive podría hacer algo como:

select isnull(mi_campo_fecha, ''), ... from ... etc

Eso no funcionaría porque siendo la columna del tipo
datetime convertiría automáticamente el '' a la fecha
cero (19000101 00:00:00.000)

Prueba esto:

select
isnull(fecha,'') as fecha
from
( select getdate() as fecha
union
select null
) x

Saludos,
Carlos