Maquetar e Implementar DB

[v1siond]

From @v1siond on January 19, 2017 14:33

La DB es la base del proyecto, es lo que va a crear el enlace front-end backend, por lo que debe ser lo primero en hacerse junto con los diseños; No es necesario tener TODA la DB lista antes de empezar a programar, pero si las tablas principales para los procesos básicos como registrar, cargar y mostrar clientes, deliverys y empresas.

Originalmente pensamos en las siguientes tablas básicas:

• [x] Empresa -> información de la empresa
• [x] Menú -> Menú de la empresa
• [x] Cliente -> información del cliente
• [x] Delivery -> información del delivery
• [x] Orden -> tabla que relaciona todos los anteriores.

Copied from original issue: loldlm1/AppDelivery#1

[v1siond]

From @loldlm1 on January 20, 2017 4:13

Version 1 para el modelado de la Base de Datos DeliveryApp:

     User model
# - Name : string
# - Email : string
# - Password : string
# - Api_token : string
# - Address : string
# - Role : integer / La verdad no se si esto sea necesario, un usuario puede trabajar y tambien comprar cierto? 

User has many Companies
User has many Orders
User has many Deliveries, through Orders

     Company model
# - Name : string
# - Address : string
# - Restaurant_type : string
# - Description : string

Company belongs to User
Company has many Menus
Company has many Orders
Company has many Deliveries, through Orders

     Menu model
# - Name : string
# - Price : integer
# - Description : string
# - Image : file 
# - Time : integer? 

Menu belongs to Order
Menu belongs to Company

     Delivery model
# - Accepted : boolean
# - delivered : boolean
# - refused : boolean
# - description : string

Delivery belongs to Order

     Order model 
# - invoice : integer / Seria necesaria un ID especial para la orden no? 

Order has one Delivery
Delivery belongs to Company
Delivery belongs to User
Order has many Menus

Esto funcionaria de esta manera:

• Un usuario podria registrar mas de un restaurante, por lo que tendria un rol de Administrador, tambien tiene muchas ordenes y envios mendiate las ordenes, supongo que habria que crear una modalidad en la que el usuario elija de ser un cliente a un trabajador y solo en este modo le lleguen las notificaciones de cada orden que se hace, del resto no.
• La compañia le pertenece a un usuario y tiene muchos menus, ordenes y envios mediante las ordenes
• El menu le pertenece a la compañia y tambien a la orden
• El envio le pertenece a la orden y por lo campos que describi, puede ser aceptada, rechazada, entregada y una descripcion que la coloca el usuario, de manera positiva o negativa al que hizo la entrega o a la compañia por su comida.
• La orden en efecto, relaciona a todos y seria un envio por orden, pero aqui hay un detalle, una orden podria enviar varios Menus?

Cualquier cosa puede cambiar, si desean añadir un campo faltante o aportar ideas para el mejor funcionamiento de la DB estaria genial.

[v1siond]

User model

 Role : integer 

si es necesario, ya que el rol define las notificaciones que le llegan.

Company model

 Company belongs to User

no estoy seguro de esta relación, tal vez es porque veo al usuario y a la compañía como registros diferentes, donde sería una relación de m to n?

Menu model

 Price : integer

cambiemos esto a float, la mayoría de los precios no son exactos y aunque lo fueran, siempre se toma en cuenta la propina y demás en los cálculos.

 Time : integer? 

definamos esta date_time y le asignamos current_time_stamp para no tener que preocuparnos por verificar formatos de fecha.

Todo lo demás me parece bien :D

[loldlm1]

User model

• Bien entonces, nos quedamos con el Role : integer o en todo caso he estado pensando y para manejar mejor las cosas, un ID especial para un usuario y ID especial para el trabajador, esos serian campos en el mismo modelo, pero serian como si estuviera con una tabla relacionado, que opinas? Asi tendria un ID exacto del comprador y ID exacto del que hizo el envio, o podria no ser necesario?

Company model

• La relacion la hice pensando en que cuando un usario se registre pueda tener una o varias empresas y el las maneje, pero tu crees que seria mejor que Company sea un registro aparte de los usuarios totalmente, la verdad lo veo bien, lo hacemos asi y vemos si nos parece bien mas adelante

Menu model

• Estoy de acuerdo y tienes razon, integer : float
• el Time : date_time este seria el tiempo en que se hace la entrega verdad? Es necesario un date_time? no recuerdo como seria un current_time_stamp :S

[v1siond]

User model

• Me parece bien, de esa manera podemos manejar mejor el rol

Company Model

• Entiendo lo del usuario manejando varias empresas, cosa que está muy bien, pero no te complicará las cosas a la hora de definir las opciones del dashboard para cada tipo de usuario?
• Yo lo había pensado de manera tal que fuera algo como if user delivery, X opciones, if empresa, X opciones else, X opciones.
• Ojo, si ya has manejado ese tipo de relación antes y crees que funcionará bien y no tendrá complicaciones con el dash ni nada, dale play, we trust you ;)

Menu model

• El time definido en date_time básicamente lo limita a este formado xx-xx-xxxx donde el primero es días, el segundo mes y el último año y el current_time_stamp lo que hará será tomar el tiempo del dispositivo y guardarlo, es decir, si se hace una orden y la máquina tiene de hora 8:00pm y fecha 01/05/2017, guardará eso. No sé si piensas que es mejor definirlo de otra manera y manejar eso con una función

[loldlm1]

Perfecto, quedamos asi entonces con el modelado, sin cambios para el Company Model, el Menu Model con un DateTime y el User Model con ID_worker y ID_customer. Por los momentos esta es la version final del comienzo del proyecto, luego se le añadiran las cosas que hagan falta sobre la marcha :)