Create schema proposals in the wiki

[duci9y]

In our wiki, create a page title 'Schema proposals'. Within this, talk about how our database will look like using text, diagrams and/or code, however you feel is best.

Specifically:

• Account for different kinds of things we may store in the database. Users, equipment item, an equipment request, etc.
• For each of these, talk about what attributes we may need to store about that kind of thing. For example, an equipment may have an 'availability' attribute, name, etc.
• Make sure you are keeping your options open. Talk about alternatives whenever possible.

Feel free to talk to @duci9y while working on this ticket.

[thedaysob]

These are some of the class and interfaces that I thought of. It's written in typescript syntax. Let me know what you think!

class User { // Basic user definition userID: string; // Tufts ID? firstName: string; lastName: string; email: string; birthday: string;

// User relationship with equipments borrowedItem: Array; requestedITem: Array;

// Misc. projects: Array; }

interface Project { name: string; members: Array; }

class Admin { admiID: string; firstName: string; lastName: string; email: string; }

class Equipment { // Basic equipment info equipmentID: string; available: boolean; name: string; description: string;

// image: ImageBitmap;

// Filter by schedule: Array; // Array of 1~365 representing the available rental days in the year category: Category; }

interface EquipmentRequest { requestID: string;

user: User; project: string;

equipment: Equipment; checkOut: Date; checkIn: Date; pickUpTime: string; }

interface EquipmentCancel { cancelID: string;

equipmentRequest: EquipmentRequest; }

interface EquipmentConfirm { confirmID: string;

equipmentRequest: EquipmentRequest; // user: User; // project: string;

// equipment: Equipment; // checkOut: Date; // checkIn: Date; // pickUpTime: string; }

interface LogInForm { username: string; password: string; }

interface Category { // Dictionary of all the category? // Something to hold categories of the equipments }

[Frama-99]

This looks great! A few ideas to add:

• TUTV often has multiple of the same equipment. For each equipment, we could have a "count" variable that keeps track of how many pieces of the same equipment we have. This would also mean that the availability would be an array of boolean values.
• Perhaps the user class and the admin class could be merged, and there can be a field called "User type" or "privilege" that specifies the type of user a person is. This way we can also solve the problem of what to do when an admin member wants to borrow equipment. This would also make it easier for the admins to do things like modifying a user's privileges
• Rather than having an Equipment cancel interface, we could have a "status" variable in the EquipmentRequest class that specifies whether if a request is pending (i.e. haven't been taken out yet), open (i.e. taken out but not returned), returned, or canceled.
• We will likely need some way to determine availability with the precision of the hour, since at busy times a piece of equipment could be returned in the morning and taken out again in the afternoon. It might make more sense to keep track of when a piece of equipment is unavailable, rather than a long array with all possible availability times.

[controversial]

Here's a wiki page which includes an outline of some database schema details that we discussed during hack night tonight.