>>We've had a general dispute in my team few years ago, on "each type of traffic into its table" vs "cram 'em into as few as possible, and try to have only one if you can". Since I'm the chief developer here, the other approach is taken - having more tables gives you more trouble in maintenance and reporting.
>
>I used to do this, Dragan, but switched to the 'every little table' after having trouble with SQL-Select code and reports that needed to use the same table for 3+ lookups.
>
>Your point about maintenance, however, is true - it's a balancing job....

The first FPD generation of this app used a single table per data data source table, per billing system. IOW, I started out with 7 copies of the same table! I do try to cram as much source data into as few as tables as possible, but when it comes to the output tables I follow standard data warehouses practices of denormalization and duplicating to get as much performance as I can milk out the environment.