Subject | External Table Guidelines |
---|---|
Author | Hardy Sherwood |
Post date | 2007-10-17T17:22:03Z |
I'd appreciate some advise and guidelines on the use of external tables to
load data into internal tables.
1. I understand that external tables is the best way of loading large
quantities of data into internal tables. Is this correct? If not, what is
a better method?
2. It seems that most experienced Firebird users recommend that only
CHAR columns are defined in external tables. I'd like to use other types to
reduce run time. The process of creating external files consisting only of
character data is CPU intensive. The process of inserting external tables
that only consist of CHAR columns into internal tables that consist of
columns of various types is also CPU intensive. What's the problem with
using other types of columns?
3. I've attempted to use external tables that contain binary data. I
ran into problems because the slack bytes Firebird introduced to align 2
byte, 4 byte and 8 byte binary values to "appropriate" boundaries did not
always seem to conform to "published" rules. Has anyone else observed this
inconsistency? Is there anyway to suppress the generation of slack bytes
for alignment of binary data to appropriate boundaries?
4. Helen Borrie suggested that as a starting guideline to insert about
8,000 rows at a time when inserting data from an external to an internal
table. She also suggested that there are other factors. I assume that
these other factors concern the number of columns and maybe the number of
bytes of data per row. I'd appreciate any additional guidelines on how much
data should be inserted at one time from an external to an internal table?
Thanks,
Hardy
-----------------------------------------------------------------------------------
This message and contents are confidential and intended solely for
the use of the individual or entity to whom they are addressed. If you
have received this email in error please notify the system manager.
The original email message has been scanned for computer viruses.
-----------------------------------------------------------------------------------
[Non-text portions of this message have been removed]
load data into internal tables.
1. I understand that external tables is the best way of loading large
quantities of data into internal tables. Is this correct? If not, what is
a better method?
2. It seems that most experienced Firebird users recommend that only
CHAR columns are defined in external tables. I'd like to use other types to
reduce run time. The process of creating external files consisting only of
character data is CPU intensive. The process of inserting external tables
that only consist of CHAR columns into internal tables that consist of
columns of various types is also CPU intensive. What's the problem with
using other types of columns?
3. I've attempted to use external tables that contain binary data. I
ran into problems because the slack bytes Firebird introduced to align 2
byte, 4 byte and 8 byte binary values to "appropriate" boundaries did not
always seem to conform to "published" rules. Has anyone else observed this
inconsistency? Is there anyway to suppress the generation of slack bytes
for alignment of binary data to appropriate boundaries?
4. Helen Borrie suggested that as a starting guideline to insert about
8,000 rows at a time when inserting data from an external to an internal
table. She also suggested that there are other factors. I assume that
these other factors concern the number of columns and maybe the number of
bytes of data per row. I'd appreciate any additional guidelines on how much
data should be inserted at one time from an external to an internal table?
Thanks,
Hardy
-----------------------------------------------------------------------------------
This message and contents are confidential and intended solely for
the use of the individual or entity to whom they are addressed. If you
have received this email in error please notify the system manager.
The original email message has been scanned for computer viruses.
-----------------------------------------------------------------------------------
[Non-text portions of this message have been removed]