yuva2achieve / solidbase

Automatically exported from code.google.com/p/solidbase
Apache License 2.0
0 stars 0 forks source link

Import from INSERTs #109

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
Thousands of INSERT statements is like 40 times slower than import from CSV. 
Can we simulate an IMPORT?

Original issue reported on code.google.com by rene.de....@gmail.com on 20 Oct 2010 at 7:17

GoogleCodeExporter commented 9 years ago
Should the variable parts of the INSERT statements be detected automatically? 
Or should it be part of the IMPORT statement? It can only be detected when all 
insert statement are taken into account. There may be a lot of repeating 
values. So we need a mask:

--* BATCH MASK INSERT INTO ATABLE ( ACOL1, ACOL2, ACOL3 ) VALUES ( ?, TO_DATE( 
?, 'MM/DD/YYYY HH24:MI:SS' ), ? )
INSERT INTO ATABLE ( ACOL1, ACOL2, ACOL3 ) VALUES ( 16, TO_DATE( '10/23/2009 
11:13:36', 'MM/DD/YYYY HH24:MI:SS' ), 'N' );
INSERT INTO ATABLE ( ACOL1, ACOL2, ACOL3 ) VALUES ( 16, TO_DATE( '10/23/2009 
11:13:36', 'MM/DD/YYYY HH24:MI:SS' ), 'N' );
INSERT INTO ATABLE ( ACOL1, ACOL2, ACOL3 ) VALUES ( 16, NULL, 'N' );
--* /BATCH

As you see, TO_DATE and NULL is a problem for the mask. TO_DATE does accept 
NULLs, but is that true for all database vendors? And the insert statements are 
generated and will most probably no be written like TO_DATE( NULL, 'MM/DD/YYYY 
HH24:MI:SS' ).

Nulls may also be a problem for JDBC, sometimes you need the datatype to set a 
parameter to NULL. Maybe we can use the string datatype.

Maybe this just isn't worth the effort. Difficult to stay database vendor 
independent, especially with respect to inserting dates/times.

Original comment by rene.de....@gmail.com on 21 Oct 2010 at 8:52

GoogleCodeExporter commented 9 years ago

Original comment by rene.de....@gmail.com on 15 Mar 2011 at 8:35

GoogleCodeExporter commented 9 years ago

Original comment by rene.de....@gmail.com on 3 Dec 2011 at 1:14