By removing the total price column, we could encounter a pitfall. We have to be sure that we can reconstruct this total price from other sub-total elements, now and in the future. This might not be possible for a number of reasons: The total price includes an amount located in another table, and this table will change over time (for example, the tax rate). To avoid this problem, see the recommendations in the Scalability over Time section in Chapter 4. This total price contains an arbitrary value, due to some exceptional cases, for example, where there is a special sale, and the rebate was not planned in the system, or when the lucky buyer is the brother-in-law of the general manager! In this case, a decision can be made: adding a new column other_rebate. Data as a Column’s or Table’s Name Now is the time to uncover what is perhaps the least known of the data naming problems: data hidden in a column’s or even a table’s name. We had one example of this in Chapter 1. Remember the qty_2006_1 column name. Although this is a commonly seen mistake, it’s a mistake nonetheless. We clearly have two ideas here, the quantity and the date. Of course, to be able to use just two columns, some work will have to be done regarding the keys this is covered in Chapter 4. For now, we should just use elements like quantity and date in our elements list, avoiding representing data in a column’s name. To find those problematic cases in our model, a possible method is to look for numbers. Column names like address1, address2 or phone1, phone2 should look suspicious. Now, have a look in Chapter 2 at the data elements we got from our store assistant. Can you find a case of data being hidden in a column name? If you have done this exercise, you might have found many past participles hidden into the column names, like ordered, arrived, and washed. These describe the events that happen to a car. We could try to anticipate all possible events but it might prove impossible. Who knows when a new column car_provided_with_big_ribbon will be needed? Such events, if treated as distinct column names, must be addressed by A change in the data structure A change in the code (UI and reports) To stay flexible and avoid the wide-table syndrome, we need two tables: car_event and event.
Note: In case you are looking for affordable webhost to host and run your web application check Vision cheap hosting services