On Feb 15, 2008, at 1:43 PM, Scott Marlowe wrote:
Generally speaking, I tend towards using the real value as the key and
foreign key in lookup tables, but occasionally using an artificial
numeric key is a better choice.
Something to consider here... any table that will have either a lot
of r
On Feb 15, 2008 5:25 PM, Scott Marlowe <[EMAIL PROTECTED]> wrote:
> On Feb 15, 2008 3:31 PM, James B. Byrne <[EMAIL PROTECTED]> wrote:
> >
> > On Fri, February 15, 2008 14:43, Scott Marlowe wrote:
> > >
> > >> For something externally provided and widely used like country codes
> > >> then option
On Feb 15, 2008 3:31 PM, James B. Byrne <[EMAIL PROTECTED]> wrote:
>
> On Fri, February 15, 2008 14:43, Scott Marlowe wrote:
> >
> >> For something externally provided and widely used like country codes
> >> then option one is attractive and possibly the most sensible and
> >> robust solution.
On Fri, February 15, 2008 14:43, Scott Marlowe wrote:
>
>> For something externally provided and widely used like country codes
>> then option one is attractive and possibly the most sensible and
>> robust solution. But consider things like transaction status codes.
>> Perhaps an invoice tran
On Fri, Feb 15, 2008 at 12:12 PM, James B. Byrne <[EMAIL PROTECTED]> wrote:
>
> I can over-ride Rails assumptions and force a primary key formed by multiple
> columns which will have a unique index automatically created for the
> previously described "system_values_table". My question still hin
On Fri, February 15, 2008 12:38, Richard Huxton wrote:
>
> I'm not a Rails guy, but everything I've read about it suggests if
> you're going to gain any advantage from it, then you should follow its
> way of doing things. That means not converting anything, but rather
> writing a rails app that do
James B. Byrne wrote:
I am considering how best to handle the issue of attribute encoding for an
OLTP application conversion.
[snip]
The conversion project framework is Ruby on Rails which embeds the practice of
arbitrary integer primary keys assigned by sequencers rather than so-called
"natur
I am considering how best to handle the issue of attribute encoding for an
OLTP application conversion. The existing system, which does not employ a
relational DBMS in the commonly accepted sense, uses a "system_table" to
validate system codes. This dataset uses concatenated fields to form a uniq
