Icon View Thread

The following is the text of the current message along with any replies.
Messages 11 to 19 of 19 total
Thread Naming conventions
Wed, Jul 5 2006 1:47 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Steve,

<< If I understand your schema correctly, I would name as follows:

Company
CompanyClassification
Classification >>

I agree.  Long table names are your friend in DBISAM/ElevateDB.  They don't
hurt anything other than your fingers from all of the typing. Smiley

--
Tim Young
Elevate Software
www.elevatesoft.com

Wed, Jul 5 2006 6:58 PMPermanent Link

"Eric Schwarz"
Ok, now it gets interesting.  What if several tables had "Classification"
support tables where the Classification codes were different for each main
table?  What I'm looking for is how others keep the sanity in naming tables
with similiar support tables and keeping in mind fieldnames within Delphi
code.

"Steve Forbes" <ozmosys@spamfreeoptusnet.com.au> wrote in message
news:20B6A81A-2F9E-43ED-95C9-891AC6C2F137@news.elevatesoft.com...
> Hi Eric,
>
> If I understand your schema correctly, I would name as follows:
>
> Company
> CompanyClassification
> Classification
>
> --
> Best regards
>
> Steve
>
> "Eric Schwarz" <eric@HATE-THAT-SPAMcomputer-strategies.com> wrote in
message
> news:16E1C785-E050-4C9A-9271-6AE7E27EBBAA@news.elevatesoft.com...
> > Let's say you have a Company table that has a 1-N relationship with a
> > table
> > that contains codes for the possible classifications for each company,
> > e.g.,
> > manufacturer, distributer, etc.  In addtiion, you have a lookup code
table
> > that contains all the classifications and their descriptions.  Any
> > interesting naming conventions for that scenario?  Depending on the
naming
> > conventions used, the table names in combination with field names can be
> > interesting/confusing/conflicting.
> >
> > "Steve Forbes" <ozmosys@spamfreeoptusnet.com.au> wrote in message
> > news:62BA8E52-554D-4ED4-B28B-A2C776E3464D@news.elevatesoft.com...
> >> Hi Eric,
> >>
> >> I do basically what Tim said i.e. non-plural noun .. related tables I
> >> prepend the "owner" tables name e.g.
> >>
> >> Customer
> >> CustomerOrder
> >> CustomerOrderItem
> >>
> >> Lookup/details tables are named the same as other primary tables
> >>
> >> --
> >> Best regards
> >>
> >> Steve
> >>
> >> "Eric Schwarz" <eric@HATE-THAT-SPAMcomputer-strategies.com> wrote in
> > message
> >> news:F97F6298-0B07-4D09-96F0-563C06389F08@news.elevatesoft.com...
> >> >
> >> > "Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in
> > message
> >> > news:2458D3AE-42D4-4B49-BC59-00C1620F59E0@news.elevatesoft.com...
> >> >> Eric,
> >> >>
> >> >> << I was wondering what table naming conventions people use.  Not so
> > much
> >> >> interested in the column names as the table names themselves and how
> > the
> >> >> names describe the contents and relationships to other tables. >>
> >> >>
> >> >> A lot of books simply recommend using the noun that that table
> >> >> represents,
> >> >> minus any plural form, such as "customer" for a customers table,
> > "order"
> >> > for
> >> >> an orders table, etc.
> >> >
> >> > I was looking for names of lookup tables, detail tables, cross refs,
> > etc.
> >> > Tables that relate to a main table and how they're named to indicate
> >> > the
> >> > relationships.  I've been doing this stuff a long time and sometimes
I
> > get
> >> > curious what other people do so that I don't get into a rut.Smiley
> >> >
> >> >
> >> >
> >>
> >>
> >
> >
>
>

Wed, Jul 5 2006 9:30 PMPermanent Link

Steve Forbes

Team Elevate Team Elevate

Hi Eric,

> Ok, now it gets interesting.  What if several tables had "Classification"
> support tables where the Classification codes were different for each main
> table?  What I'm looking for is how others keep the sanity in naming
> tables
> with similiar support tables and keeping in mind fieldnames within Delphi
> code.

I would probably group all classifications into a single Classification
table and maintain an additional column (possibly RelatedTable) to determine
which they belong to (for maintenance/presentation purposes). Otherwise,
(not my preferred method) I'd do the following:

Company
CompanyClassification
CompanyClassificationLookup

Order
OrderClassification
OrderClassificationLookup

etc.

--
Best regards

Steve

"Eric Schwarz" <eric@HATE-THAT-SPAMcomputer-strategies.com> wrote in message
news:7A0671CA-CB8B-4FC5-9A20-75C9EAA72FEC@news.elevatesoft.com...
> Ok, now it gets interesting.  What if several tables had "Classification"
> support tables where the Classification codes were different for each main
> table?  What I'm looking for is how others keep the sanity in naming
> tables
> with similiar support tables and keeping in mind fieldnames within Delphi
> code.
>
> "Steve Forbes" <ozmosys@spamfreeoptusnet.com.au> wrote in message
> news:20B6A81A-2F9E-43ED-95C9-891AC6C2F137@news.elevatesoft.com...
>> Hi Eric,
>>
>> If I understand your schema correctly, I would name as follows:
>>
>> Company
>> CompanyClassification
>> Classification
>>
>> --
>> Best regards
>>
>> Steve
>>
>> "Eric Schwarz" <eric@HATE-THAT-SPAMcomputer-strategies.com> wrote in
> message
>> news:16E1C785-E050-4C9A-9271-6AE7E27EBBAA@news.elevatesoft.com...
>> > Let's say you have a Company table that has a 1-N relationship with a
>> > table
>> > that contains codes for the possible classifications for each company,
>> > e.g.,
>> > manufacturer, distributer, etc.  In addtiion, you have a lookup code
> table
>> > that contains all the classifications and their descriptions.  Any
>> > interesting naming conventions for that scenario?  Depending on the
> naming
>> > conventions used, the table names in combination with field names can
>> > be
>> > interesting/confusing/conflicting.
>> >
>> > "Steve Forbes" <ozmosys@spamfreeoptusnet.com.au> wrote in message
>> > news:62BA8E52-554D-4ED4-B28B-A2C776E3464D@news.elevatesoft.com...
>> >> Hi Eric,
>> >>
>> >> I do basically what Tim said i.e. non-plural noun .. related tables I
>> >> prepend the "owner" tables name e.g.
>> >>
>> >> Customer
>> >> CustomerOrder
>> >> CustomerOrderItem
>> >>
>> >> Lookup/details tables are named the same as other primary tables
>> >>
>> >> --
>> >> Best regards
>> >>
>> >> Steve
>> >>
>> >> "Eric Schwarz" <eric@HATE-THAT-SPAMcomputer-strategies.com> wrote in
>> > message
>> >> news:F97F6298-0B07-4D09-96F0-563C06389F08@news.elevatesoft.com...
>> >> >
>> >> > "Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in
>> > message
>> >> > news:2458D3AE-42D4-4B49-BC59-00C1620F59E0@news.elevatesoft.com...
>> >> >> Eric,
>> >> >>
>> >> >> << I was wondering what table naming conventions people use.  Not
>> >> >> so
>> > much
>> >> >> interested in the column names as the table names themselves and
>> >> >> how
>> > the
>> >> >> names describe the contents and relationships to other tables. >>
>> >> >>
>> >> >> A lot of books simply recommend using the noun that that table
>> >> >> represents,
>> >> >> minus any plural form, such as "customer" for a customers table,
>> > "order"
>> >> > for
>> >> >> an orders table, etc.
>> >> >
>> >> > I was looking for names of lookup tables, detail tables, cross refs,
>> > etc.
>> >> > Tables that relate to a main table and how they're named to indicate
>> >> > the
>> >> > relationships.  I've been doing this stuff a long time and sometimes
> I
>> > get
>> >> > curious what other people do so that I don't get into a rut.Smiley
>> >> >
>> >> >
>> >> >
>> >>
>> >>
>> >
>> >
>>
>>
>
>

Thu, Jul 6 2006 1:55 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Steve,

<< I would probably group all classifications into a single Classification
table and maintain an additional column (possibly RelatedTable) to determine
which they belong to (for maintenance/presentation purposes). >>

Not good for RI, though. Wink

--
Tim Young
Elevate Software
www.elevatesoft.com

Thu, Jul 6 2006 5:49 PMPermanent Link

Steve Forbes

Team Elevate Team Elevate

Hi Tim,

> Not good for RI, though. Wink

Not sure why .. each of the user tables would have a RI relationship to
Classification i.e. <UserTable>.ClassificationId -> Classification.Id. The
RelatedTable column mentioned would only be used to identify what context
the Classifications belong to (adding a new entry in the Classification
table, and when determining what to display to the user in the combobox or
picklist etc.)

--
Best regards

Steve

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message
news:4BCC46A1-BD0A-4892-AFF7-27B741E8D618@news.elevatesoft.com...
> Steve,
>
> << I would probably group all classifications into a single Classification
> table and maintain an additional column (possibly RelatedTable) to
> determine which they belong to (for maintenance/presentation purposes). >>
>
> Not good for RI, though. Wink
>
> --
> Tim Young
> Elevate Software
> www.elevatesoft.com
>
>

Fri, Jul 7 2006 11:20 AMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Steve,

<< Not sure why .. each of the user tables would have a RI relationship to
Classification i.e. <UserTable>.ClassificationId -> Classification.Id. The
RelatedTable column mentioned would only be used to identify what context
the Classifications belong to (adding a new entry in the Classification
table, and when determining what to display to the user in the combobox or
picklist etc.) >>

Yes, but ideally you wouldn't want to allow something to be classified in a
context that isn't valid, and RI can't do that when the context is not
present in the table where the foreign key is defined.  Doing so would
involve adding a Context column to every table along with the Classification
column so that both could be used in the RI to ensure that only a valid
classification is entered.

--
Tim Young
Elevate Software
www.elevatesoft.com

Sun, Jul 9 2006 11:20 AMPermanent Link

"GregF"

"Steve Forbes" <ozmosys@spamfreeoptusnet.com.au> wrote in message news:20B6A81A-2F9E-43ED-95C9-891AC6C2F137@news.elevatesoft.com...
> Hi Eric,
>
> If I understand your schema correctly, I would name as follows:
>
> Company
> CompanyClassification
> Classification
>
> --
> Best regards
>
> Steve
>

For my two cents worth
and as a Codd/Date pioneer
and given the example
I would have used

Company
Company_SupplyChainLevels
SupplyChainLevels

I avoid using generic terms like class/type
too often you have clashes leading to confusion

gregF

Wed, Jul 12 2006 6:42 AMPermanent Link

Chris Erdal
"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in
news:B1B5070C-834F-4347-8E04-6A9B1847356F@news.elevatesoft.com:

> Yes, but ideally you wouldn't want to allow something to be classified
> in a context that isn't valid, and RI can't do that when the context
> is not present in the table where the foreign key is defined.  Doing
> so would involve adding a Context column to every table along with the
> Classification column so that both could be used in the RI to ensure
> that only a valid classification is entered.

Add a tables table with an ID against each table name, and use that ID as
the context? But how would each table know its own ID? hummm...

--
Chris
Wed, Jul 12 2006 2:03 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Chris,

<< Add a tables table with an ID against each table name, and use that ID as
the context? But how would each table know its own ID? hummm... >>

Exactly. Smiley

--
Tim Young
Elevate Software
www.elevatesoft.com

« Previous PagePage 2 of 2
Jump to Page:  1 2
Image