Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM General Discussion » View Thread |
Messages 11 to 19 of 19 total |
Naming conventions |
Wed, Jul 5 2006 1:47 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. 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. -- Tim Young Elevate Software www.elevatesoft.com |
Wed, Jul 5 2006 6:58 PM | Permanent 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. > >> > > >> > > >> > > >> > >> > > > > > > |
Wed, Jul 5 2006 9:30 PM | Permanent Link |
Steve Forbes 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. >> >> > >> >> > >> >> > >> >> >> >> >> > >> > >> >> > > |
Thu, Jul 6 2006 1:55 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. 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. -- Tim Young Elevate Software www.elevatesoft.com |
Thu, Jul 6 2006 5:49 PM | Permanent Link |
Steve Forbes Team Elevate | Hi Tim,
> Not good for RI, though. 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. > > -- > Tim Young > Elevate Software > www.elevatesoft.com > > |
Fri, Jul 7 2006 11:20 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. 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 AM | Permanent 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 AM | Permanent 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 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. 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. -- Tim Young Elevate Software www.elevatesoft.com |
« Previous Page | Page 2 of 2 | |
Jump to Page: 1 2 |
This web page was last updated on Wednesday, April 24, 2024 at 11:07 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |