Is "name" a keyword?

It's blue in SQL Studio but I can't find it in SQL Books on-line. I
wanted to use it as a field name but don't like using [].

Is it reserved?

It is not a keyword in Standard SQL, but it is too vague to be a column
or other data element name by itself

It is a modifier -- think about what it.  Name?? Name of what?
Employee?  Pet?  Product? etc.

Also a field is a totally different concept from a column!.

Cecil wrote:

> It's blue in SQL Studio but I can't find it in SQL Books on-line. I
> wanted to use it as a field name but don't like using [].
>
> Is it reserved?

It's reserved for the inexperienced who won't bother to come up with a
more useful and informative name. The rest of us know better because
we've had too many bad experiences trying to make sense of other
people's designs with fatuous names like "ID", "NAME", "DATE" or (I kid
you not) "DATA".

--
David Portas
SQL Server MVP
--

OK, can you help me to understand why ID and name are poor field
choices. I am asuming it has to do w/ ambiguity. I always qualify
fields w/ their table names for precisely this reason, so I always
concidered something like Category.categoryID to be very redundant.

I prefer Category.ID and Category.name. The only time I would write
CategoryID is if it was a foreign key linking to the "ID" field in the
Category table.

If you believe this to be poor practice, would you please explain why?
Thanks.

Cecil wrote:

> OK, can you help me to understand why ID and name are poor field
> choices. I am asuming it has to do w/ ambiguity. I always qualify
> fields w/ their table names for precisely this reason, so I always
> concidered something like Category.categoryID to be very redundant.
>
> I prefer Category.ID and Category.name. The only time I would write
> CategoryID is if it was a foreign key linking to the "ID" field in the
> Category table.
>
> If you believe this to be poor practice, would you please explain why?
> Thanks.

Naming conventions are supposed to aid understanding, verification,
interchange, and ongoing maintenance of code by others. Generally
accepted standards and conventions therefore ought to be more important
than personal preferences. Quote: "Any fool can write code that a
computer can understand. Good programmers write code that humans can
understand." (Martin Fowler). The same applies to your data model.
There is in fact an international standard for naming data elements:
http://metadata-standards.org/

One principle that's very widely used and that works well is that every
single data element should have a unique name in your database schema.
That means that foreign keys usually have the same name as the column
that they reference and that most column names won't appear in more
than one table except where they are keys or part of compound keys.

The advantages of using unique names are many:

- When maintaining schema and code you can easily search for column
name references in your code because each column has a unique name.
Your idea of qualifying each with the table name won't work because in
correlations and multiple joins to the same table you may be forced to
use aliases rather than table names. That means you can never reliably
search for a particular column. You'll have to manually check for each
occurence of "NAME" to see if it's the right one.

- Types and constraints can be defined and checked by column name
throughout the database. This is ideally suited to systematic auditing
of the schema, something which ought to be part of any implementation.

- Data dictionaries can be smaller and simpler to use by referencing
each element name rather than each table and name.

- Your code will be more readable if you use short aliases but that
only helps if you use concise and meaningful column names.

- Data interchange with XML for example is also made easier if you use
unique names for data elements.

- You'll be much less likely to clash with present and future reserved
keywords because most keywords are simple nouns or verbs whereas the
column names that are likely to conflict with them are usually
compounds.

--
David Portas
SQL Server MVP
--

David,

Thank you for your thoughtful reply. I will consider adopting your
recommendations.

I agree with 'DATE' and 'DATA' but ID and NAME, it depends on your style.

Its good practice to alias table's on the FROM clause and to specify the
alias when referencing those columns - it helps maintanence by knowing
clearly where columns are referenced from.

create table Logon (
id    int not null....

The above declaration for instance, in a SQL statement you would write...

select logon_id = l.id
from Logon l

The table (set) is a container in the same way an object (table) is a
container, the object just contains properties (columns) though rather than
any methods.

My two cents.

Tony.

--
Tony Rogerson
SQL Server MVP
http://sqlserverfaq.com - free video tutorials


"David Portas" < REMOVE_BEFORE_REPLYI
NG_dportas@acm.org> wrote in message
news:1135722026.375744.184650@f14g2000cwb.googlegroups.com...
> Cecil wrote:
> 
>
> It's reserved for the inexperienced who won't bother to come up with a
> more useful and informative name. The rest of us know better because
> we've had too many bad experiences trying to make sense of other
> people's designs with fatuous names like "ID", "NAME", "DATE" or (I kid
> you not) "DATA".
>
> --
> David Portas
> SQL Server MVP
> --
>