Skip to main content

Database Design

Database designs provide the blueprints of how the data is going to be stored in a system. 

Database design is a vital component of any app, and it determines what data to be stored and how the different data elements interact. A proper database affects the overall performance of an application. We're using a Firebase Database for our app. We prefer Firebase over SQLite since this is a multi-user app and FireBase is preferred over SQLite for Multi-User Apps. 

Google Firebase is Google-backed application development software that allows developers to develop Android, IOS, and Web apps. It can be used for user authentication and to host a real-time database. The database design for our app is given below.


The root node of our Database is Users, which branches into two children i.e. Customer and Vendor.
We store all the information corresponding to the customer using the Customer's Mobile Number as the Key, and for vendor, we store all the information using the OutletName as the key. 
Under the Customer subtree, it has three children, namely, Cart, UserData, and the TransactionHistory. 

1) Cart

The Cart will store the list of items in the cart of the customer.  Every child in the cart will have four children, namely
  • Name of the Item
  • Price of the Item
  • URL of the picture 
  • Quantity of the item
We access this node when we want to display the list of items in the cart. When the user placed the order all the items in the cart are deleted. 

2) User_Data

Under this, we store all the information pertaining to the user. This child is common for both Customers and Vendors. Every child in the User Data will have four children, namely
  • Email
  • Password
  • PhoneNumber
  • Username (Name of the Customer / Outlet Name)
We access this node during Login and Registration and also for displaying the Customer Profile.

3) Transaction_History_Customer

Under this we store information regarding all the orders placed by the customer. Every child in this node will have 
  • Amount of the Transaction
  • The outlet from which they purchased
  • Transaction ID
We access this node to display the Transaction History of the Customer

4) Menu

Under this node, we store the menus of the individual outlets. Every child in this node will have 
  • Name of the item
  • Price of the item
  • URL of the item
We access this node to display the menu to the vendor and also to the customer.

5) Transaction_History_Vendor

Under this we store information regarding all the orders received by the outlet. Every child in this node will have 
  • Amount of the Transaction
  • Phone Number of the customer
  • Transaction ID
We access this node to display the Transaction History of the Vendor





Comments

Popular posts from this blog

What is Diner2Door?

There are a good number of food outlets in BITS Pilani Hyderabad Campus and they are very popular among students. This in turn results in high waiting time for customers. Also, this leads to decreased revenue for outlets since people choose not to utilize the outlets due to the long waiting time. Our Solution? Diner2Door is an app created to solve this problem. The users can order from their favorite outlets using our app from the convenience of their own rooms. We made two separate pages for both the vendor and the customer where the vendor can change the menu based on availability and the customer can choose their favorite outlet and order food from their rooms.

General Features

This page talks about the standard features of both Vendor and Customer: When the application is launched, Main Activity sends an intent to the Splash Activity, which displays the App Logo for 2000 milliseconds, from where the control comes back to the Main Activity.  The app splash screen is the brief introductory screen that appears as the app loads after the user has just opened the app. Registration:   New users can register by entering their information. Their account gets created upon submitting the registration form.  The new user fills out their e-mail ID, mobile number, and Password. They will select the type of user in a spinner. If the type of user is a vendor, they have to add a URL of the picture of their food outlet. Then on clicking register, a new account is created. Login: Users can log in using their Username. The user is directed to the Login Activity for authentication. The User first selects what type of user (i.e., Customer or Vendor) in the Spinner on the Login p

App Features(Customer)

Here, we talk about the Customer's side of the app: The customer Homepage contains a fragment that displays the corresponding layout of the item clicked in the sidebar. As soon as the customer is logged in OutletList Fragment is called which displays the list of outlets present, where clicking on a particular outlet, will take them to the particular menu of the outlet. We've used Firebase UI in all fragments. Firebase UI is a class provided by Firebase SDK to make a query in the database to fetch appropriate data. Based on the customer's requirements and usability, we have developed an exclusive set of fragments. OutletList: This fragment will be called after the user is logged in. It will consist of a list of eateries that are open at any given time. It contains a recycler view, which populates itself using outletList_adapter by querying the List of Vendors in the Database using Firebase UI.  OutletMenu: On selecting one of the outlets, this fragment is called which di