String lengths in the SQL backend
plongstaff at rogers.com
Wed Nov 12 10:24:03 EST 2008
For those on the gnucash user list, a new SQL backend is in development. An
issue has arisen, and I need to get input from users, not just developers.
Rolf Leggewie has run into some problems with the SQL backend
(http://bugzilla.gnome.org/show_bug.cgi?id=560165) - he wants to add another
SQL table to key off the account 'code' field. However, the 'code' field is
varchar(2048) which is too big to be a primary key in mysql. I responded that
earlier discussion on this mailing list (mainly/only by Derek) had been that
strings should be unlimited, and since SQL requires *some* limit, I chose
For those who don't know SQL, for a variable length string (varchar), the
database engine will only allocate enough space to hold the value, so allowing
2048 and storing only 10 chars uses about the same disk space as allowing 128
and storing the same 10. The problem in this case is that one user wants to
be able to index some more information by the account code, but the fields used
as the index is too large.
I'd have to look back, but I think Derek's reply was the only one. I'd like
to open the topic again, because of Rolf's problem. Can anyone think of a
reason that account code size limit cannot be reduced to a smaller value (e.g.
32)? Will anyone ever enter an account code longer than that?
More information about the gnucash-user