Tag Info

New answers tagged

0

A two-tier fact table is usually more trouble than it's worth. That's your OLTP instinct to normalize kicking in - fight it! It took me several months to get my head around the warehouse/star schema paradigm. All that invoice header information can be tucked into a couple of extra dimensions. This will just add a couple of INT columns to your fact table, ...


0

You haven't given a lot of details, but on the face I'd say make it a new fact table. It sounds like your cohorts will be entirely distinct, so it wouldn't be meaningful to total or average across both sets. Your records won't have any overlap in dimensions (except Date, which is almost universal), so they're really distinct things, they just happen to ...


1

Generally, downstream tools will reference your data in some kind of intermediate form, like SSAS cubes, QlikView QVD files, or simply CSV. But if your downstream tool is hitting the database directly, you can simply create a series of views, one for each roleplaying dimension. Each can be defined as SELECT * FROM Dates. Have Tableau and Excel reference ...


1

Change tracking offers the functionality you're looking for. When switched on, SQL Server creates additional internal tables. Changes to your data tables are noted in these internal tables. System functions allow you to pull changes out of these internal tables and transfer only changed rows. A related technology - Change Data Capture - allows you to see ...


3

Generally, I've seen these intermediate levels referred to by the "grain" of the aggregation at which the data is stored. For example, if you have an intermediate aggregation in which the data is stored at the level of a person for a day, we would call that the person-day grain. This can be applied generically throughout most schemas.


0

I edited the Query to the following: EXPLAIN UPDATE jobcontrol.actual_values a JOIN jobcontrol.processing p ON a.para_id = p.para_id SET a.value = (select p.value from jobcontrol.processing p WHERE a.para_id = p.para_id ORDER BY t_ns DESC LIMIT 1) The JOIN ON makes the recordset smaller (DB checks only the parameters which are also in ...


1

If at all possible, I would allocate the shipping cost to line items. This would let you assess the actual cost and profit for individual products as accurately as possible. If this is not possible, I second @Jamie's idea of making Shipping a special type of "product." This is discussed by Kimball in The Data Warehouse Toolkit (third edition), page 185, ...



Top 50 recent answers are included