Introduction to the use of time types in the training dry goods DM7 of Shanghai Tengke Education Dream Database

In the daily use of the database, whether it is recording the service start time or storing the order time in the front-end application, it is inseparable from the use of various date types. This article will introduce you to the difference and use of various time types in DM7 Precautions.

 

One. Introduction to time and date types in DM7

 

There are three commonly used time and date types in DM7: DATE, TIME, and TIMESTAMP.

 

The DATE type includes year, month, and day information, and defines any valid Gregorian date between'-4712-01-01' and '9999-12-31'.

 

The TIME type includes hour, minute, and second information, and defines a valid time between '00:00:00.000000' and '23:59:59.999999'. The decimal second precision of the TIME type specifies the number of digits after the decimal point in the seconds field, and the value range is 0~6. If not defined, the default precision is 0.

 

The TIMESTAMP type includes year, month, day, hour, minute, and second information.

A valid Gregorian date and time between 00:00:00.000000' and '9999-12-3123:59:59.999999'.

 

The decimal seconds precision of the TIMESTAMP type specifies the number of digits after the decimal point in the seconds field, and the value range is 0~6. If not defined, the default precision is 6.

 

two. The difference between DATE and TIMESTAMP

 

According to the above definition, we know that the DATE type can only store the year, month, and day. What will happen when we try to store a complete time in the DATE? We can do the following tests:

 

DECLARE

       TEST1 DATE;

       TEST2 DATE;

BEGIN

       SET TEST1=to_date('2018-11-0115:20:10','YYYY-MM-DDHH24:MI:SS'); --Deposit time 1

       SET TEST2=to_date('2018-11-0117:20:10','YYYY-MM-DDHH24:MI:SS'); --Deposit time 2

 

       IF TEST1=TEST2 THEN 

       PRINT'TEST1=TEST2'; --If the two values ​​are the same, it will display TEST1=TEST2

       PRINT  TEST1;

       ELSEIF TEST1>TEST2 THEN

       PRINT'TEST1>TEST2';

       PRINT TEST1;

      ENDIF;

END;

 

The results are as follows:

 

[Dry goods sharing] Introduction to the use of time types in DM7

 

 

It can be seen that when we try to store a complete time including year, month, day, hour, minute, second and millisecond into the date type, the values ​​other than year, month, and day will be cut off. Therefore, when comparing two values, the result is an equal sign. In this case, to avoid data loss, we need TIMESTAMP to store complete date and time information.

 

3. Migration from ORACLE to DM

 

Readers who are familiar with ORACLE should understand that the DATE type of ORACLE includes year, month, day, hour, minute, and second information. Therefore, during the data migration from ORACLE to DM, if the DATE type is not converted, the hour, minute, and second data may be lost. At this time, we should convert the DATE type to TIMESTAMP in DM, as shown below:

 

Create instance tables in ORACLE and enter time data

 

CREATE TABLE T1 (AAA DATE);

INSERT INTO T1VALUES(to_date('2018-11-01 15:20:10','YYYY-MM-DD HH24:MI:SS'));

COMMIT;

 

Here we use the DTS tool to perform the migration. Due to space limitations, the process will not be demonstrated here. After the migration is completed, the corresponding T1 table and data can be found in the DM.

 

[Dry goods sharing] Introduction to the use of time types in DM7

 

The tables and data have been migrated, and the type has been converted to TIMESTAMP. The hour, minute, and second data are not lost. Here, some readers may ask, why did the DATE type itself become TIMESTAMP? Did we do anything during the migration process?

 

In fact, I did not manually specify the data type mapping during the migration process. However, when we use DTS to migrate from ORACLE to DM, the DTS tool will convert some types by itself.

 

[Dry goods sharing] Introduction to the use of time types in DM7

 

As shown in the figure, the tool has automatically converted the DATE type to the TIMESTAMP type. Of course, the type conversion during migration is more than that in the figure. Interested readers can refer to the chapter on default data type mapping in the DTS help document.

 

Guess you like

Origin blog.csdn.net/qq_42726883/article/details/108577683