FSP Wiki Setup + Feature List + Schema

[mwmadsen67]

Hi Jason, here is a checklist for going through tonight's homework and setting up your wiki. If it makes it easier for you, you can check these off while working through it, otherwise I will check them off when I review your docs tomorrow.

---

Wiki Page Home

• [x] Is the first page you see upon entering the wiki
• [x] Contains a welcome message
• [x] Contains a link/placeholder for a link to the live page
• [x] All links in the right sidebar should contain each wiki page and link to the correct page
• [x] Correctly formatted
  • [x] each wiki page is listed in bullet points
  • [x] all links route the correct page

---

Feature List

• [x] Should have 7 Features.
  • [x] 3 of those are User Auth, Render.io, and Production README.
  • [x] The other 4 are from the Feature List for approved apps or they have clarified them with you
• [x] Contains a description sentence of the app
• [x] Includes two to three detailed bullets on functionality and presentation of feature
• [x] At least one CRUD feature, which states what CRUD operations are planned (creation, reading, updating, deletion)
• [x] Estimates how long it will take the code each feature
• [x] Correctly formatted
  • [x] features are listed in an ordered list
  • [x] Each feature is broken down into bullet points

---

Database Schema

• [x] Contains correct datatypes
• [x] Contains appropriate constraints/details
  • [x] primary key
  • [x] not null
  • [x] unique
  • [x] indexed
  • [x] foreign key
• [x] Contains bullet points after the table that state which foreign keys will reference to which table, or references to the associations which will be made
  • [x] foreign key and table name are lowercased, snake_cased and back_ticked
• [x] Correctly formatted
  • [x] schema is written in a table format
  • [x] the table's name are lowercased, snake_cased and back_ticked
  • [x] the table header column names are bolded
  • [x] columns names are lowercased and snaked_cased and back_ticked

---

[mwmadsen67]

Alright I have looked through your docs and they're looking great so far. Your feature list is solid so I don't have any notes in that.

A couple minor notes/ questions on your schema:

• Do you need to have not null and unique on username? On the website itself I see a lot of "OpenTable Diner" which implies that sometimes users don't have a username. I also see a lot of short names like NikkiF or BillT which makes me think they don't need to be unique either. I wouldn't add the constraints if you don't need them.
• On restaurants, what is reservation interval and tables per time?
• For reservations, I think you should also include a number of people column. Also restaurant_id should be indexed
• For reports, restaurant_id should be indexed. Also, reservation_date_time_id seems like an odd column. There is no reservation_date_time column so I wouldn't make that an id or a foreign key.
• Also, on the site it looks like they have rating categories like "overall, food, service, ambience". You might want to separate those into 4 different rating columns.

I hope this feedback is helpful, nice work so far Jason!

[jason330]

Hi Mike!

Thanks so much for all your feedback! I've replied below each question:

Alright I have looked through your docs and they're looking great so far. Your feature list is solid so I don't have any notes in that.

A couple minor notes/ questions on your schema:

• Do you need to have not null and unique on username? On the website itself I see a lot of "OpenTable Diner" which implies that sometimes users don't have a username. I also see a lot of short names like NikkiF or BillT which makes me think they don't need to be unique either. I wouldn't add the constraints if you don't need them.

Thanks so much for catching this! Made the updates!

• On restaurants, what is reservation interval and tables per time?

I wasn't sure about the best way to keep track of table availability, so tentatively planned to compute availability instead of maintaining a database table. I figured that restaurants would provide their availability in terms of days of the week they're open ( days_open ) and open and close times ( opening_hour and closing_hour ), and if they also specify the time interval between reservations ( reservation_interval ) and the number of tables available per reservation time ( tables_per_time ), I would be able to compute availability to display to the user on demand. Do you foresee any problems with this or have suggestions for a better way?

• For reservations, I think you should also include a number of people column. Also restaurant_id should be indexed

Definitely, thanks for catching these!

• For reports, restaurant_id should be indexed. Also, reservation_date_time_id seems like an odd column. There is no reservation_date_time column so I wouldn't make that an id or a foreign key.

Added the index on restaurant_id , thanks! Yes I realized reservation_date_time_id seems not quite right; I initially had that column to enforce the constraint that each user can only post one review per reservation, and I was trying to get that reservation data from the reservations table. I changed that column to reservation_id. Let me know if you have any thoughts!

• Also, on the site it looks like they have rating categories like "overall, food, service, ambience". You might want to separate those into 4 different rating columns.

Added these, thanks for catching this as well!

I hope this feedback is helpful, nice work so far Jason!

[mwmadsen67]

In regards to table availability, I think your explanation makes sense. As long as you have a plan for making those reservations work I am all for it.

Nice job on making the rest of the changes!