>>Anyone who cares about storage bloating wouldn't even use DBF. DBF is one of most storage wasting structures (not as worse as XML but tons of unused space).
>
>Over the years, I've come to conclusion that a well designed dbf would zip 90%. With binary fields (integers, datetimes, currency) somewhat less.
>
>But I've seen badly designed tables which would zip 99%. Why? Zip algorithm thrives on repetition. Anything that's repeated, like a bunch of spaces in blank fields, will zip incredibly well. Any repeated strings, as in non-normalized tables, likewise. This guy had a dbf imitate an excel sheet - the users would sit in a simple browse and scroll endlessly left and right to put their numbers (daily deliveries of bread and stuff to about 30 shops, 3 or 4 times a day - so about 20*4 columns (item, shift) over 30 rows (shops), starting with a copy of yesterday's delivery. I got to do that from scratch when he ate all the space on disk.
>
>The morale of my story is that it doesn't matter how wasteful the format, bad design can make it far worse :).

Dragan,
You are right of course:) Mine was a ironical reply to whom that cares the "wasted" space using GUID vs integer:) GUID is not wasting a bit but using that space to the last byte - just in favor of preventing conversions at runtime:)

BTW my 36 suggestion was solely based on experience. Logically (and physically) the 16 bytes format would do, but conversions needed at runtime, reading from/to backends like SQL server would need further code (is that bloat in code).

And finally for a purist who wants integers as keys a "GUID" might exist (there is collision chance of less than 5 per 100000 as I have seen):

Declare Integer UuidCreate In 'RPCRT4.dll' String @pguid
Declare Integer StringFromGUID2 In 'Ole32.dll' ;
	string rguid, String @lpsz, Integer cchMax

CREATE CURSOR myIntGuids (guid i)
LOCAL lnId
FOR ix=1 TO 100000
	lnId = val(sys(2007,guid(),1,1))
	DO WHILE m.lnId > 0x7FFFFFFF
		lnId = val(sys(2007,guid(),1,1))
	enddo
	INSERT into myIntGuids values(m.lnID)
endfor
SELECT guid FROM myIntGuids HAVING COUNT(*) > 1 group BY 1

PROCEDURE guid
	Local pguid,rguid
	pguid=Replicate(Chr(0),16)
	rguid=Replicate(Chr(0),80)

	UuidCreate(@pguid)
	StringFromGUID2(pguid,@rguid,40)
	RETURN Strconv(Left(rguid,76),6)
ENDPROC

Integer fields cannot store integer values is another problem but majority seems to be unaware of it:)

Cetin