Phil Longstaff <[EMAIL PROTECTED]> writes:
>> I suppose we could use varchar; the guid has a fixed size so we know
>> exactly how much space it requires. It's just an MD5 hash, so it's
>> 128 bits, which is 16 bytes of binary or 32 bytes of Hexstring.
>
> I am looking at having an int as the primary key for references to a
> table. The GUID would be stored with the row as 4 ints (guid_1, guid_2,
> guid_3 and guid_4). If we need to search a lot by GUID, we could have
> an index which spans those 4 columns. I don't see there is a lot of
> need, though.
I still don't understand why you want to do this. What does it buy
us? It seems to add a LOT of complexity on the GnuCash side when
building up SQL queries. Instead of just being able to print out
"$table.${object}_id='$guid'" we'd need a much more complicated SQL
generator routine.
-derek
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
[EMAIL PROTECTED] PGP key available
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
