On Thu, 2006-12-07 at 00:00 +0100, Karel Zak wrote: > On Wed, Dec 06, 2006 at 11:19:29AM -0800, Toshio Kuratomi wrote: > > On Wed, 2006-12-06 at 09:19 -0500, Elliot Lee wrote: > > > To balance fast indexing/comparison, small storage space, and room > > > for expansion, it's often easier to use INTEGER for these type of > > > columns, and then assign meaning to those values elsewhere (either > > > through a separate table that translates values to strings, or by > > > #define-like constants in the source code). > > > > > I think we'll do this with INTEGER and a separate table because Jeffrey > > Ollie's proposal to allow translations to the status codes makes sense. > > It depends on number of status codes. You can use 1 or 2 chars as a > primary key for status table (instead integers). It's better for > humans, because simple selects (without join to status table) are > still readable. Somewhat. We have 15 status codes right now. Even with three letter abbreviations, you have to have a pretty good idea what the possible statuses are in order to make use of it in "raw" form. Here are a few of the problems: + 7 of the statuses begin with "a" + Many of our statuses are two words + We have status's like "Under Review" and "Awaiting Review" which prevents simplifying to a mnemonic for the most significant word. Not sure that it's worthwhile to try to make these status codes directly human readable or not. -Toshio
Attachment:
signature.asc
Description: This is a digitally signed message part
