String lengths in the SQL backend

[Graham Leggett]

Derek Atkins wrote:

> Uhh, yeah.  Sorry.  Totally unreasonable.
> 
> The "code" in question is a user-input field.  Historically accountants
> used codes instead of names to keep track of accounts.  So GnuCash provides
> a place for you to enter in an Account Code.  But it's a string, not a number.
> Granted, most users probably do only use numbers, but there is no
> requirement that it be a number.

It is for this exact reason that in standard database schema design, 
codes should not be used as keys.

The end user (or an administrator, or an auditor) should have the power 
to choose the code as they see fit and change the code if they see fit. 
If you have used the code as a key, changing that code becomes difficult 
from a sql perspective.

The XML file already uses a separation between codes and keys: the user 
might enter a code, but internally inside the XML file GUIDs are used as 
keys. Because of this, the code can be changed easily and safely, and 
the end user doesn't have to know or care what a GUID is or even that a 
GUID exists.

It is perfectly reasonable (and recommended) for the primary key to be 
something private to the application (an integer, a GUID, whatever), and 
the code to be just-another-field in the table.

Regards,
Graham
--
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3287 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.gnucash.org/pipermail/gnucash-user/attachments/20081113/1d756396/attachment.bin