|Subject||RE: [firebird-support] PK database design was RE: SP hanging|
>No, sorry, I don't mean that the user should not have a stock code. An
>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.
example would be :
(RECORDNO INTEGER NOT NULL,
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.
[Non-text portions of this message have been removed]