2009-11-03 19 views
10

Bakground: Tengo una aplicación heredada en la que estoy trabajando que utiliza tipos de FECHA para la mayoría del tiempo de almacenamiento en la base de datos. Me gustaría probar actualizar algunas de estas tablas para que puedan utilizar zonas horarias, ya que esto está causando problemas con los usuarios en diferentes áreas desde donde está el db (consulte A a continuación). Esto es para Oracle 10g.Migración de las columnas de Oracle DATE a TIMESTAMP con la zona horaria

quetions:

1) ¿Puedo migrar esta "en su lugar." Es decir, ¿puedo convertir como

DATE_COL = type:DATE => DATE_COL = type:TIMESTAMP 

... o tendré que usar un nombre de columna diferente?

Tenga en cuenta que los datos deben conservarse. Si esto se puede hacer de forma semi-fácil en un script de migración, funcionará para mis propósitos.

2) ¿Este tipo de conversión será compatible con versiones anteriores? Es probable que tengamos algunos scripts o informes que llegarán a esta mesa de los que quizás no sepamos. Probablemente podamos manejarlo, pero me gustaría saber a qué tipo de nido de avispas me estoy metiendo.

3) ¿Qué escollos debería estar buscando?

Gracias,

EDIT:
(en parte como respuesta a Gary)

estoy bien con un proceso de múltiples pasos.

1) mover datos a una columna de marca de hora nueva (TEMP caled) con algún tipo de conversión 2) colocar la columna de edad (lo llamaremos my_date) 3) crear nueva columna de marca de tiempo con el nombre de columna de fecha antigua (my_date) datos 4) se mueven a la columna de la my_date 5) gota columna TEMP

a Gary también quería aclaraciones sobre la cuestión específica zona horaria. Copié mi respuesta de abajo para mantenerla más legible.

Básicamente se accederá a los datos desde diferentes áreas. Necesitamos poder convertir a/de la zona horaria local según sea necesario. También tenemos desencadenantes que usan sysdate complicando aún más las cosas. la marca de tiempo con zona horaria alivia mucho este dolor.

Ah, y gracias por las respuestas hasta el momento.

Respuesta

14

Se podía correr:

ALTER TABLE your_table MODIFY your_date_column TIMESTAMP WITH TIME ZONE; 

, pero yo recomendaría la adición de una columna TIMESTAMP a la mesa, utilizando una instrucción UPDATE para poblar, y soltar la columna de la fecha original si así lo desea:

ALTER TABLE your_table ADD date_as_timestamp TIMESTAMP WITH TIME ZONE; 

UPDATE your_table 
    SET date_as_timestamp = CAST(date_column AS TIMESTAMP WITH TIME ZONE); 

La conversión es compatible con versiones anteriores: puede volver atrás & adelante como desee.

+0

Supongo que lo que me gustaría aclarar es si reemplazo la columna con una marca de tiempo (como describo en mi actualización), ¿los informes y las consultas que utilizan estos campos se ahogarán en una marca de tiempo? (esto será solo de lectura) ¿Podría considerar una marca de tiempo como una subclase de fecha o hay suficientes sutilezas de Oracle para hacer de eso una suposición muy mala? –

+0

'TIMESTAMP' es un tipo de datos diferente: los informes y las consultas deberán revisarse para determinar su impacto. No es que el DB se "estrangulará", pero es probable que las funciones/etc no sean flexibles en el tipo de datos, por lo que deberán actualizarse para adaptarse. –

+0

'TIMESTAMP' no registra la zona horaria que es lo que requiere la pregunta. Debería usar 'TIMESTAMP WITH TIME ZONE' o' TIMESTAMP WITH LOCAL TIME ZONE'. Ver http://download.oracle.com/docs/cd/B19306_01/server.102/b14225/ch4datetime.htm. El primero almacena la fecha y la zona horaria en la columna, mientras que la segunda almacena la fecha normalizada en la zona horaria de la base de datos, pero la traduce al tiempo de sesión del usuario cuando el usuario consulta la columna. –

6

lo suficientemente simple para demostrar

SQL> create table x (y date); 
Table created. 
SQL> insert into x select sysdate from dual; 
1 row created. 
SQL> commit; 
Commit complete. 
SQL> alter table x modify y timestamp; 
Table altered. 
SQL> select * from x; 

Y 
--------------------------------------------------------------------------- 
03/NOV/09 12:49:03.000000 PM 
SQL> alter table x modify y date; 
Table altered. 
SQL> select * from x; 
Y 
--------- 
03/NOV/09 
SQL> alter table x modify y timestamp with time zone; 
alter table x modify y timestamp with time zone 
ERROR at line 1: 
ORA-01439: column to be modified must be empty to change datatype 
SQL> alter table x modify y timestamp with local time zone; 
Table altered. 
SQL> alter table x modify y date; 
Table altered. 

para que pueda ir de fecha a fecha y hora (o marca de tiempo con la zona horaria local) y de vuelta otra vez, pero no para la marca de tiempo con la zona horaria (es decir, donde se conserva el offset). Debería agregar otra columna y copiar los datos existentes (con un valor predeterminado para la zona horaria correspondiente).

"causando problemas con los usuarios en diferentes áreas de donde está el db". Podría ayudar a ser un poco más específico. ¿Es suficiente convertir las fechas (o marcas de tiempo) de la zona horaria de la base de datos a la zona horaria del usuario cuando se insertan/cambian/consultan, o realmente necesita persistir el hecho de que el registro se creó a las 3:00 p.m. en una zona horaria específica.

+0

"causando problemas con los usuarios en diferentes áreas de donde está la base de datos" Básicamente se accederá a los datos desde varias áreas diferentes. Necesitamos poder convertir a/de la zona horaria local según sea necesario. También tenemos desencadenantes que usan sysdate complicando aún más las cosas. la marca de tiempo con zona horaria alivia mucho este dolor. –

+0

¿La marca de tiempo con zona horaria LOCAL resuelve el problema. Si es así, es la solución más fácil de implementar. –

+2

PD. Cuando resta una fecha de otra, obtiene una respuesta numérica en días. Con timestamps, obtendrías un tipo de datos INTERVAL. Esa es una trampa para buscar –

Cuestiones relacionadas