Database Structure and User Roles for

DoveLinker
Overview
This document outlines the database structure necessary for the DoveLinker platform,
focusing on user roles, their permissions, and data requirements. This will serve as a
foundational resource for developers to implement the system efficiently.

User Roles
DoveLinker will have six key user roles, each with specific permissions and
responsibilities:

1. Riders (Dispatch Riders/Drivers)

a. Responsibilities:
i. Deliver items to users.
ii. Update their availability status.
iii. View and manage delivery requests.
b. Required Information:
i. Name
ii. Email

DOVE-LINKERS
 iii. Phone Number
iv. Home Address
v. Profile Image
vi. Vehicle Plate Number
vii. Associated Logistics Company
2. Normal Users (Customers)
a. Responsibilities:
i. Browse products from partner vendors.
ii. Place orders and make payments.
iii. Provide feedback and ratings.
b. Required Information:
i. Name
ii. Email
iii. Phone Number
iv. Delivery Address
v. Profile Image (optional)
3. Vendors (Partner Store Owners)
a. Responsibilities:
i. Manage product listings and inventory.
ii. Accept or reject incoming orders.
iii. View sales analytics and performance.
b. Required Information:
i. Store Name
ii. Contact Person
iii. Email
iv. Phone Number
v. Physical Store Address
vi. Profile Image
4. Workers (InStore Staff)
a. Responsibilities:
i. Assist in inventory management.
ii. Prepare orders for pickup by riders.
iii. Provide realtime updates on product availability.
b. Required Information:
i. Name
ii. Email
iii. Phone Number
iv. Assigned Store
5. Logistics Companies
a. Responsibilities:
i. Manage rider registrations.

DOVE-LINKERS
 ii. Validate rider details for security.
b. Required Information:
i. Company Name
ii. Contact Person
iii. Email
iv. Phone Number
v. Address
6. Admin (System Administrators)
a. Responsibilities:
i. Manage user accounts across all roles.
ii. Oversee platform operations.
iii. Generate reports and analytics.
b. Required Information:
i. Admin Name
ii. Email
iii. Phone Number
iv. User Role (Admin, Support, etc.)
v. Profile Image

DOVE-LINKERS
Database Structure

1. For the stores section

The database will include the following tables to manage the various user roles and
their interactions:

1. Users Table
a. Columns:
i. UserID (Primary Key, Unique Identifier)

DOVE-LINKERS
 ii. UserRole (e.g., Rider, User, Vendor, Worker, Logistics Company,
Admin)
iii. Name
iv. Email (Unique)
v. Phone Number
vi. Password (hashed for security)
vii. Profile Image (URL)
2. Products Table:
a. Columns:
i. ProductID (Primary Key)
ii. VendorID (Foreign Key linked to Users Table)
iii. Product Name
iv. Description
v. Price
vi. Available Quantity
vii. Image URL
3. Orders Table
a. Columns:
i. OrderID (Primary Key)
ii. UserID (Foreign Key linked to Users Table)
iii. ProductID (Foreign Key linked to Products Table)
iv. Quantity
v. Status (Pending, In Progress, Completed, Cancelled)
vi. Total Amount
vii. Delivery Address
viii. Created At (timestamp)
ix. Updated At (timestamp)
4. Rider Availability Table
a. Columns:
i. AvailabilityID (Primary Key)
ii. RiderID (Foreign Key linked to Users Table)
iii. AvailableStatus (Available, Unavailable)
iv. LastUpdated (timestamp)
5. Store Inventory Table
a. Columns:
i. InventoryID (Primary Key)
ii. VendorID (Foreign Key linked to Users Table)
iii. ProductID (Foreign Key linked to Products Table)
iv. Quantity Available
v. LastUpdated (timestamp)

DOVE-LINKERS
2. For the Find Riders section

1. User Ride Order History

a. Data Structure:
■ User ID: Unique identifier for the user.
■ Ride Order ID: Unique identifier for each ride.
■ PickUp Location: Where the ride started.
■ DropOff Location: Where the ride ended.
■ Date/Time: When the ride took place.
■ Amount Charged: Total cost for the ride.
■ Status: Completed, canceled, etc.
b. Functionality:
■ Users can view their past rides in chronological order.
■ Filters for date range and ride status can be included.
■ Option to rate the ride and provide feedback.
2. Driver/Rider Order Tracking:
a. Data Structure:
■ Driver ID: Unique identifier for the driver.
■ Total Rides Completed: Number of completed rides.
■ Total Earnings: Sum of all earnings from completed rides.
■ Ride History: Array of ride IDs linked to each ride's details (can
include routes, earnings per ride, etc.).
b. Functionality:
■ Drivers can view their performance metrics, including earnings and
completed rides.
■ Insights can be provided on peak riding times, popular routes, etc.
■ Option for drivers to respond to user feedback or view ratings.
3. Integration with Ride Matching
a. RealTime Updates:
■ Ensure that both user ride history and driver earnings are updated
in real time as orders are completed.
b. Dashboard View:
■ Create an intuitive dashboard for both users and drivers to access
their ride histories and statistics easily.
4. Notifications
a. Implement notifications for:
■ Users when their ride order is completed.
■ Drivers when a ride is accepted or completed, and earnings are
updated.

DOVE-LINKERS
 5. Privacy Considerations:
Ensure that personal information is protected and that any shared data complies
with privacy regulations.

By implementing these elements, we'll create a feature that not only tracks ride history
for users but also provides valuable insights for drivers, enhancing the overall user
experience on the "Find Riders" page. Focus on usability and clarity to ensure both
parties can efficiently access their respective data.

Explanation of Relationships
1. Users Collection: The Users collection contains all user information, including
different roles like Riders, Normal Users, Vendors, Workers, and Admins. Each
user document has fields like:
a. _id: A unique identifier for each user.
b. role: Specifies the user's role (e.g., vendor, rider).
c. name, email, phoneNumber, profileImage, etc.: Basic information about
the user.

Relationship: The vendorId field in the Products collection references the

corresponding user in the Users collection. This means each product can be tied
back to the vendor who owns it.

2. Products Collection: This collection specifically holds information related to the

products available for sale. Each product is linked to a vendor via the vendorId.
a. vendorId: This serves as a foreign key, pointing to the corresponding
document in the Users collection. This establishes which vendor is offering
the product.
3. Orders Collection: The Orders collection captures details about each order
placed by users. Each order will have:
a. userId: A reference to the user who placed the order, linking back to the
Users collection.
b. productId: A reference to the specific product being ordered, linking to
the Products collection.
4. Rider Availability Collection: This collection keeps track of the availability of
riders. Each document links back to a rider in the Users collection but isn’t
directly connected to product management or orders.
5. Store Inventory Collection: Though this collection is mentioned in the earlier
structure, it's less common in a NoSQL schema since products are typically
managed through their own collection. If we decide to keep the inventory tracking
separate for operational needs, each document can specify which products
belong to which vendor. However, we might instead simply rely on the Products
collection to manage inventory quantities.

DOVE-LINKERS
Summary of Relationships

● Users (all types, including Vendors) store user information.

● Products have a vendorId that references a user in the Users collection, linking
each product to its vendor/store.
● Orders reference both users and products using userId and productId, allowing
for easy access to order data, customer data, and product details.

Visualizing Relationships

● You can visualize these relationships as follows:

● Users Collection has many types of users (Riders, Vendors, etc.)
● Products Collection has a one-to-many relationship with Users (one vendor can
have many products).
● Orders Collection has a one-to-many relationship with both Users and Products
(one user can place many orders; one product can appear in many orders).

Other database structure option

The alternative to all of these is we have individual collection for every subject
and below are the advantages and disadvantages of that.

Whether we decide to use the db structure(single collection approach) outlined

above or not, to store all user types in a single collection or separate them into
multiple collections depends on the application's, complexity, and the trade-offs
you're willing to make. Here are some pros and cons of each approach:

Single Collection Approach

Pros:

1. Simplicity: Easier to manage and query users. All user-related data is in one
place, which can simplify operations like authentication and authorization.

DOVE-LINKERS
2. Uniformity: Easy to add new user roles or make changes to existing roles
without altering the database structure significantly.

3. Flexibility: Having one collection allows for a more dynamic schema where you
can easily adjust fields (using an `additionalData` field, for example) to
accommodate any user type.

4. Less Complexity: Fewer collections can lead to a simpler overall architecture,

reducing the overhead of managing multiple collections.

Cons:

1. Sparse Data: Different user types may have widely varying fields—this could
lead to many unused or null fields in documents, which can waste space and
complicate validation.

2. Performance: As the collection grows, queries might take longer due to the
varied structures and indexing might also become more complicated.

3. Difficulties in Validation: Enforcing validation for different user roles in a single

schema can become complex, particularly if there are many varying required
fields.

Multiple Collections Approach

Pros:

1. Specialization: Each collection can have a tailored schema specific to the user
type, which can result in clearer validation rules and better-organized data.

2. Performance: Collections can be optimized for the specific needs of each user
type, leading to potentially faster queries and more efficient indexing.

3. Simplified Management: Data can be managed and updated independently

without affecting other user types.

4. Cleaner Data Demographics: No sparse fields; each collection contains only

relevant fields for that user type.

DOVE-LINKERS
Cons:

1. Increased Complexity: More collections can lead to increased complexity in

relationships, requiring more sophisticated querying logic, especially for cross-
role operations.

2. Difficult Common Operations: Actions that need to involve multiple user types
(like pulling all users for a dashboard) might require more complex aggregations
or multiple queries.

3. Higher Overhead: If you need to introduce new user types, you would have to
create additional collections and potentially refactor parts of your application.

DOVE-LINKERS