Kbase P25825: Dynamics. Table Naming Conventions
Autor |
  Progress Software Corporation - Progress |
Acesso |
  Público |
Publicação |
  15/10/2008 |
|
Status: Unverified
GOAL:
Dynamics. Table Naming Conventions
FACT(s) (Environment):
Dynamics 2.0A
FIX:
Table names should be unique across the whole range of databases used by an application. This makes it possible to identify any table used by the application just by the table name, which Dynamics takes advantage of to allow common operations, such as associating comments with a record, or logging auditing
information for a record, to be done in a standard way for any database table. In Dynamics there is a presumption that the dump name of every table used by the application is unique. Since the dump name now has no length constraint, and can in fact always be the same as the table name, this is not particularly an issue. However, be aware that there is a convention in Dynamics of using the dump name as an identifier that is displayed in various places, and a name that is five to eight characters long is considered standard (and might be reflected in default display formats, for example).
There?s no straightforward way to guarantee, of course, that a table name will be unique forevermore in any set of databases that is used by an application. In this regard, it can be useful to know that the Dynamics repository database observes a convention of prefixing every table name with a three-letter code followed by an underscore. This convention helps define the nature of the information in the table and helps create a name space that makes conflicts between table names unlikely. The first two letters of the name are an
abbreviation of the application or ?module? name for which the table is principally used. Within the Dynamics repository, for example, the prefix ?ry? is used for tables that form part of the framework repository. The third character identifies the nature of the data in the table, its volatility if you will.
You do not need to observe this particular convention, but it can be a useful way of organizing the data in your databases and making the usage of a table at least basically understandable just from looking at the name.
Another Dynamics convention is to specify a unique two-letter code for each table name. (This two-letter code is arrived at much like U.S. state codes, by using the first two letters of the name, or the two ?predominant? letters, such as the first letter of each of the two words in a two-part name, or failing that, any other combination of letters that is unique at least within the application or module.) By appending this two-letter sequence to the three-letter table prefix, each table now has a unique five-letter abbreviation (referred to as its five-letter acronym or ?FLA?). This abbreviation has been expanded so that programs in the framework that use it expect up to eight characters (based on the dump name of the table). Procedures and logical objects are identified by beginning their names with the FLA of the principal table operated on by the procedure or logical object. In this way, all the procedures and objects for an application can be organized and sorted in a meaningful way just based on their names. Again, you do not need to observe this naming convention to use Dynamics successfully. However, it serves as a useful model for naming entities in a helpful and consistent way.
An example of Dynamics table naming is within the Dynamics repository database.. There is a table for maintaining attribute groups, identifying related attributes that should be managed or visualized together.
Because this table is part of the Repository (ry) module and it maintains constant (c) data - values that should not change once they are defined within the framework the table name prefix is ryc. The table name is ryc_attribute_group. Using a meaningful and complete phrase for the table name makes it easy to turn the name into a description that you can insert into messages or reports.. By removing the prefix and the underscores, Dynamics refers to this table as the ?attribute group? table. The same convention applies to
field names and the default labels that are generated. for them.
The letters ?ag? make up the unique two-letter abbreviation for ?attribute group?, which lets you create the FLA of ?rycag? as the table?s unique identifier. In turn, you can use this FLA at the beginning of every file
name or object name that maintains this table. This can include rycagfullo.w as the SDO for the table with all fields. You can name the primary SmartDataViewer? for the table rycagviewv.w or another completion that identifies it. You can give other Viewers other names beginning rycag and ending in v, or whatever convention is appropriate to your application.
Values for Third Character in Dynamics Table Prefixes.
Character Data or Table Type Description
c constant ?Constant? data is used effectively as system parameters and value lists and normally does notchange.
m master ?Master? tables contain (usually limited) sets of values referred to by other tables, such as country codes or sales rep codes or the like. These values are expected to change relatively infrequently.
t transactional A ?transactional? table contains values subject to frequent change during application execution.
r raw ?Raw? data is subject to further processing..