What are Database Keys and their Types?

In any relational database, the ability to uniquely identify each record is essential for maintaining data integrity and supporting efficient queries. Yet data professionals routinely encounter devastating key-related failures that bring systems to their knees. Consider this: research reveals that approximately 50% of databases contain dangling foreign keys pointing to nonexistent records, creating logical corruption that applications cannot detect. Meanwhile, 20% of production systems violate basic primary key standards, leading to data inconsistencies that cascade through business-critical operations.

These aren't theoretical concerns—they represent daily operational nightmares for database administrators and engineers. Unindexed foreign keys trigger full table scans that degrade query performance by 300%. Composite key migrations force schema changes across dependent tables, causing hours of downtime. Monotonic primary keys create "hot shards" in distributed systems, bottlenecking write operations when 90% of traffic hits just 10% of database partitions.

This is where database keys become your first line of defense against data chaos. Just like physical keys unlock specific doors, primary keys, foreign keys, and other key types ensure each piece of information is correctly linked and retrievable. They serve as foundational elements that help establish relationships between tables, prevent duplicate values, and support maintaining data integrity in both simple and complex schemas. Modern data-integration platforms like Airbyte handle millions of key-based relationships daily, processing over 2 petabytes of data while maintaining referential integrity across diverse source systems.

This guide introduces essential types of keys including candidate keys, alternate keys, unique keys, composite keys, and super keys. We'll explore how each one helps uniquely identify rows, ensure data accuracy, and connect multiple tables using consistent key columns. Beyond traditional concepts, we'll examine emerging key-management strategies including temporal database implementations and modern identifier systems that address the scalability and security challenges facing distributed architectures.

Let's start by breaking down what database keys are and why they matter for preventing the costly failures that plague modern data systems.

What Are Database Keys and Why Do They Matter?

A database key is a field, or a group of fields, that uniquely identifies each row in a table. In a relational database, keys are fundamental for organizing data, linking tables, and enforcing rules that keep your data clean and reliable.

Database Keys Are the Foundation of Relational Integrity

Without keys, databases would have no way to tell one record from another. That would make filtering, updating, or joining data nearly impossible. Keys solve this by ensuring each record can be found, related, or updated with precision.

Every key plays a specific role in improving data integrity, preventing duplicate values, and enabling structured queries across multiple tables. In essence, keys are the rule-set that keeps your system organized. Modern data-integration challenges amplify this importance, as systems must maintain key relationships across heterogeneous data sources, cloud platforms, and real-time streaming architectures.

The consequences of poor key design extend beyond theoretical concerns. Organizations frequently experience production incidents when foreign key constraints are disabled during bulk imports, leaving orphaned records that corrupt data validity. Similarly, the absence of proper indexing on foreign keys can cause JOIN-heavy queries to degrade exponentially as data volumes grow, transforming sub-second operations into multi-minute bottlenecks that impact user experience and business operations.

What Are the Main Types of Database Keys Available?

There are several types of keys used in modern databases, including:

• Primary keys – the main unique identifier
• Foreign keys – connect related data across tables
• Candidate keys – other possible ways to uniquely identify rows
• Alternate keys – when more than one unique identifier exists
• Composite keys – two or more columns combined
• Super keys – any combination of columns guaranteeing uniqueness

A Key Is More Than Just a Field

In some cases, you may have multiple candidate keys in a table, each capable of identifying a row. One becomes the primary key, while the others are alternate keys. This flexibility gives you multiple ways to manage data consistency and performance.

Advanced database systems can also accommodate surrogate keys, which are artificial identifiers created by the system, and composite primary keys, which combine multiple fields to ensure uniqueness. In distributed architectures, key management becomes more complex, requiring coordination across multiple databases and ensuring consistency in eventual-consistency scenarios.

Understanding these key types becomes critical when you consider that different scenarios demand different approaches. Auto-incrementing integer primary keys excel in single-database environments but create coordination challenges in distributed systems. Natural keys like email addresses provide business meaning but introduce volatility when business rules change. Composite keys enable complex relationships but complicate schema evolution and migration processes.

Keys as Digital Lock-and-Key Mechanisms

Think of a database key like a physical key. A flat key might open one drawer, while a barrel key or tubular key opens a secure lock. In high-security environments, keys work alongside electronic locks and advanced security solutions. The same applies to digital systems where each key corresponds to one specific record—and without it, access fails.

Why Are Database Keys Critical for System Reliability?

Ensuring Uniqueness and Identity

Keys like primary keys, composite keys, and super keys uniquely identify each row in a table, preventing ambiguity in data retrieval. Data-integration platforms rely on these unique identifiers to merge data from multiple sources without creating duplicates or losing relationships. The absence of proper unique identification leads to scenarios where customer records proliferate across systems, creating inconsistent views of business entities that compromise analytics and operational decisions.

Enforcing Data Integrity Across Tables

Foreign keys ensure data in a child table corresponds to valid entries in a parent table, enforcing referential integrity. Unique keys maintain consistency even when NULL values are permitted, eliminating duplicates and ensuring accuracy. This enforcement becomes particularly crucial in distributed systems where eventual consistency can create temporary states where referential relationships appear broken.

Supporting Performance and Scalability

Keys act as indexed access points, speeding up queries and reducing resource use. As database systems scale, keys simplify relationships and schema maintenance. Modern distributed databases even use keys for sharding strategies, where the choice of shard key directly impacts system performance and hotspot prevention. Poor shard key selection can result in 90% of writes hitting just 10% of database partitions, creating bottlenecks that limit horizontal scaling effectiveness.

Enabling Audit Trails and Compliance

In regulated industries, keys provide the foundation for audit trails and data lineage tracking. Financial systems use compound keys to track transaction histories across time, while healthcare systems rely on patient identifiers to maintain continuity of care records. The ability to trace data relationships through key structures becomes essential for compliance with regulations like GDPR, HIPAA, and SOX.

Aligning With Real-World Structures

Like electronic locks, valet keys, magnetic keys, or even dimple keys, database keys define logical access to digital records. Understanding the different key types keeps your database fast, accurate, and secure, especially in cloud environments where key management complexity increases with distributed architectures and multi-region deployments.

How Does a Primary Key Function as the Main Identifier?

The primary key is the most fundamental type of key in any relational database. It serves as the main unique identifier for each row in a table and must be both unique and non-null.

The Role of the Primary Key in Relational Design

A primary key is used to uniquely identify each record in a table and to establish relationships, especially when referenced by foreign keys. The primary key choice significantly impacts database performance, as most database systems automatically create a clustered index on the primary key, determining the physical storage order of data on disk.

Example: Students Table

‍

CREATE TABLE Students (
 StudentID INT PRIMARY KEY,
 FirstName VARCHAR(50) NOT NULL,
 LastName  VARCHAR(50) NOT NULL
);


Primary Key Design Considerations

The choice between surrogate keys (like auto-incrementing integers) and natural keys (like email addresses) involves important trade-offs. Surrogate keys provide stability and performance benefits but add storage overhead and can complicate debugging. Natural keys offer business meaning but risk instability when business rules change, potentially requiring expensive cascade updates across related tables.

Modern distributed systems often favor UUID-based primary keys to avoid coordination overhead during key generation. However, random UUIDs can cause index fragmentation that degrades write performance. Emerging solutions like UUIDv7 and ULID address this by incorporating timestamp information that preserves chronological ordering while maintaining global uniqueness.

How Do Candidate Keys Provide Alternative Identification Methods?

A candidate key is any column or combination of columns that could serve as a primary key because it uniquely identifies each row and contains no NULL values.

Example: Candidate Keys in Students

‍

CREATE TABLE Students (
 StudentID            INT         PRIMARY KEY,      -- chosen PK
 SocialSecurityNumber VARCHAR(11) UNIQUE,           -- candidate / alternate key
 FirstName            VARCHAR(50) NOT NULL,
 LastName             VARCHAR(50) NOT NULL,
 UNIQUE (FirstName, LastName)                       -- another candidate key
);


The Strategic Value of Multiple Candidate Keys

Having multiple candidate keys provides flexibility during system evolution and migration. When business requirements change, you can potentially switch primary keys without losing referential integrity, though such changes require careful planning and execution. For example, a system initially using Social Security Numbers as primary keys might migrate to generated identifiers for privacy compliance while maintaining the SSN as an alternate key for legacy integration purposes.

The presence of multiple candidate keys also enables performance optimization. Different queries may benefit from different access patterns, and having multiple unique constraints allows the query optimizer to choose the most efficient execution path based on predicate selectivity and index characteristics.

When Should You Implement Unique Keys Over Primary Keys?

A unique key enforces uniqueness in a column or set of columns but allows NULL values (unlike a primary key).

Example: Users Table with Unique Email

‍

CREATE TABLE Users (
 UserID    INT PRIMARY KEY,
 Email     VARCHAR(50) UNIQUE,   -- may be NULL, but must be unique when present
 FirstName VARCHAR(50) NOT NULL,
 LastName  VARCHAR(50) NOT NULL
);


Practical Applications of Unique Keys

Unique keys prove particularly valuable in scenarios where optional but distinct attributes exist. Social media platforms often allow users to have optional usernames that must be unique when provided. E-commerce systems may have optional phone numbers that cannot be duplicated when entered. The ability to enforce uniqueness while allowing NULL values provides the flexibility needed for real-world data scenarios.

Performance Implications

Unique keys automatically create indexes in most database systems, improving query performance for lookups on those columns. However, maintaining multiple unique indexes can impact write performance, particularly during bulk operations. Database administrators must balance the benefits of enforcing uniqueness against the overhead of maintaining additional index structures.

How Do Foreign Keys Establish and Maintain Relationships?

A foreign key links a child table to a parent table by referencing the parent's primary (or unique) key, enforcing referential integrity.

Example: Customers and Orders

CREATE TABLE Customers (
 CustomerID INT PRIMARY KEY,
 FirstName  VARCHAR(50) NOT NULL,
 LastName   VARCHAR(50) NOT NULL
);

CREATE TABLE Orders (
 OrderID    INT PRIMARY KEY,
 CustomerID INT NOT NULL,
 OrderDate  DATE,
 FOREIGN KEY (CustomerID) REFERENCES Customers(CustomerID)
   ON DELETE RESTRICT
   ON UPDATE CASCADE
);


The Critical Importance of Foreign Key Indexing

One of the most common performance pitfalls involves unindexed foreign keys. Without proper indexes, JOIN operations force full table scans that scale poorly with data growth. Research indicates that unindexed foreign keys can degrade query performance by 300% or more in tables with millions of rows. Best practices mandate creating indexes on all foreign key columns immediately upon constraint creation.

Foreign Key Constraints and System Reliability

The enforcement actions (CASCADE, RESTRICT, SET NULL, SET DEFAULT) determine how the database maintains referential integrity during parent record changes. RESTRICT prevents deletions that would orphan child records, while CASCADE automatically propagates changes. The choice between these approaches significantly impacts data safety and system behavior during maintenance operations.

Challenges in Distributed Systems

Foreign key constraints become complex in distributed database systems where related tables may reside on different servers or regions. Some distributed databases like PlanetScale's Vitess historically disabled foreign key support entirely due to cross-shard enforcement challenges. Modern solutions employ distributed transaction protocols or application-level consistency checks to maintain referential integrity across partitioned systems.

What Defines a Super Key in Database Design?

A super key is any combination of columns that uniquely identifies rows. Every candidate key is a super key, but not all super keys are minimal.

Understanding Super Key Minimality

Super keys can include redundant columns that don't contribute to uniqueness. For example, in a Students table, (StudentID, FirstName, LastName, DateOfBirth) forms a super key because StudentID alone ensures uniqueness. However, this super key is not minimal—it contains unnecessary columns that increase storage and processing overhead without improving identification capability.

Practical Implications for Database Design

While super keys provide theoretical completeness in relational design, practical database implementations focus on minimal keys to optimize performance. Non-minimal super keys can lead to bloated indexes and increased maintenance overhead. Database designers should identify minimal candidate keys and avoid creating constraints or indexes on non-minimal super key combinations.

How Do Alternate Keys Support Flexible Data Access?

An alternate key is a candidate key that was not chosen as the primary key but still enforces uniqueness.

Strategic Use of Alternate Keys

Alternate keys provide multiple access paths to the same data while maintaining uniqueness constraints. In customer management systems, CustomerID might serve as the primary key while Email becomes an alternate key. This dual approach enables efficient lookups regardless of whether applications have the internal identifier or the business identifier.

Implementation Best Practices

Alternate keys should be implemented using UNIQUE constraints rather than secondary primary keys. This approach maintains clear entity identification through the primary key while enabling efficient alternative access patterns. Most database systems automatically create indexes on unique constraints, providing performance benefits for queries using alternate key values.

Migration and Evolution Considerations

Alternate keys prove valuable during system migrations and business rule changes. When replacing legacy systems, alternate keys can maintain compatibility with existing integrations while new components use modern primary keys. This dual-key approach facilitates gradual migration without requiring simultaneous updates across all dependent systems.

When Should You Implement Composite Keys?

A composite key combines two or more columns to uniquely identify each record. When it's the primary identifier, we call it a composite primary key.

Example: Composite Key in Orders

‍

CREATE TABLE Orders (
 OrderID   INT NOT NULL,
 ProductID INT NOT NULL,
 Quantity  INT,
 PRIMARY KEY (OrderID, ProductID)   -- composite PK
);


Composite Key Design Patterns

Composite keys naturally represent many-to-many relationships and time-series data. In junction tables linking entities, composite keys often provide the most efficient identification method. Order line items, user permissions, and audit logs frequently benefit from composite key structures that reflect their inherent multi-dimensional nature.

Performance and Maintenance Trade-offs

Composite keys increase JOIN complexity and can complicate application code. Queries must specify all key components for optimal index utilization, and partial key searches may not leverage the primary index effectively. Additionally, schema evolution becomes more challenging when composite keys require modification, as changes cascade through all referencing foreign keys.

Modern Alternatives

Many modern applications prefer surrogate integer keys with unique constraints on natural composite attributes. This approach simplifies foreign key relationships while preserving business uniqueness requirements. The trade-off involves additional storage overhead balanced against simpler application logic and schema maintenance.

How Are Temporal Database Keys Revolutionizing Data Management?

Temporal databases represent a paradigm shift in data management by systematically incorporating time as a first-class entity. Unlike conventional databases that store only current state information, temporal databases maintain historical states through explicit timestamping, enabling accurate historical queries and audit trails.

Conceptual Foundations of Temporal Data Management

The temporal model distinguishes between three fundamental time dimensions: valid time (when a fact was true in reality), transaction time (when the fact was recorded in the database), and decision time (when the decision about the fact was made). Bitemporal implementations combine valid time and transaction time to provide comprehensive historical tracking capabilities.

SQL:2011 Standard and Key Implementation

The SQL:2011 standard introduced native temporal support through PERIOD definitions that create implicit time ranges without requiring schema modifications. This standard specifically addresses temporal key constraints through novel syntax extensions:

Temporal primary keys enforce entity integrity across time periods using PRIMARY KEY (...) WITHOUT OVERLAPS clauses, ensuring no two records with identical logical keys can have overlapping validity periods. For example, an employee database might implement:

ALTER TABLE Employees
ADD PRIMARY KEY (employee_id, PERIOD valid_time WITHOUT OVERLAPS);


This guarantees that an employee cannot hold two positions simultaneously during overlapping time intervals.

Temporal foreign keys maintain referential integrity across time through syntax like:

ALTER TABLE Departments
ADD FOREIGN KEY (dept_id, PERIOD valid_time)
REFERENCES Companies (company_id, PERIOD valid_time);


This ensures that department assignments always reference existing companies during corresponding validity periods, even when both entities have time-variant states.

PostgreSQL 18 Bitemporal Key Innovations

PostgreSQL 18's upcoming bitemporal key support represents a groundbreaking advancement in temporal database technology. This implementation enables simultaneous tracking of both system time (when data was recorded) and valid time (when the fact was true), using specialized syntax:

CREATE TABLE financial_records (
 record_id INTEGER,
 balance DECIMAL,
 valid_from TIMESTAMP,
 valid_until TIMESTAMP,
 system_time TIMESTAMPTZ GENERATED ALWAYS AS ROW START,
 PRIMARY KEY (record_id, PERIOD valid_time WITHOUT OVERLAPS)
);


This structure allows complex historical queries like "What did we believe the account balance was on June 1st, as recorded on June 5th?" – a capability particularly valuable for financial audits and regulatory compliance.

Real-World Applications and Benefits

Financial systems use bitemporal keys for accurate audit trails and transaction reconstruction, with major institutions implementing AI-driven anomaly detection atop temporal structures to reduce fraud investigation costs. Supply chain management leverages temporal foreign keys to track material provenance across ownership changes, while regulatory compliance in healthcare and finance benefits from temporal primary keys that automatically enforce data integrity across history, satisfying requirements like GDPR's "right to explanation" through built-in historical traceability.

What Modern Key Generation Techniques Address Distributed System Challenges?

Traditional key generation methods face significant challenges in modern distributed environments. Auto-increment integers create bottlenecks in distributed write scenarios and expose business logic through sequential identifiers. Random UUIDs solve distribution challenges but introduce storage inefficiency and indexing fragmentation due to non-sequential insertion patterns.

Limitations of Traditional Key Approaches

These limitations become particularly problematic in high-throughput systems where organizations observe substantial index bloat in UUID-keyed tables at scale. The fragmentation caused by random UUIDs can degrade write performance by forcing database systems to constantly reorganize index pages, creating overhead that scales poorly with data volume.

Lexicographically Sortable Identifiers

Modern key systems address these limitations through timestamp-prefixed designs that maintain global uniqueness while enabling efficient indexing:

ULIDs (Universally Unique Lexicographically Sortable Identifiers) combine a 48-bit timestamp with 80-bit randomness using Crockford Base32 encoding:

01H5Z24M2TS0V4F90K7R12AB3C
|----------| |----------------|
 Timestamp     Randomness


Key advantages include natural clustering as new inserts append to index tails, reducing fragmentation significantly compared to UUIDs. The implicit temporal information provides millisecond precision decodable from the first characters, while the human-readable format supports debugging without specialized tools.

KSUIDs (K-Sortable Unique IDs) offer similar properties with different encoding characteristics, demonstrating significantly faster batch insertion than UUIDv4 in distributed database benchmarks.

Snowflake IDs and Distributed Generation

Twitter's Snowflake ID architecture represents another approach optimized for distributed environments:

+-----------+----------------+------------------+
| Timestamp | Worker Node ID | Sequence Number  |
| (41 bits) | (10 bits)      | (12 bits)        |
+-----------+----------------+------------------+


This structure enables chronological ordering without centralized coordination, high-throughput generation capabilities, and compact storage compared to traditional UUIDs. Distributed systems benefit significantly from Snowflake's design, with major platforms handling millions of daily messages using modified Snowflake implementations.

Implementation Best Practices

Adopting modern key systems requires careful consideration of database-level generation to ensure consistency, as implemented in PostgreSQL extensions:

CREATE TABLE events (
 id TEXT PRIMARY KEY DEFAULT generate_ulid() NOT NULL
);


Key decoding integration enhances debugging capabilities by allowing implicit timestamp derivation without additional columns. Sharding considerations favor Snowflake-like systems when workload distribution is uneven, while ULIDs provide better cross-region coordination flexibility.

Performance Impact and Adoption Trends

Modern key systems demonstrate measurable operational improvements in insert throughput, index fragmentation reduction, and storage efficiency. Industry adoption reflects these advantages, with organizations using ULIDs as primary keys across all tables to eliminate secondary key mapping complexity, implementing Snowflake variants for distributed collaboration systems, and favoring KSUIDs for transaction IDs due to implicit timestamping benefits in dispute resolution processes.

What Advanced Key-Management Strategies Support Modern Data Systems?

Modern data systems require sophisticated key management approaches that extend beyond traditional relational concepts:

Vector Embedding Keys for AI-Driven Systems

Machine learning applications increasingly require similarity-based lookups using vector embeddings. These systems employ specialized indexing techniques like approximate nearest neighbor search, where traditional unique keys combine with high-dimensional vectors to enable AI-driven similarity searches across large datasets.

Dynamic Key Rotation and Lifecycle Management

Security frameworks now mandate automated key rotation to minimize exposure windows. Advanced systems implement ephemeral credentials with time-based validity periods, ensuring that compromised keys have limited impact duration. This approach requires coordination between application layers and key management systems to handle rotation without service disruption.

Envelope Encryption and Hierarchical Structures

Enterprise systems employ envelope encryption where Key Encryption Keys (KEKs) protect Data Encryption Keys (DEKs), creating hierarchical key structures that balance security with performance. This approach enables efficient key rotation by changing only the KEKs while preserving encrypted data structures.

Cloud-Native Integration Across Hybrid Environments

Modern key management systems integrate with cloud provider services like AWS KMS, Azure Key Vault, and Google Cloud KMS while supporting hybrid and multi-cloud deployments. This integration enables consistent key policies across diverse infrastructure while avoiding vendor lock-in through standards-based interfaces.

How Do Security Considerations Shape Modern Key Architecture?

Security concerns have evolved significantly with the rise of distributed systems, cloud computing, and sophisticated cyber threats:

Cryptographically Strong Key Generation

Modern systems require cryptographically secure random number generation for key creation, moving beyond simple pseudo-random approaches. Hardware security modules (HSMs) and trusted execution environments provide tamper-resistant key generation and storage capabilities that protect against both software and hardware-based attacks.

Automated Rotation and Lifecycle Management

Manual key rotation processes create security vulnerabilities through delayed updates and human error. Automated rotation systems monitor key age, usage patterns, and threat indicators to trigger rotation events without manual intervention. These systems coordinate across distributed components to ensure seamless transitions without service disruption.

Role-Based Access Control and Separation of Duties

Zero-trust security models require granular access controls where key management operations are restricted based on user roles and operational context. Separation of duties ensures that no single individual can compromise key security, requiring multiple approvals for sensitive operations like key export or algorithm changes.

Tamper-Evident Audit Logging and Real-Time Monitoring

Comprehensive audit trails track all key-related operations with immutable logging that prevents retroactive tampering. Real-time monitoring systems detect anomalous key usage patterns and trigger automated responses to potential security breaches. These capabilities support regulatory compliance and forensic analysis requirements.

Integration with Modern Security Frameworks

Key management systems integrate with broader security frameworks including Security Information and Event Management (SIEM) platforms, threat intelligence feeds, and incident response systems. This integration enables coordinated security responses that consider key management as part of comprehensive defense strategies.

Compliance Standards and Regulatory Requirements

Modern key management must support various compliance frameworks including GDPR, HIPAA, PCI-DSS, and SOX. These requirements mandate specific key handling procedures, audit capabilities, and data protection measures that influence architectural decisions and operational procedures.

How Can You Apply These Database Key Concepts Effectively?

You've now explored the most important types of keys including primary, foreign, candidate, alternate, composite, and super keys, along with emerging concepts like temporal keys and modern identifier systems. Understanding these key types and their appropriate applications is essential for building robust, performant database systems.

Key Selection Strategy

Choose primary keys based on stability, uniqueness, and performance characteristics. Consider surrogate keys for volatile business data while maintaining natural keys as alternate keys for business logic. Evaluate composite keys carefully against surrogate alternatives, weighing relationship expressiveness against complexity overhead.

Performance Optimization

Always index foreign keys to prevent JOIN performance degradation. Consider the impact of key choice on clustering and partitioning strategies in distributed systems. Modern identifier systems like ULIDs and Snowflake IDs can significantly improve write performance in high-throughput scenarios while maintaining global uniqueness.

Security and Compliance

Implement comprehensive key management strategies that support regulatory requirements and security best practices. Consider temporal key implementations for audit trail requirements and historical data analysis. Plan for key rotation and lifecycle management as integral parts of security architecture.

Modern Architecture Integration

Design key strategies that support cloud-native deployments, microservices architectures, and distributed data systems. Consider how key choices impact system scalability, maintainability, and evolution over time. Plan for migration scenarios where key strategies may need to change as business requirements evolve.

Mastering both foundational concepts and emerging techniques will help you build resilient, performant, and secure data systems that maintain integrity across today's distributed, cloud-native architectures. The evolution from traditional relational keys to modern temporal and distributed identifier systems reflects the changing demands of contemporary data management.

FAQs

How do I choose a database key?

Pick a column (or columns) that uniquely identifies each record, is never NULL, and rarely changes. Evaluate all candidate keys, then designate one as the primary key. Consider stability, performance implications, and business requirements when making this choice.

Why are keys needed in a database?

They guarantee uniqueness, prevent duplicates, maintain data integrity, and enable relationships among tables for efficient querying. Keys also support performance optimization through indexing and enable audit trails for compliance requirements.

Do all databases need a primary key?

Technically no, but a primary key is strongly recommended for uniqueness, performance, and referential integrity. Some database systems and replication technologies require primary keys for proper operation, making them essential in most production environments.

What is the difference between a primary key and a unique key?

Both enforce uniqueness; however, a primary key cannot be NULL and formally identifies each row, while a unique key can contain NULLs and may not be the table's main identifier. A table can have multiple unique keys but only one primary key.

Can a foreign key be null?

Yes. If the relationship is optional, the foreign-key column can be NULL, indicating no related parent record. This allows for scenarios where the relationship may not always exist, providing flexibility in data modeling while maintaining referential integrity when values are present.