Database and data schema of Places RFC

[Alejandrocuartas]

In this RFC we expose clearly and briefly the database to use, the data schema and the flows for accesing to it.
This is the PR.
@Omarsan-av @JoaquinAprendizaje

[emanuelalvaradog]

Hi Alejandro. Talking with @gh0stl1m about the way the geolocation data will be saved, places team should notify geolocation team via the API with the information of the new place created. In that case I guess you don't have to save latitude and latitude at all and just send it to us via the API

[Alejandrocuartas]

Hi, Emmanuel. Could you tell me how it is supposed to be, please?

[emanuelalvaradog]

Sure. Whenever you receive a new place to be registered, the location data should be sent via our API for us to register it.

[Alejandrocuartas]

Thanks a lot @emanuelalvaradog! I already read the your squad's database RFC and understood the flow.

[Alejandrocuartas]

We already updated the RFC @emanuelalvaradog.

[gh0stl1m]

@Alejandrocuartas congratulations for the good work in the RFC it is well explained and extra points for the sequence diagrams that you created because they clarify better the workflows.
The design of the database is good but there are a couple of things that we should bear on mind:

1. What's the difference between the id and the place_id in the places table?
2. How is the geolocation be stored? do we need to have just the longitude and latitude or should we have something else? does make sense to store the geolocation or should we delegate this to the geolocation team? if does what information should we store?

Seems that you choose MySQL over PostgreSQL but in the RFC is not explained the reason of why this decision was taken, so would be great if we add more details around the reason of why MySQL is better than progress for our business case.

Good job folks, let me know if you have any doubt.

[Alejandrocuartas]

Thanks a lot, @gh0stl1m!!

About the first question, in the places table there is not an 'places_id' atribute. There is only the 'id' atribute. 'places_id' atribute is only for referencing a single place in other tables, its a foreign key.

About the geolocation store we are already talking to Geo squad and will do new commits to the RFC.

We are also gonna explain better why we choose MySQL over PostgreSQL.

[Alejandrocuartas]

We already updated the RFC, @gh0stl1m.

[Edilberto-Vazquez]

I made a diagram to better understand what the flow is like when creating a place. This diagram includes both places and geolocation in this RFC #29, If you have any questions or suggestions about geolocation RFC endpoints, please let me know via Slack @edilberto Vazquez Luna [C9] or here #32

[YaelRmz]

Hi! I'm from Data Monitoring team. We saw that you use a Reviews table but, this information is domain for Booking or yours?

[Alejandrocuartas]

Hello, @YaelRmz.
Yes, it is ours. Actually the reviews is a feature that my team and i agreed to implement, but it is not in the requirements document.