>
>2. Also, another drawback, is scanning a stock transaction table containing
>numbers that mean nothing to me by sight. If, however, the table contains
>the stock code themselves, it saves me having to link to the stock table to
>see what it actually represents. Now that I'm using Firebird, though (along
>with IBExpert), this is actualy becoming less of problem, as it is just as
>easy to run a stored proc (with all the stock descriptions looked up), as it
>is to look at the data in the table directly.

No, sorry, I don't mean that the user should not have a stock code. An
example would be :

Table STOCK
(RECORDNO INTEGER NOT NULL,
STOCKCODE VARCHAR(64),
DESCRIPTION VARCHAR(64),
PRIMARY KEY (RECORDNO))

Which allows you the best of both worlds. The joins and foreign keys are
done (in this case) on the field RECORDNO - but the user sees and uses
STOCKCODE. Also makes it easier to scan through the table.

Regards

Tim


[Non-text portions of this message have been removed]