I have to implement a ticket selling service using php, where the user inputs the number of seats he/she wants, the system checks for availability and then presents random seats, the user confirms and the reservation is done.
First thing I have to do, is conclude to the database schema I will use. I am a little bit confused, so I will present you what I have thought so far. I really need your advice, in order to continue with the implementation.
I have concluded to the following tables:
Customer: id, name
Ticket : ticket_id, time, price, seat_id
Booking: id, customer_id, ticket_id
Seat: id, status
Τhe point is I am not sure about this, and pretty sure that it is false. For example the theater has a capacity (standard number of seats). So, where should I store this? Should I have a table Theater: id, name, capacity and when the admin completes for example the capacity = 60, then automatically I should make a query that inserts 60 records to the Seats table with status=1 (available)?
I am confused. I will have to think about it more carefully, but a second opinion, would be really very helpful for me.
You are right in thinking your current schema is incorrect. The way you have it now a booking can only have one seat, but your requirement says you need to be able to choose multiple. What you need is a many-to-many relationship. Ask google to find out what that means.
Here's what I think should work:
Customer: id, name
Ticket: ticket_id, time
Booking: id, customer_id, ticket_id
Seat: id, status, price
seat_ticket_map: seat_id, ticket_id
So to attach new seats to a ticket you make a new seat_to_ticket_map instance.
I wasn't sure where to put price but I think it makes sense on Seat. It depends on your requirements though
Related
I am trying to create a simple DB of Customers/Products/Orders to practice my skills with aggregate and so on. I need some help on how to design the relation between those collections correctly (that i'll really be able to store the details in the right way).
I go for the minimal build and information-->
Customer:
(1) customer_id ,
(2)orders (this will be an array with all the order_id's this customer did)
Product:
(1) product_id
Order:
(1) order_id ,
(2) products (this will be an array with all the products in this order) + I wonder how I add quantity for each product ,
(3) user_id (this will store the user_id did this order) or i don't even need this field??
I hope someone could tell me if this is a right thinking, because I come from SQL and this what I would do there I guess
// I'm not using embedded document because in case i'll want to change a specific field value it would change in all places
I'm working on an app for our office and before I start writing this part of the app I need to get some ideas on the best way to structure my data. The application will allow the sales team to enter an estimate and provide it to the customer. If the customer accepts the estimate it becomes a job and is scheduled for the appropriate day. I need a structure that allows me to historically see the estimate in its original state but allow for change orders once the estimate becomes a job. At the completion of the job I will need to see the entire job including all change orders.
I have thought about having an estimates table, an estimates details table and then, once the estimate is turned into a job, the record is copied to the job table, job details table and then a change order table? This doesn't seem very efficient to me.
Would someone shed some design light on this for me please?
Sample Structure:
What you want is the ability to track changes in your entity from initial creation to the final state. You also need to "look back" to see the entity as it existed at any specific time in the past.
Easy. Though not quite simple. What you need is to version your data. I have mentioned versioning in several answers, so rather than repeat some rather lengthy answer here, let me just refer you to a couple.
https://dba.stackexchange.com/questions/114580/best-way-to-design-a-database-and-table-to-keep-records-of-changes/114738#114738
Which option would be better for historical information of a table?
Sorry for lack of details here, but your question was very general in nature.
Update: There is nothing in estimates that would change over time (though I don't understand why it needs address information), so it must be estimate_details you want preserved over time. But I can't tell if there are multiple details to an estimate. The diagram shows a 1:n relationship so I'll go with that.
The best thing would be to place another entity, say bids between estimates and estimate_details:
create table bids(
estimate_id int not null,
eff_date date not null default current_date(),
...,
constraint PK_Bids primary key( estimate_id, eff_date ),
constraint FK_Bids_Estimate foreign key( estimate_id )
references estimates( ID )
);
create table estimate_details(
bid_id int not null,
eff_date date not null,
product_id int not null,
quantity float,
constraint PK_Estimate_Details primary key( bid_id, eff_date, product_id),
constraint FK_EstimateDetail_Bid foreign key( bid_id, eff_date )
references bids( estimate_id, eff_date )
);
I'm assuming here that no two details will concern the same product. Other bids data could include the date it was submitted to customer, the total price, the date customer responded and whether the bid was accepted.
When an estimate is created, the first bid is also created with the same ID as the estimate and the effective date, which could be the date work started on the estimate or other meaningful date. Details link to the bid using the estimate ID and the date of the bid. Then the bid is finished and submitted to the customer. Customer rejects so a new bid is created -- same ID, different date. New details link to this bid.
There could be any number of bids each with any number of details. You can query any estimate at any time just by retrieving the bid for the date you wanted to look at and getting the details linked to that bid.
I'm also assuming that each new bid starts with a clean slate -- that no details carry forward to apply unchanged to the new bid. If that is wrong, if you want to reuse some details from bid to bid, then a slight change can remove the need to duplicate these details across bids.
I am making an application for a restaurant.
For some food items, there are some add-ons available - e.g. Toppings for Pizza.
My current design for Order Table-
FoodId || AddOnId
If a customer opts for multiple addons for a single food item (say Topping and Cheese Dip for a Pizza), how am I gonna manage?
Solutions I thought of -
Ids separated by commas in AddOnId column (Bad idea i guess)
Saving Combinations of all addon as a different addon in Addon Master Table.
Making another Trans table for only Addon for ordered food item.
Please suggest.
PS - I searched a lot for a similar question but cudnt find one.
Your relationship works like this:
(1 Order) has (1 or more Food Items) which have (0 or more toppings).
The most detailed structure for this will be 3 tables (in addition to Food Item and Topping):
Order
Order to Food Item
Order to Food Item to Topping
Now, for some additional details. Let's start flushing out the tables with some fields...
Order
OrderId
Cashier
Server
OrderTime
Order to Food Item
OrderToFoodItemId
OrderId
FoodItemId
Size
BaseCost
Order to Food Item to Topping
OrderToFoodItemId
ToppingId
LeftRightOrWhole
Notice how much information you can now store about an order that is not dependent on anything except that particular order?
While it may appear to be more work to maintain more tables, the truth is that it structures your data, allowing you many added advantages... not the least of which is being able to more easily compose sophisticated reports.
You want to model two many-to-many realtionships by the sound of it.
i.e. Many products (food items) can belong to many orders, and many addons can belong to many products:
Orders
Id
Products
Id
OrderLines
Id
OrderId
ProductId
Addons
Id
ProductAddons
Id
ProductId
AddonId
Option 1 is certainly a bad idea as it breaks even first normal form.
why dont you go for many-to-many relationship.
situation: one food can have many toppings, and one toppings can be in many food.
you have a food table and a toppings table and another FoodToppings bridge table.
this is just a brief idea. expand the database with your requirement
You're right, first one is a bad idea, because it is not compliant with normal form of tables and it would be hard to maintain it (e.g. if you remove some addon you would need to parse strings to remove ids from each row - really slow).
Having table you have already there is nothing wrong, but the primary key of that table will be (foodId, addonId) and not foodId itself.
Alternatively you can add another "id" not to use compound primary key.
I want to get Employee ID, Leave Reason, Leave type and Employee name for my internal report purpose. I wrote a SQL query to retrieve those data and I got some duplicates also.
Seems it's missing some join / foreign id mapping part missing
select
h.id as employee_id,h.name as leave_reason,
s.name,r.name as res_name
from
hr_holidays_status s,
hr_holidays h,
hr_employee e,
resource_resource r
where
h.employee_id=e.id and
h.holiday_status_id=s.id and
e.resource_id=r.id
order by
resource_id
Your query looks correct, but maybe you're getting unexpected results because the hr_holidays table contains both "Leave Requests" and "Leave Allocations". It's like a double-entry system where leave allocations increase the quantity of leave days available for an employee or an employee category, while leave requests decrease it.
Your query should probably take this distinction into account, and you might also want to filter on other fields like the state, because some of the records may not be validated yet.
Looking at the declaration of the hr.holidays model in 6.1, you will see a few noteworthy fields that could be used in your query:
type: can be Allocation ('add') to represent an increment, or Request ('remove') to represent a decrement
holiday_type: can be Employee ('employee'), in which case the employee_id column indicates which employee, or Category ('category'), in which case the category_id column indicates which category
state: New ('draft'), Waiting Approval ('confirm'), Refused ('refuse'), Waiting Second Approval ('validate1'), Approved ('validate'), Cancelled ('cancel')
I have created an adaptation of the 'Goods' database that includes a quote feature. The user selects the customer (customer table), Product (product table), qty, discount ect.
The chosen entities then get saved to the quotes table and there is a 'print' function on form.
Whilst the information can be saved and the quote prints via a quote report, I'm having major difficulty in finding a way to add multiple products to a single quote.
The main objective is to be able to select various products and add their total price (product after addition of qty, discount) to a SUB TOTAL
Quote total is therefore the formula Tax+Shipping+SubTotal
any takers? :)
Hi guys,
Thanks for the response I really appreciate it. As for tax and shipping, they are just added in the form and are not pushed from anywhere else in the database. Its simply a type in form and display on report sort of thing. As you said in the answer, HansUp, the salesperson will compute it seperately and just input it.
As for tax, products will be shiped globally so the tax/vat shall be computed seperately also.
Also, each table DOES have its own unique ID.
More to the point of having QuoteProducts. I can't seem to get my head around it! Are you saying that whatever products are chosen in QuoteProducts will create a QuoteProd_ID and then that ID's total price will therefore be added to the Quote?
I tried making a subform before but through the 'multiple records' form but obviously every selection made its own ID. Is there any way you could elaborate on the Quote products part and how it allows multiple records to store to one ID? Without understanding it i'm pretty much useless.
In addition, how the multiple records are then added up to make the subtotal also baffles me. Is that done in the Quote form?
Edit 2
HALLELUJAH.
It works! I created a sum in a textbox on the footer of the subform and then pushed that into subtotal :)
I do have one slight issue:
I made a lookup&relationship for the ListPrice. I don't think its the correct way to do it as it comes up with the price of every light (i.e 10 products priced £10, £10 shows up ten times in dropdown).
Can you guys help?
List Price Problem
here's what i've tried:
1) Create >Client>Query Design
2) Show Products, QuoteDetails. For some reason, it automtically comes up with ListPrice, ProductID (as it should) and Product Name linked to ID in Products
3) Delete links with ListPrice and ProductName.
4) Show all in quoteDetails (*)
5) Create Multiple Items form
Doesnt work! What am I doing wrong?
I'm extremely grateful for both your help. If I can do anything, just shout.
Ryan
In addition to HansUp's stellar answer, you might be interested in DatabaseAnswers.org. They have a number of data models for free that might provide additional insight to your situation and possibly serve as inspiration for future projects you may encounter.
Edit 1
Forget about the form and report for a moment - they are important but not as important as the data and how you store the data.
In your current design, you have a quotes table presumably with an autonumber key field. For the purposes of this answer, this field is named Quote_ID.
The quotes table, as HansUp suggested, should store information such as the Customer_ID, Employee_ID, OrderDate and perhaps even a reference to a BillingAddress and ShippingAddress.
The quotes table SHOULD NOT store anything about the products that the customer has ordered as part of this quote.
Instead, this information should be stored in a table called QuoteProducts or QuoteDetails.
It's structure would look something like the following:
QuoteDetails_ID --> Primary Key of the table (autonumber field)
Quote_ID --> Foreign key back to the Quotes table
Product_ID --> Foreign key back to Products table
Quantity
UnitPrice
You may also want to consider a field for tax and a separate field for shipping per line item on the quote. You will inevitably run into situations where certain items are taxable in some locations and not others, etc.
This design allows a particular quote to have any number of products assigned to the quote.
Returning to your form \ reports, you would need to change your existing forms and reports to accomodate this new table design. Typically one would use a main form for the quote itself, and then a subform for the quote details (item, price, quantity, etc).
To get the quote total, you would sum the items in QUoteDetails for a particular Quote_ID.
You may also want to check out the Northwind sample database from Microsoft. From what I recall Northwind had a sample Orders system that might help make these ideas more concrete for you by seeing a working example.
For the first 3 tables mentioned in your comment, each should have a primary key: Customers, customer_id; products, product_id; and employees, employee_id.
The quotes table will have its own primary key, quote_id, and will store customer_id and employee_id as foreign keys. (I'm assuming you want employee_id to record which customer representative/salesperson created the quote.) You may also decide to include additional attributes for each quote; date and time quote prepared, for example.
The products offered for quotes will be stored in a junction table, QuoteProducts. It will have foreign keys for quote_id and product_id, with one row for each product offered in the quote. This is also where you can store the attributes quantity and discount. An additional field, unit_price, can allow you to store the product price which was effective at the time the quote was prepared ... which would be useful in case product prices change over time. I don't know whether tax should be included in this table (see below).
I also don't know how to address shipping. If all the products associated with a quote are intended to be delivered in one shipment, shipping cost could be an attribute of the quotes table. I don't know how you intend to derive that value. Seems like it might be determined by shipping method, distance, and weight. If you have the salesperson compute that value separately, and then input the value, consider how to handle the case where the product selection changes after the shipping fee has been entered.
That design is somewhat simplistic, but might be sufficient for the situation you described. However, it could get more complex. For example, if you decide to maintain a history of product price changes, you would be better off to build in provisions for that now. Also, I have no idea how tax applies in your situation --- whether it's a single rate applied to all products, varies by customer location, varies by type of customer, and/or varies by product. Your business rules for taxes will need to be accommodated in the schema design.
However, if that design works for you (test it by entering dummy data into the tables without using a form), you could create a form based on quotes with a subform based on QuoteProducts. With quote_id as the link master/child property, the subform will allow you to view all products associated with the main form's current quote_id. You can use the subform to add, remove, and/or edit products associated with that quote.
Not much I can say about the report. There is a lot of uncertainty in the preceding description. However, if your data base design allows you to build a workable form/subform, it should also support a query which gathers the same data. Use that query as the record source for the report. And use the report's sorting and grouping features to create the quote grand total.
Edit: With the main form/ subform approach, each new row in the subform should "inherit" the quote_id value of the current record in the main form. You ensure that happens by setting the link master/child properties to quote_id. Crystal Long explains that in more detail in chapter 5 of Access Basics by Crystal: PDF file. Scroll down to the heading Creating a Main Form and Subform on page 24.
Edit2: Your strategy may include storing Products.ListPrice in QuoteDetails.ListPrice. That would be useful to record the current ListPrice offered for a quote. If so, you can fetch ListPrice from Products and store it in QuoteDetails when you select the ProductID for a row in the subform. You can do that with VBA code in the after update event of the control which is bound to the ProductID field. So if that control is a combo box named cboProductID and the subform control bound to the QuoteDetails ListPrice field is a text box named txtListPrice, use code like this for cboProductID after update:
Me.txtListPrice = DLookup("ListPrice", "Products", "ProductID = " _
& Me.cboProductID)
That suggestion assumes the Products and QuoteDetails tables both include a ProductID field and its data type is numeric. And cboProductID has ProductID as its bound field and uses a query as its RowSource similar to this:
SELECT ProductID, ProductName
FROM Products
ORDER BY ProductName;