Before moving on and modifying your basic application in the next chapter, you still have to load one final table to complete the initial loading of your data set. Before jumping into this task, you should consider the implications of the foreign key you created in the previous section.
For that foreign key constraint, the value in the ORDER_ID column for the ORDER_ITEMS pointed to the value in the primary key of the ORDERS table, ORDER_ID. But you might remember that this column was created automatically when you loaded the table from the spreadsheet. Why did the values in the ORDER_ITEMS column match the appropriate values in the ORDERS table?
Well, this data is sample data, specifically designed for demonstrations like the ones in the book. The values for the ORDER_ID in the ORDERS table were nicely created to be sequential from 1 to 11, and the values in the corresponding column in the ORDER_ITEMS table matched that simple scheme. In the real world, however, you probably won't be so lucky. In fact, a common task might involve breaking one spreadsheet up into more than one table, and loading the same column value into both tables involved in the foreign key restraint.
On one hand, this scenario is easy to deal with. When importing the table, you simply say that the value for the primary key is in an existing column. The issue arises with the use of a sequence to assign further values automatically. By default, the sequence defined as part of ...