You are designing a Windows Azure SQL Database for an order fulfillment system. You create a table named Sales.Orders with the following script. Each order is tracked by using one of the following…

Adding Status, PreviousStatus, and ChangeDate columns directly to Sales.Orders only stores one level of history (current and one previous status), which is a denormalized design that does not scale well and wastes storage if more history is ever needed.

Creating a separate Sales.OrderStatus table with columns for OrderID, Status, and ChangeDate is the most normalized and storage-efficient approach for tracking status history. This design allows multiple status records per order to capture the full history, and by querying the two most recent rows per OrderID, you can retrieve both the current and previous status along with the change date. A separate table avoids denormalization and scales cleanly without requiring schema changes as business requirements evolve.

Change Data Capture (CDC) is a heavy auditing mechanism designed for data replication and ETL scenarios, not for application-level status tracking; it incurs significant storage and processing overhead, violating the requirement to minimize storage.

Adding FulfilledDate, ShippedDate, and ReceivedDate columns stores dates but not a flexible status field, requires schema changes for new statuses, and does not directly provide the previous status without complex logic, making it less efficient and less maintainable.