You are here: Re: Function Parameter « MsSQL Server « IT news, forums, messages
Re: Function Parameter

Posted by --CELKO-- on 04/29/07 12:23

>> Please can you explain what you mean by this? <<

The ISO-11179 standards for naming data elements are based on the idea
that you name things for what they inherently are. That name is then
used everywhere in the schema.

You do NOT name them for:

1) How they are physically stored -- that means you do not put the
data type into the name. We had to do in the original versions of
BASIC because the interpreters needed that information to allocate
storage on the fly. A lot of programmers never un-learned that.

Physical locators generated by the physical storage are never
attributes in the schema. IDENTITY is never a key. We do not make
the user navigate the tables using track and sector numbers, etc. The
SQL engine is supposed to handle surrogates and not the humans.

It also means no silly "tb-" or "tbl-" to tell us it is a table
(there is only *one* data structure in SQL, duh!). And no vw-" affix
to tell us it is a VIEW (the "vw-" thing always looked like a
"Volkswagen" to me).

2) Where they are located - that means the table name is not part of
the data element name. Do you change your name from place to place as
you move around? Of course not. This practice also screws up the
data dictionary (if you do not have a data dictionary your project is
really screwed).

3) How they are used in one place -- that means no "pk-" or "fk-"
affixes. That is also silly because the same identifier that is a
FOREIGN KEY in the referencing has to be UNIQUE or a PRIMARY KEY in a
second table by definition.

The correct format is "<entity name>_<attribute type>" in lower case
for column names. The attribute types are defined in your data
dictionary, but I have a short list in other postings.

4) A data element name does not have multiple attribute types. That
means you can have "customer_id" or "customer_type" but never
"customer_type_id" because the attribute has to be either an
identifier (unique per customer) or a type (applies to many
customers).

This is usually a newbie confusing data and metadata in his attempt at
a data model.

5) A data element name is not a single attribute type. There is no
such thing as the magical, universal "id" or "date" or "value" etc.
An attribute has to be the identifier of something in particular, the
date of a particular kind of event, the value of a known attribute as
measured on a scale, etc. It is also a sign the project has no data
dictionary because you would quickly see that these magical vague
attributes apply to automobiles, squids and Britney Spears.

"To be is to be something in particular; to be nothing in particular
or everything in general is to be nothing." - Aristotle

6) A data element name is not a dangling entity name. The data
element name "customer" by itself begs the question "what?"
--"customer_id", "customer_type", "customer_name", or what? My
favorite is assuming that "sex" means "sex-frequency" or
"sex_preference" and not "sex_code" when I get a form.

The programmer has confused a table with a file and expects context to
provide the information he was too lazy to put into the table. The
field names in a file are local to the file; the column names are
global to the schema or better yet, are global to a data model that
covers your entire enterprise or industry.

An exception to this is the use of industry standard names that are
well understood in your enterprise. For example, VIN for automobiles,
ISBN for books, etc.

7) Tables are sets and should have collective or plural names, not
singular ones. That is, "Employee" is a bad table name (exception:
you really do have only one employee); "Employee" is better;
"Personnel" is best. Collective nouns imply a set by their nature and
will not be used in attribute names, which have a singular name
because their values apply to an element in the set.

An exception to this is the use of industry standard names that are
well understood in your enterprise. But most of these will be
collective nouns.

8) Relationship tables should use a common name for the relationship
and not an invented hyphenate. For example, "Roster" and not
"StudentClass" or worse.

I you wish, I can also post a quick look at ISO-11179.

 

Navigation:

[Reply to this message]


Удаленная работа для программистов  •  Как заработать на Google AdSense  •  England, UK  •  статьи на английском  •  PHP MySQL CMS Apache Oscommerce  •  Online Business Knowledge Base  •  DVD MP3 AVI MP4 players codecs conversion help
Home  •  Search  •  Site Map  •  Set as Homepage  •  Add to Favourites

Copyright © 2005-2006 Powered by Custom PHP Programming

Сайт изготовлен в Студии Валентина Петручека
изготовление и поддержка веб-сайтов, разработка программного обеспечения, поисковая оптимизация