<background info>
There are two main camps in database design style. You could almost say
there are three if you count the newbies who haven't "found" one of the
other two yet. One camp derives their style from object oriented
development. These people use tables with singular names with simple
(non-unique) names for fields. Referring to one of these fields in a
query is similar in format to saying that the object (table) "person" has
a property (field) of "name" because you would refer to both as
"person.name".
The second camp, as is described in the article, are more data-oriented.
This practice was created in the original days of databases and
programming design where ALL variables, including table names and field
names, were global and needed to be absolutely unique. In this case you
give tables plural names (They do hold lists of things, right? In
conversation you would say "This is the 'vendors' list for todays event"
or the "addresses" table, referring to a table of addresses).
You uniquely identify all fields for several reasons:
You avoid the need to use table.fieldname in any query
If you see a field name in a query that someone else wrote, you
can instantly deduce which table it comes from.
Different fields with the same short name could have different
data types. For example: on the "person" table the "name" field is
varchar(20) but on the "vendor" table the "name" field is varchar(128). If
you expect to recieve 20 characters but got 128, that could cause some
headaches, right?
There are even styles within the style. Some people split the "table
prefix" from their field name with an underscore, some use all proper
case, others use lower case for the prefix and proper case the field name.
I look at the issue as a matter of style and coding convention. I know
there are strong opinions about both styles and I am not advocating one
over the other. It is important that you conform to the coding styles and
conventions of your organization. Being an odd-ball could make your
designs harder to read and maintain. However, if you know that there is
chaos in your organization, you **could** help things by picking a style
and sticking to it. As everyone else begins to notice how readable and
maintainable your code is, they will slowly come around.
</background>
<answer>
Finally, to answer your question: Yes, the author of that article is
suggesting that you uniquely name ALL of your fields (so that no two
tables in the same database could possibly contain identically named
fields) by prepending the table name to the "simple" name of each and
every field.
</answer>
Shawn Green
Database Administrator
Unimin Corporation - Spruce Pine
"Chris W. Parker" <[EMAIL PROTECTED]> wrote on 10/12/2004 07:40:14 PM:
> hello,
>
> continuing my quest to build a better database, i'd like to ask a
> question that i haven't been able to find an answer to. here is an
> excerpt from an article on evolt
> (http://www.evolt.org/article/Beginning_Database_Design_Part_I/18/27137/
> ): (and where i got the idea as well)
>
> "You'll probably see some duplicate field names, such as 'Name' in both
> the 'Companies' and 'People' tables. Let's make them unique across the
> database. You might choose 'ContactName' and 'CompanyName' but whatever
> you use, stick to the guidelines above, and be consistent."
>
> is this person suggesting that *all* fields within the 'Companies' table
> be prepended with "Company" (i.e. CompanyName, CompanyAddress1,
> CompanyZip, etc.) or is he suggesting that only fields which have the
> same name in multiple tables have "Company" added?
>
> THIS:
>
> +---------------------+
> | COMPANIES |
> +---------------------+
> | CompanyName |
> | CompanyDate |
> | CompanySize |
> +---------------------+
>
> +---------------------+
> | CONTACTS |
> +---------------------+
> | ContactName |
> | ContactHeight |
> | ContactWeight |
> +---------------------+
>
> OR THIS:
>
> +---------------------+
> | COMPANIES |
> +---------------------+
> | CompanyName |
> | Date |
> | Size |
> +---------------------+
>
> +---------------------+
> | CONTACTS |
> +---------------------+
> | ContactName |
> | Height |
> | Weight |
> +---------------------+
>
>
>
> Thank you for your time.
>
> Chris.
>
> --
> MySQL General Mailing List
> For list archives: http://lists.mysql.com/mysql
> To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
>
