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 --
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel