Object design in SqlDBM supports but does not require the use of fully qualified database names. However, no matter which naming style you choose, you must ensure that your objects use unique names to avoid ambiguity.

To help ensure uniqueness, SqlDBM has set up safeguards at various points in the design process to help avoid duplicates.

Preventing duplicate objects

When considering object names, SqlDBM users can opt to use fully-qualified names or use simple object naming.

Naming styles:

• Simple object name: names the object without specifying the schema or database. (e.g., myObject)

• Fully qualified name: when database and schema are defined for a given object, they form the fully qualified name along with the simple object name. (e.g., myDB.mySchema.myObject)

Understanding uniqueness

Uniqueness in SqlDBM is considered on the level of the fully qualified name. When fully qualified name details are not provided, only the object name is considered.

Note that uniqueness is not case-sensitive in SqlDBM. While this may not conform to the way some databases handle casing and quoting, SqlDBM does not consider case when comparing object names, even if enclosed in quotes.

The following are all considered unique object names:

• customer

• edw.customer

• prod.edw.customer

• raw.customer

• prod.raw.customer

Preserving uniqueness

To help ensure uniqueness at the object level, SqlDBM will show a popup whenever a duplicate object name has been set—giving the user a chance to correct the problem.

When duplicates are encountered, use the popup options to change the object schema or object name to ensure uniqueness. Dismissing the popup will return the object name to its previous state.

For bulk edits, individual renaming will not be possible through the popup, but a list of conflicting object names is displayed for reference. In a bulk naming conflict, changes will not be applied.

Preventing duplicates within an object

Duplicates can also occur within a project object, as is the case with columns, constraints, or other properties. SqlDBM has various safeguards in place to prevent duplicates from occurring in these cases.

Singular objects

The SqlDBM UI is designed to prevent singular objects like primary keys and object-level properties from being defined multiple times—preventing the possibility of their duplication. Should such duplicates be introduced through invalid DDL during the reverse engineering process, they will be skipped.

Repeatable objects

Repeatable elements like column names and foreign or unique constraint names must be unique to the object in which they reside. To accomplish this and safeguard against duplicates—which would otherwise produce invalid DDL—SqlDBM appends an "undercore N" to duplicate objects to ensure their uniqueness.

For example, attempting to define the name column three times in one table would result in the following column names:

• name

• name_1

• name_2

Such elements must be edited by hand to provide them with unique names.

Functions & procedures

Functions and procedures can be overloaded (i.e., declared with the same object name but using different parameters) and are considered unique as long as the parameter signatures differ.

The following are all considered unique procedures:

• myProc()

• edw.myProc()

• edw.myProc(strVar STRING)

• edw.myProc(strVar STRING, intVar INT)

To overload procedures in SqlDBM:

• Declare them with unique names first (e.g., myProc() and myProc2())

• Add parameters to the procedures you wish to overload (e.g., myProc2(strVar STRING)

• Rename the procedure with overloaded parameters (e.g., myProc2(strVar STRING) -> myProc2(strVar STRING) )

See also:

• Tables

• Snowflake tables

• Azure Synapse Analytics tables

• Procedures & UDFs

• Views