The PDF is now available, thanks for pointing this out.
thanks for dedicating a chapter to this topic. Here a few comments:
- Paragraph 3: It says "parameter that is used as the hash value for the partition". I am not sure where this chapter is placed and if at this point the definition of what a "hash value for a partition" has been given. In addition, I am not sure if mentioning "hash value" is actually necessary at this point.
- Paragraph 4: It says "other partitioned tables that are partitioned on the same hash value" in italics. At this point the definition of hash value is actually necessary. I think I remember that columns of the same type are hashed in the same way so that a value in that column from two tables result in the same has value. But this is not clear from this discussion here. At this point I would explain a lot more and possibly draw a pictorial representation of two tables that are in that situation.
- Back to Paragraph 3: It says "both the partitioning table and column and the parameter that is used as the hash value for the partition". Here it might be important to say that different columns of the same table can be used as hash value in different stored procedures to avoid the impression that it must be the same column across all stored procedures. Or must it be because of the project definition? From there it seems that it must be the same column. And what happens if there can be several project definitions for the same tables? What I try to point out here is that there are dependencies across all these that you might want to make very explicit (and possibly the fact that the partition column does not have to be the primary key).
- Bullet 3: It says "The two tables are partitioned on the same column (in this case, FLIGHTID)". I had the impression that the constraint is that the join columns are of the same data type (i.e. same hash values), not necessarily have the same column name?
- After the bullets: It says "However, the RESERVATION table cannot be joined with the CUSTOMER table in a single-partitioned stored procedure because the two tables use different partitioning columns. (CUSTOMER is partitioned on the
CUSTOMERID column.)". Now semantically it does not make sense to join with flightid = customerid at all. However, from a mechanics viewpoint, since both columns have the same data type, the join is correct in the sense from above, i.e., they have the same hash values.
- Not sure if you want to also discuss other operators in addition to "=" in this chapter, like "!=", "<", etc.