I creating a database for booking system.
Lets consume the following:
Hotel has 20 rooms with the same design, photos, price
So i have an entity like this:
Room:
ID
Hotel_ID
Price
Quantity
How should i perform booking ?
If i consider all the 20 rooms as differ objects, everything is simple:
Room:
RoomID
Status
Price
Quantity
Booking:
BookingID
UserID
RoomID
With the second one approuch administrator has to do much more job and also i have data duplication.
Also i am curios about how to this with the first one approuch.
You could create a third table named 'room-type' or something similar and save there the price, photos, desing, etc.
Then you can create a relation with this table and the room table (where you store 10 records with the ID of each room) so there's not duplicated data and finally make a relation between the room and the booking table.
Related
I have a system that lets members rent equipment and the system should have a history of each item that was rented and by who. The system should also track who has what equipment rented/checked out and should also sort the equipment by type, status, name, etc. Lastly it should also send out notification email on equipment that are overdue.
I'm trying to understand the relationships and how I should model this. As of now my current tables and thinking is something like this:
Member Table:
Id (PK)
MemberId
FirstName
LastName
Email
EquipmentItem Table:
Id (PK)
EquipmentName
EquipmentType (FK)
EquipmentStatus (FK)
TotalQuantity
RemainingQuantity
EquipmentStatus Table:
Id (PK)
StatusName
EquipmentType Table:
Id (PK)
TypeName
EquipmentRentalHistory Table:
Id (PK)
MemberId (FK)
EquipmentId (FK)
CheckOutDate
ReturnedDate
1) I want to know the relationships between these would the rental history be a many to many relationship between the Member table and EquipmentItem table?
2) Would EquipmentItem table have a one to many relationship between the status and type, the way I see it is EquipmentItems can have many statuses or types but each status or each type can only belong to one EquipmentItem.
3) Does it make sense to have a quantity field in the EquipmentItem, I used to work in a grocery store so I'm basing the logic on barcodes where same products would usually have the same barcode e.g. (Cheetos Puff chips) all Cheetos Puff chips would have the same barcode but would have a quantity value on it. Or would it be better to have each item unique regardless if it's the same product/model?
My logic would be:
member rents out item
system logs it into the history table
system then checks how many of the same item has been checked out so far, if say we have total quantity of 4 on that item and 3 members has checked it out
we update the remaining quantity field to the difference so in this case to 1
system can then track who has what checked out by returning all records with a returned date of null
system will then check all records with a returned date of null and then do a date range on the checked out date to determine if the equipment is overdue
send notification to member emails associated with said records from step 6
I would just like some help better understanding the relationship between these and if I have modelled my tables correctly, if not, it would be great if someone can point me in the right direction of improving upon this.
To answer your questions
With respect to modelling in an ERD, I don't think that qualifies as a many-to-many relationship, but rather, EquipmentRentalHistory is its own entity that has a many-to-many relationship with both Member and EquipmentItem.
A many-to-many would be more like, "a Member has access to 0...n EquipmentItems, and each EquipmentItem can be accessed by 0...n Members".
I would disagree that they are a one-to-many relationships.
An oxygen tank and a pair of flippers can both be classified as 'Scuba Gear' and have the status 'Checked Out'.
You could have multiple 'Scuba Gear' tags and assign each unique 'Scuba Gear' tag to its very own EquipmentItem, but then you'll just be creating new tags for every new EquipmentItem, rather than reusing existing ones.
That really depends on whether you want to identify exactly which piece of equipment a member rented (maybe something is damaged you can track down everyone who rented that specific one?). If you do differentiate, then every item will just be its own row. You should also add a new column as an external identifier, but there would be no need to keep a tally.
If it's all the same to you, then I would only keep the total but not the available. If you kept the available column, then you would constantly have to update it whenever something is logged in EquipmentRentalHistory. This would be annoying if the tables fall out of sync. You could just query EquipmentRentalHistory for the Id of the equipment, and count up the entries where returnedDate IS NULL for the number of equipment that is currently in use
Additional Note
It might be good to have a 'due date' column in the rental history rather than hard code the date calculation in case you want to varying due dates. This way you can also grant extensions.
I'm currently developing a web app on a travel & tourism website. What I'm willing to do is to allow the user to register himself to be able to book a tour for himself and/or family members. The 'family members' need not to register themselves. And the user should be able to cancel any member/himself from the booking. The tables I've designed so far are:
users
id,
name,
password,
email,
phone,
level (to distinguish between user & admin),
dob (date of birth),
status (active or blocked)
tours
id,
title,
short_desc,
start_date,
end_date,
max_passenger_capacity,
fees,
published (boolean),
long_desc
passengers (for additional passengers who are not registered)
id (PK),
user_id (FK from users),
name,
age,
sex,
status
wallets (where users can deposit money and pay from)
id (PK),
user_id (FK from users),
date_time,
narration,
ref_no,
withdraw (float),
deposit (float)
Now I intend to create an invoice table (id, date, user_id etc.), invoice_items table (id, invoice_id, etc. with reference to who is booking which tour for whom), passengers_booked table (id, tour_id, passenger_id etc. to keep track of which passenger is opting which tour).
The user should be able to cancel all the members from a tour or any member from the tour. In the later case an invoice should be raised quoting any refund and the other members should stay opted for the tour.
And how should manage the condition when the user is opting a tour for himself? And how to manage such invoice_items so that he can cancel himself?
I'm totally lost. Please help.
A few thoughts on users and invoices structures to hopefully get you back on track. You'll probably need to clarify your question regarding other aspects (e.g. refunds).
To cope with users optionally being passengers, you could create a common people table, the people_id being a FK in both passengers and users. Hopefully, this should help keep your subsequent queries simpler and ease the processes whereby users become passengers, and possibly where passengers become registered users too. For example:
people: id (PK), name, dob, sex
users: id (PK), people_id, password, email, phone, level, status
passengers: id (PK), people_id (FK from people), status (as a passenger)
Notes:
Would people.name be better as multiple fields (forename and surname)?
You might consider email and phone better as fields on people rather than users (balancing redundancy against potential marketing)?
Use dob consistently, rather than age (as this will require maintaining).
You might think about how you keep entries on the people table unique to help prevent duplicates being added for the same person.
With respect to Invoices and Refunds section, I'm not entirely sure what is required from the fragment you posted. Consider the following:
invoice: id (PK), invoice_date, user_id, tour_id, invoice_amount
passengers_booked: id (PK), tour_id, passenger_id
wallets: id (PK), user_id (FK from users), transaction_date_time, narration, invoice_no NULL (FK to invoice), ref_no, transaction_amount (float)
Notes:
I'm not sure what your intention was for invoice_detail, as you know who's booking for whom by joining invoice and passengers_booked on tour_id.
Refunds would be handled by posting any refund amount to the relevant wallet record.
I've combined withdrawal and deposit into a single transaction_amount field to remove redundancy and ease the processing when, for example, calculating balances. The types can be distinguished using +ve and -ve values. [Although you may have accounting standards that mandate separate fields.]
I've added invoice_no to wallet to track payments and refunds relating to a particular trip (but may be NULL for deposits/withdrawals). Similarly, ref_no may then be used when deposits/withdrawals into the wallet are received. [n.b. You might consider combining invoice_no and ref_no.]
Example
User U is booking for a tour T for himself and his family members A,
B, C & D. And he also made the payment. Lets assume cost for tour T is
$1000/passenger. So he made a payment of $5000.
The users table has a record for user U.
The tours table has a record for tour T.
The people table has 5 records for U, A, B, C, D.
The passengers table has 5 records.
The passengers_booked table has 5 records for tour T.
The invoice table has a record dated e.g. '1 Jan' for $5000 for tour T.
The wallet has a deposit record for $5000.
The wallet also has a payment of -$5000 against our invoice.
Now he wishes to cancel the booking of B. And for that he will be refunded (suppose)
$900 after cancellation charge.
The B record is removed from passengers_booked (but can be left on passengers for future use).
The invoice table is updated with revised date e.g. '8 Jan' and amount $4100.
The wallet table has a refund made to it against that invoice for $900.
Thus we use a single invoice which only holds the latest position.
You can check the latest invoice amount against the sum of wallet entries for that invoice, to see whether there is an amount outstanding or due for refund.
n.b. There are other ways to model this, e.g. use invoice as the summary as above but have multiple invoice_detail records to capture the detail on passenger changes. Depending on why you're doing this and how sophisticated it needs to be will determine which route is better for you.
I'm building a database that contains for each customer's purchase
Product Name
Product Manufacturer
Store
Date
Buyer's name
Buyer company
Some data such as product name, manufacturer, shop, buyer's name and the buyer's company back on themselves at the time.
Is it better to build them in separate tables and in the primary table to keep their indexes?
On the one hand it saves space on the server
On the other hand it overloads the server and requires more work
I would keep buyer information and product information in separate tables. There is no reason to store this information more then once.
In addition you could use a (relation like) table with buyer id, serialized array of product id's and date of the purchase.
buyer_id | {"prod1_id","prod2_id",...} | date
This way you get a table with all purchases that you can get whenever you want. This will increase the calls to the database but save on the storage.
Hope it makes sense to you.
I need a little help designing a database that a bar would use for drinks. My app handles drink orders in 2 ways: A customer can order drinks and pay right away, or they can start a tab. This is my table relationship so far:
Table Order: Table Tabs:
------------ ------------
[PK] OrderId - 1 [PK] TabId
ItemName / TabName
QtyOrdered / Total
TabId *- PaymentType
Archive
Its setup so 1 tab can have many drinks on it. Thats great for tabs, but customers can choose not to setup a tab. My question is, how can i modify these two tables to support that? Or do I have to create a new table?
Thanks in advance.
Your "item" is the order line-item.
"My brother and I will each have a Guiness and his wife would like a gin-and-tonic."
There are three (EDIT: items, but two) line-items on that order. To identify them as part of the same order [if you should need to do so], you would need two tables:
the OrderHeader
(orderheaderid, orderdatetime, customerid)
and
the OrderDetail
(id, orderheaderid, drinkid, howmany, extendedprice, paymentamountapplied).
If you do not need to identify the drinks as belonging to the same order, you could abandon the two-table structure, but then you could have only one kind of drink per order.
ORDER
orderid, orderdatetime, customerid, drinkid, howmany, extendedprice, paymentapplied.
Extended price is howmany * the drink's price at time of the order. You store this value in your order table so you can change the price of the drink in the DRINKS table without affecting the tab amount owed (in case the tab lifetime is longer than a day -- i.e. customers can run a monthly or quarterly tab).
HowMany can default to 1. The amount owed on a drink line-item is (extendedprice - paymentamountapplied). PaymentAmountApplied defaults to 0 (i.e. default is to run a tab).
If you do not need to track the kind of drink being ordered (i.e. you don't care to use your database to discover that on Tuesday nights you sell a lot more gins-and-tonic than Guinesses, for some reason):
ORDER
orderid, orderdatetime, customerid, ordertotal, paymentapplied.
Your barkeep would simply enter the total amount of the order, calculated outside your system, without reference to a DRINKS table in the database -- maybe the barkeep would look at a chalkboard on the wall.
You need a CUSTOMERS table, a DRINKS table, an ORDERSHEADER table, an ORDERDETAIL table (each drink on the tab is a line-item). You could/should have a separate PAYMENTS table. And you would allocate payments to the line-items of the ORDERDETAIL (your tab). The "tab" is the set of all line-items on the order(s) that have no payment applied to them.
I'm trying to model timesheets, billable hours, projects, users
Whats the best way to represent these in a database
Elaborating more on the question: My biggest predicament is how to keep date, hours, project together
One possible solution
User (PK id, name)
Project (PK id, name, FK user_id)
BillableHour (PK id, FK project_id, hours, date)
Thanks
Start with the reports you want and work backwards.
The minimal input unit is Activity, Duration, but if you use that minimum, you wind up with activities such as sri.attends.scrum.for.parisian.branch.of.client50.via.scype.from.home.to.discuss.installation.routine.of.zoom22, and your report code will have a lot of switch statements.
Presumably you will have at least one report with a name, an activity description, and a total time for a given time-period. If that's your only report, you can implement it as a four-field list: Worker (string), Task (string), Start (time), Duration (integer). If there's a report asking for all the activities ever allocated to a particular project, or one for all the time spent on activity-type X, or a report that allocates activities to particular clients, your design will benefit from more fields.
Perhaps you have a report that distinguishes installing.server.updates at the home office and installing.server.updates under active enemy gunfire in a warzone. If you have a "while.a.target" checkbox on your time-logging screen, that could be a real time-saver for your users.
It's worth learning about Normal Forms if you're not familiar with them. Saves you storing redundant data in your database (amongst other benefits).
http://databases.about.com/od/specificproducts/a/firstnormalform.htm
I can tell you from a very high level how I've done it for a very simple time keeping app. Although, this isn't necessarily the best way.
I don't have a handy ER diagram to share at the moment, but this is just a very basic starting point for a set of tables anyway.
User
ID PK
UserRole
UserID FK
RoleID FK
Role
ID PK
Name
UserProject
ID PK
UserID FK
ProjectID FK
HoursAvailable
Customer
ID PK
Name
Project
ID PK
CustomerID FK
EntryType
ID PK
Name (i.e. billable, non-billable, etc.)
Entry
ID PK
UserID FK
ProjectID FK
EntryTypeID FK
Hours
Date
TaskName (this could be further normalized, esp. if you want to have a bucket of tasks)
Description
I could go on, but you get the idea.
Here's a brief (and incomplete) summary of some of the tables my old accounting system used:
user: the person using the system; name, password, etc
entity: a company or business; name, government IDs, etc
project: a project that can be billed; name, supplier entity, client entity
timesheet: a timesheet entry: user, project, start time/date, number of hours, description of work