"Downsizing" DataTypes.

  • Thread starter Thread starter Bob Barnes
  • Start date Start date
B

Bob Barnes

I have inherited a DB where, as an example, Long Integer
was assigned for "numbers" that would never exceed a value
of 100. I can change that DataType to Byte [Stores
numbers from 0 to 255 (no fractions)]. In theory. fingers
crossed, I would never lose any data. There are many joins
for the fields which would be "downsized" from Long to
Byte.

I have several issues where Double was assigned and it
should have been Single.

Changing the above should save storage space.

I will be sure to backup everything before trying this.

My question - Are there any "Traps" waiting for me when
I try this?

TIA - Bob
 
No...I'm just a "Less is More" Programmer.

It's true the hardware has made things run so much
faster than the days of the 386 & 486. But, I always
try to keep it lean & mean.

Bob
-----Original Message-----
Seems like a lot of effort for the sake of saving space...are you nearing
the maximum file size?

--
Kevin Hill
3NF Consulting
www.3nf-inc.com/NewsGroups.htm



Bob Barnes said:
I have inherited a DB where, as an example, Long Integer
was assigned for "numbers" that would never exceed a value
of 100. I can change that DataType to Byte [Stores
numbers from 0 to 255 (no fractions)]. In theory. fingers
crossed, I would never lose any data. There are many joins
for the fields which would be "downsized" from Long to
Byte.

I have several issues where Double was assigned and it
should have been Single.

Changing the above should save storage space.

I will be sure to backup everything before trying this.

My question - Are there any "Traps" waiting for me when
I try this?

TIA - Bob
Click to expand...


.
Click to expand...
 
It's true the hardware has made things run so much
faster than the days of the 386 & 486. But, I always
try to keep it lean & mean.
Click to expand...

Bear in mind that many OSs are optimised for 4- or 8-byte boundaries. I
haven't a clue whether Byte fields actually take less space than Longs (and
frankly, I don't really care either). The main reason for using a Byte
would be to prevent negative numbers when I am too lazy to set the
ValidationRule. And I always use Double floats because the rounding errors
with Singles are so gross that it's not even possible to do simple maths
with them.

B Wishes


Tim F
 
Tim - Interesting...

Remember in 1998 I was told about your "Double" info
below. Don't know if it's true now or not, but I've
heard "Single"s can be trusted??? You say no?

I don't know. The "Byte" is 1 Byte, a Long is "4 Bytes".
I have a lot of data, so if I can reduct it 5 Meg, I try.

Thank you, Bob
 
Remember in 1998 I was told about your "Double" info
below. Don't know if it's true now or not, but I've
heard "Single"s can be trusted??? You say no?
Click to expand...

It's not a question of trust: Singles do exactly what they say on the tin.
It is more a question of capabilities, and you have to appreciate that
there is a severe loss of precision. Whether that is important depends on
your application. And remember that you can get odd effects when coercing
Singles to Doubles.
I don't know. The "Byte" is 1 Byte, a Long is "4 Bytes".
I have a lot of data, so if I can reduct it 5 Meg, I try.
Click to expand...
My guess is that 2 to 4 bytes could be packed into one d-word, but a
solitary byte would almost certainly take up the same space. GOK what
happnes if it's indexed. I have no idea how to test it: there is so much
garbage and overhead in the average mdb file that the difference would by
pretty minimal at best.

B Wishes


Tim F
 
Tim - Thanks again.

I may revert to the "Doubles" standard, as Data Integrity
must be maintained.

Bob
 
Back
Top