I am beginning to grasp the difference in "quick and dirty" data modelling and proper data modelling.
Working with a sales database scenario, am I right in assuming that proper data modelling would include, for example, tables to allow multiple address for customers etc and tables to allow multiple prices for items? And that these would be indexed by a composite key that would include the date to protect against duplicates? For pricing, I fully understand the concept of derived data but if a company wishes to keep a record of product pricing (which is clearly very valuable when it comes to business/data analysis), then it would require a static price history. So the price for a certain item would be derived from a junction table with a unique composite index of date+item ID? Would that be correct? And I would imagine you would have some kind of yes/no field in price table to state whether or not that was the active price and use this as a default, allowing users access to inactive prices but warn them before doing so (in case of backfill exercises)?