Kbase P24250: What is the ratio between a table size as it appears in dbanalys and the size of its .d once it' dum
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
10/16/2008 |
|
Status: Unverified
GOAL:
What is the ratio between a table size as it appears in dbanalys and the size of its .d once it' dumped
GOAL:
What is the ratio between a table size as it appears in dbanalys and the size of its ASCII dump
FIX:
The ASCII dump of a table (stored in a file with extension .d) will be larger because the amount of bytes taken when data is in ASCII format is larger than when it's stored into the database. But then, the exact ratio between dbanalys and the .d is really data- and schema-dependent.
For example, the integer value 125 is stored as 2 bytes in the database, but it dumps to 4 bytes ('1', '2', '5' plus the delimiter from the next field, usually the space character).
Dates are even larger, when dumped: they usually take 3 bytes in the db, but when exported they will be in any form from M/D/YY (e.g. 1/1/97, the shortest) to MM/DD/YYYY (e.g. 12/12/2004, the longest), that is: from 6 to 10 bytes, plus 1 more byte for the delimiter.
The only type of data that stays more or less the same is strings: they take (length + 1) bytes when stored in the database, and take (length + 3) bytes in the ASCII dump; the overhead is for the 2 double-quotes, plus the delimiter from the next field.
This shows that the ratio is data and data-type dependent, therefore it cannot be predicted in advance in a simple and straightforward fashion.
It has to be said, however, that for large tables this ratio will usually remain constant over time; so, if the table was dumped at one point in time and the ratio was calculated, there is a good possibility that this ratio is roughly the same to this day.