nice

good

great

good

BIEN

Good

Good

good

good

good

good

Good

good

good

Good

Good

good

good

Eas

gd

ok

3

.

V

The lectures and weekly coursework were fine -- although a bit too easy. The emphasis on certain aspects, such as formatting/commenting, and some comments on joins were on point. Sadie has a soothing voice and good pace, although the content somewhat drags at places. Not her fault as a presenter, the videos were just going too slow imo. There were a few typos in the lecture slides, one of which was quite confusing (I have reported them separately).

Unfortunately what really stood out in a negative way was the peer-graded assignment. This *really* needs to be rewritten. Specific problems:

Part1

=====

Questions 5 to 7 could be answered in two different ways: one, which is the "easier" one and the one that the marking guide forced us to accept, is to read off review_count from the Business table (and descend-order it). The first few results this way are

+-----------------+---------+

| city | reviews |

+-----------------+---------+

| Las Vegas | 82854 |

| Phoenix | 34503 |

| Toronto | 24113 |

| Scottsdale | 20614 |

| Charlotte | 12523 |

| Henderson | 10871 |

+-----------------+---------+

The problem with this is that the data set we're working on is a SUBSET of the full Yelp set. This means that the Business.review_count column (which was presumably added there in a redundant, denormalized way, in order to speed up queries) contains much higher counts than the ones that would be obtained by actually joining the Business and Review tables (on business id) and grouping by city. Here are the first few results of this approach, which imo is the correct one:

+-----------------+---------+

| city | reviews |

+-----------------+---------+

| Las Vegas | 193 |

| Phoenix | 65 |

| Toronto | 51 |

| Scottsdale | 37 |

| Henderson | 30 |

| Tempe | 28 |

+-----------------+---------+

I would be totally ok if the marking guide gave us the choice to accept both methods, but that wasn't the case.

Part 2

======

Q1 of Part2 was badly worded and unclear. It asks us to "pick a city AND a category" but then to group the businesses (by star rating) "in that city OR category". What exactly does that mean? Lump together all businesses from eg Phoenix (regardless of category) with the eg Restaurants businesses (regardless of city)? What's the rationale behind this? Or was it meant to read "in that city AND category" (meaning that we would only consider restaurants from Phoenix)?

Also, Q1.iii is both random and vague: why location? What do you mean by location (zip code? longitude/latitude?). This ties to the above ambiguity (X=AND vs X=OR in "in that city X category").