Power) All queries are single threaded, so the core speed can be more important than the number of cores

Partitioning) MySQL partitioning only does partition elimination, and it doesn’t do it very well. MySQL 5.5 is supposed to make some improvements here.

Parallelism) In a single query, there is none.

I never suggest using a SAN for MySQL. SAN are great for shared-everything databases (RAC) but not for shared-nothing ones like MySQL. RAC has OCFS, a clustered filesystem designed to work with technology like SANS.

A star/snowflake schema always has one fact table, since by definition the schema is about one factual subject (like sales). There can be dimensions that are shared between different fact tables (puppet dimensions) like the date/time dimensions, perhaps lists of customers, etc.

A snowflake schema contains one or more normalized dimension tables, that is, the hierarchical information isn’t stored redundantly in a single table.

An example of a dimension in a star schema might be:

create table dim_product (
product_id int,
category_name char(10),
sub_category_name char(10),
base_price decimal(6,3)
)

but in a snowflake:
create table dim_product (
product_id int,
base_price decimal(6,3)
)

create table dim_product_category (
product_id int,
category_name char(10),
category_type enum(‘top’,'sub’)
)

#1
“A star schema is a selfish model, used by a department, because it’s already got aggregation in it.”

This sound like bollocks to me :)

While it is true that many people draw star schemas from a (more or less) 3NF normalized data warehouse as departmental data marts, aggregation is not an intrinsic property of star schemas at all. Aggregation may be added for performance reasons, but ideally the fact table has one row for the lowest possible level of interest – aggregation should be done as much as possible by the reporting and/or OLAP tool, so, at query time.

#2:
“Another schema-related topic I had a hard time putting into words before this workshop was the difference between a star and a snowflake schema: compared to a star schema, in a snowflake schema, you have more than one fact table and maybe some dimensions that are not used often.”

Star and snowflake schemas are both examples of a dimensional model. In a dimensional model, you have one fact table which contains columns for the metrics (aka measures), and columns that reference the dimension tables which provide the context for the metrics. While querying these dimensional models, the fact table is joined to one or more dimension tables, and the metric columns are typically aggregated, using several columns from the dimension tables for grouping. One datamart can contain multiple fact tables, and typically the fact tables in one datamart share (a number of) dimensions.

The difference between star and snowflakes is that in a star schema, each dimension is implemented in a single dimension table. The star schema dimension table is denormalized and contains all data for all levels of all hierarchies along which the dimension can be rolled up to get aggregated results from the fact table.

In a snowflake, you still have a single fact table, which still points to the dimension tables. The only difference is that in a snowflake, dimensions are implemented using multiple tables, typically a single dimension table is used at each level of each hierarchy of the dimension.

Example: an order line fact table will have a link to an order date dimension (among many others). The order date dimension should allow users to view the data in the fact table at different levels of time: year, quarter, month, day are examples of such levels; another example would be year, week, weekday.

Note that Y-Q-M-D and Y-W-D are two distinct an non-overlapping hierarchies of a single date dimension – two ways to partition time.

Now in a star schema, the date dimension would have columns for all levels of all hierarchies (Y, Q, M, day-in-month, W, day-in-week). This is necessarily a denormalized table because of the functional dependencies between the levels of the hierarchies.

In a snowflake, we would still have the same fact table, the only difference would be that each level of each hierarchy would get it’s own table. so, at the lowest leve of the dimension you’d have one day table. The day table would point to a day-in-week table for that level of the Y-W-d hierachy, and also to a month table for the Y-Q-M-d hierarchy)

So basically, both are dimensional models but in a snowflake the dimension tables are normalized (at least each level gets its own table).