Primary Keys and Pseudokeys - pengdows/pengdows.crud GitHub Wiki

Table of Contents

Candidate Keys

Any combination of one or more columns that uniquely identify a record in a database table. These are the legitimate keys that naturally enforce uniqueness based on real-world meaning.

Primary Keys

A primary key is the candidate key you choose to define the record's identity in business terms. This should reflect the "reason for the row's existence."

  • Must be NOT NULL
  • Must be unique
  • Should represent a real-world concept (like a username, SKU, or email)
  • Typically defines the clustered index
In pengdows.crud, these are marked using the [PrimaryKey] attribute and may span multiple columns. The system uses them for "where by primary key" logic such as BuildWhereByPrimaryKey().

Pseudo Keys

A pseudo key is a synthetic, usually auto-generated value used strictly to uniquely identify a row. Commonly named Id, UserId, or Guid, this is the key used for foreign key relationships and often as a default lookup.

  • May be a GUID, int, or deterministic hash
  • Exists only to provide a unique identity — not business meaning
  • Usually a single column, marked with [Id]
In pengdows.crud:
  • This is the default key used by EntityHelper<T, TID> for CRUD operations
  • Only one [Id] property is allowed per class

Best Practices

  • Use a real candidate key as the primary key
  • Use a pseudo key as a stable unique identifier — useful for foreign keys
  • Do not make the pseudo key your primary key — this leads to schema drift and poor indexing
  • Define your clustered index on the primary key — the thing queries actually filter on

In pengdows.crud

pengdows.crud enforces this philosophy:

  • [Id] marks a unique pseudo key column — single column only
  • [PrimaryKey] may be used on one or more fields
  • Tables must have a unique single-column [Id] to use the full EntityHelper automation
  • BuildWhereByPrimaryKey() and RetrieveByPrimaryKey() target [PrimaryKey] columns instead of [Id]
This allows you to:
  • Use deterministic UUIDs as [Id] while still enforcing real-world uniqueness on [PrimaryKey]
  • Maintain proper indexing and cardinality
  • Keep foreign keys consistent while enforcing business logic

Related Pages

⚠️ **GitHub.com Fallback** ⚠️