Primary Keys and Pseudokeys - pengdows/pengdows.crud GitHub Wiki
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.
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
[PrimaryKey]
attribute and may span multiple columns. The system uses them for "where by primary key" logic such as BuildWhereByPrimaryKey()
.
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]
- This is the default key used by
EntityHelper<T, TID>
for CRUD operations - Only one
[Id]
property is allowed per class
- 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
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()
andRetrieveByPrimaryKey()
target[PrimaryKey]
columns instead of[Id]
- 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