SQL/MX 3.2.1 Management Manual (H06.26+, J06.15+)

2 Understanding and Planning SQL/MX Tables
An understanding of the types of organizations of SQL/MX tables and their key-sequenced file
structure is essential for effective use and functioning of the database.
This section presents conceptual information about SQL/MX tables and describes how to plan for
them, including:
• “Planning Object Naming” (page 29)
• “Understanding SQL/MX Table and File Structures” (page 30)
• “Using Keys in SQL/MX Tables and Indexes” (page 31)
• “The Key-Sequenced File Structure” (page 32)
• “Planning Table and Index Partitioning” (page 34)
• “Determining a Database Layout” (page 35)
For more information, see “Creating an SQL/MX Database” (page 73).
For more information about understanding and planning SQL/MP tables, see the SQL/MP Installation
and Management Guide.
Planning Object Naming
When you plan your SQL/MX database, you should develop and implement a strategy for naming
database objects that effectively serves the short-term and long-term needs of your database. To
do this, you must consider and plan for certain realities that govern ANSI naming for SQL/MX
database objects:
• “Avoid Renaming Nodes” (page 29)
• “Avoid Changing Object Names or Moving Database Objects” (page 29)
• “Understand the Schema Ownership Rule” (page 30)
• “Avoid Using Duplicate Catalogs on Multiple Distributed Nodes” (page 30)
For more information about using ANSI names, see “Introduction to SQL/MX Database
Management” (page 18), and the SQL/MX Reference Manual.
Avoid Renaming Nodes
After an SQL/MX database node has been installed and initialized, do not attempt to change the
node name. The node name is recorded in system metadata entries and file labels throughout the
database. The node number is not recorded anywhere.
Avoid Changing Object Names or Moving Database Objects
You should develop and implement an object-naming strategy that prohibits changing object names
or moving named objects. This strategy is important because many production databases contain
hundreds or thousands of database objects and hundreds of programs or MXCI scripts that reference
the original object names. No automated tools exist to perform programmatic updates.
The best way to avoid changing object names is to carefully plan for and develop in advance
object names that can be retained over the years and to enforce a policy against changing names.
To help in this endeavor, do not name objects with company, project, product, or employee names
that might need to be changed.
Starting with the SQL/MX Release 3.1, a new feature is introduced to modify the ANSI and
Guardian names of some objects. For more information on this feature, see the SQL/MX Reference
Manual.
Planning Object Naming 29