String lengths in the SQL backend

[Geert Janssens]

I agree that this would be the best course of action.

Use a separate key for the codes. Internally, link the tables using the keys, 
and only where user interaction is expected, present the code.

My 2c.

Geert

On Thursday 13 November 2008, Graham Leggett wrote:
> 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
> --