Design Docs Review #1 - MVP List & Schema

[mmcnulty20]

Good work on design docs so far, here's some changes that I'd like to see reflected going forward:

MVP List

• [x] Add length of time intended to spend on each MVP (rather than just "due dates")
• [x] Demo User should be included in New Account Creation MVP
• [x] Break Create and Search out into separate MVPs
• [x] Not just any user can create a restaurant: that requires a specific business account and more information. If you wish to provide restaurant creation functionality, keep that in mind!
• [x] What does "available now" mean in terms of the search functionality? Can we also check available later?
• [x] Users also search based on location - how can you incorporate location into search and display for restaurants?
• [x] What information about restaurants does a user see from a search? Are they able to find more info? How?
• [x] Where can a user view their reservations (Reservations should have full CRUD functionality, which includes Read)
• [x] Where are ratings/reviews submitted? Displayed? Can they be edited or deleted?
• [x] Does making a review require a user to be logged in? What about viewing one? Does it require a user to have a past reservation at that location?
• [ ] What functionality to the website does the ability to favorite a restaurant add? Where would these be seen?

  Schema

• [x] Minor, but table names in the schema should be lowercase
• [x] Website asks for a first and last name when signing up, rather than a username. It does also provide the ability to set a username for reviews. Reflect this in your users table.
• [x] Website asks to set a "primary dining location" when signing up
• [x] If you wish users to have the ability to create restaurants, how do you distinguish between business accounts and normal accounts?
• [x] All tables should have created_at and updated_at columns.
• [ ] If the owner of a restaurant is not a user, how would that be handled?
• [x] The ($, $$, $$$) is listed after cuisine but is probably intended as the valid options for price
• [x] Can each restaurant only have one cuisine type? How would deviations from this be reflected?
• [x] Addresses should be more specific than just city and state
• [x] Might want to include a lot more information for a restaurant, like capacity, hours, etc
• [x] You shouldn't need the reservation_id combined with the user_id and restaurant_id for reviews: that's duplicating information you could pull from associations.
• [x] Note all foreign keys as being foreign keys.
• [x] Note where something might be unique in a certain scope
• [ ] Need a favorites table for favorites MVP

[mmcnulty20]

Schema

• [ ] Probably still want to have a username on the schema as WELL as the first/last name for review display (optional - let me know)
• [ ] Do not store previous reservations as an array on your users. You should be able to write a previous_reservations association on the model utilizing the reservations table and the date on it compared against the current date.
• [ ] Users no longer have the ability to own restaurants, so the owner_id wouldn't be necessary on the restaurant table.
• [ ] Don't store arrays on the schema. Instead, make a separate "Cuisines" table with possible cuisines, then have a joins table to join cuisines and restaurants.
• [ ] Probably also want to store latitude and longitude on the restaurants table for ease of using google maps API
• [ ] Do not store images on the Restaurants table in the schema - we'll be using AWS
• [ ] Do not store hours as an array - I'd recommend factoring hours out into a separate table, but we can talk about options for hours in a 1-on-1
• [ ] Do not store reservations on the restaurants table. They're accessible via the has_many/belongs_to association
• [ ] reservation_id should be unique on the reviews table if a user can't leave more than one review for a single restaurant reservation (if a user can't leave more than one review on a restaurant at all, send me a slack and we'll discuss)