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.

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

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:

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.

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.

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 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:

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

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:

To overload procedures in SqlDBM: