and 45 times as many lines of code, respectively, as the equivalent simple SQL statements that use the new DB2 temporal features (see Figure 1 ). Furthermore, it took less than an hour to develop and test these few DB2 SQL statements. By contrast, the homegrown approaches required four to five weeks to code and test, and both provided only a subset of the temporal data management support built into DB2. Indeed, the homegrown logic didn't address system time, bitemporal data, views, and many other DB2 features. Thus, providing truly equivalent temporal data support through a homegrown implementation would likely take months. This is much longer than it would take to simply write the appropriate DB2 SQL statements, which we'll discuss shortly. To help you understand the temporal data management support in DB2, we use a common application scenario and sample data. The scenario involves car insurance policies, which we've represented in a single table for simplicity. The table tracks a subset of typical information associated with such policies: a policy identifier (ID), vehicle identification number (VIN), estimated annual vehicle mileage, whether a rental car will be provided if the car needs repair as a result of a claim, and the coverage amount (including accidental property damage, medical expenses, etc). Table 1 illustrates the basic structure of the POLICY table without any temporal support. The support in DB2 for system time enables you to automatically track and manage multiple versions of your data. By defining a table with a system