Robot Catalogue Keys: Read UNIQUE and NULL Together

Robot catalogue keys need a clearer explanation than a column heading that says unique. In an SQLite-backed catalogue, the declaration of a uniqueness constraint and the treatment of a missing value answer different questions. A reviewer who overlooks that difference may assume that every record already carries a usable external identifier. Reading the schema and its stated data policy together provides a better basis for a catalogue handover. This article examines documentation only; it does not inspect or change a live robot database.

Ask which identity the catalogue is trying to preserve

A catalogue can assign an internal record key while also storing a manufacturer's model identifier and an identifier supplied by a contributor. Those fields need not have the same purpose. Before interpreting a constraint, ask which field supports the intended lookup and who owns its meaning. A row's internal identity does not automatically establish that a missing manufacturer identifier can be used to locate a product elsewhere.

For a hypothetical catalogue submission, suppose some entries have a contributor reference while others are awaiting clarification. The reviewer wants to know whether the reference is required and whether supplied references can repeat. These are two separate policy questions. A schema can help explain the technical rules, but it cannot decide what an unknown reference means or whether two descriptions refer to the same real robot.

Read the columns covered by the UNIQUE constraint

The official SQLite CREATE TABLE documentation explains that a UNIQUE constraint concerns the combination of values in its identified columns. It also says that NULL values are considered distinct from all other values, including other NULLs, for this constraint. The declaration therefore needs to be read with both its column list and its NULL behavior visible.

A statement such as this column is unique can hide that important qualification. If the project expects every record to contain a reference, that expectation needs a separate account. The same documentation describes NOT NULL as a constraint against a NULL value in the associated column. Do not infer that requirement merely from UNIQUE, and do not silently treat an empty text value as identical to a database NULL.

The practical reading record should preserve the actual declaration rather than a shortened paraphrase. If the constraint covers a combination of columns, identify that combination. A contributor reference that repeats across different source organizations may raise a different policy question from a repeat within one source. This article does not propose a schema for that fictional situation; it asks the catalogue owner to explain the intended identity boundary.

Do not confuse a DISTINCT result with a constraint check

The SQLite page on NULL handling explains a distinction between NULL treatment for UNIQUE columns and for SELECT DISTINCT and UNION. Its historical account describes NULLs as distinct for UNIQUE while indistinct for the latter operations. A compact query result is therefore not interchangeable with the question of which rows a declared uniqueness rule allows.

This second source includes tests and comparison tables originating in 2002 with subsequent historical updates. They are useful context for the SQLite distinction described by the page, but they should not be republished as a current survey of every named database engine. A migration or cross-engine comparison requires current documentation and observations for the actual versions involved. No such comparison has been performed here.

In the hypothetical handover, a contributor might show a short list of distinct references and call the identifier field complete. The reviewer should ask what the list was intended to demonstrate and whether missing-reference records remain outside that presentation. A shorter display does not, on its own, resolve a completeness question or identify which records require follow-up.

Separate a declared rule from observed catalogue contents

Reading a schema establishes what declaration was supplied. Inspecting stored records is a further activity, and checking their meaning against manufacturer sources is another. Keep those levels separate in the acceptance note. If only the schema has been read, say that the uniqueness and required-value rules were identified; do not report a completed audit of robot model identity.

Likewise, if an application rejects an entry, preserve the actual message and relevant context before explaining the cause. This documentation reading does not diagnose an unknown error or recommend deleting apparent duplicates. A missing identifier may require a contributor response, while two matching strings may require understanding their source scope. Neither should be resolved by inventing product information.

Return a field-specific question to the catalogue owner

A useful response names the identifier field, the declared constraint, the intended treatment of missing references and the evidence still needed. Ask the owner how unresolved records are represented and how a later correction will be associated with the original entry. Preserve that policy beside the schema so a receiving editor does not mistake a technical allowance for an editorial approval.

The two original diagrams explain constraint questions without showing real catalogue records or query output. Related materials in the robot model data collection and the article directory discuss other database handover topics. Reading UNIQUE and NULL together makes the identifier rule explicit while leaving record completeness and real-world model identity to their own evidence.