I'm trying to implement a flight booking system, and the use case is as follow:
A registered customer should be able to buy several tickets, not only for himself, and for each ticket the passenger info would be recorded.
In the database design, I have two tables -- a ticket table, and a purchase table. Tuples in the ticket table records only information with the flight and the passenger, and each ticket has a unique ticketID as primary key. Inside the purchase table, it has a foreign key reference to the ticket table, and has attributes that indicate which registered use this purchase record belongs to.
Now, suppose I have several tuples of passenger data sent to the server, the first thing I should do is to insert new tickets, and then I could perform insertion on the purchase table indicates the relation between each tickets and the person who bought the tickets. Notice that the new records in the purchase table would have ticket_ids which were just created by new tickets.
My confusion is: how do I implement this within one operation as a whole? ** In the purchase table, I would also give the tuples that are created by the same customer in the same transaction an ID, indicates that those tickets belongs to the same purchase records. ** Could I achieve this using a stored procedure? I feel like the passing of data is tricky, since I'm very new to stored procedure, etc.
Related
I have a database of 5 tables. Some contain the same columns as others, does tying these tables to another table which has the primary keys of other tables meet 3rd normalisation. (This is outlined more clearly below)
I have a table of customers, with their names and phone numbers as well as requirements they want in their car etc. The primary key is CustomerID.
I then match a customer with a car which matches their requirements. I have a table with Match ID (Primary key) and CustomerID and CarID (As foreign keys.)
By doing this, can I then make a table off Match ID which can be given to the receptionist so that they can contact the customer. In this table I would need to include the customer name and phone number. However, does this break 3rd normal form as Phone number is now both in CustomerID and the new table.
The last table you describe doesn't necessarily break any normal form, because the customer's phone number can change in the future. You may want to preserve the phone number in another table so there is a record of what phone number was contacted on that date.
Compare with a database of products. The product table has prices. Then you record customer purchases, with a copy of the price they paid on the date they made the purchase. That's okay because you need a record of what was paid in each case. A customer may buy the product during a sale, or they got a senior discount, or a bulk discount, or the price may change a month after they bought the item, etc. The price they paid is not necessarily the current price recorded in the products table. Therefore it does not violate 3NF.
In Microsoft Access I have three tables: order table, customer table and product table. My order table pulls in both customer contact and product information. Every now and then I need to update either the customer address. When doing so, I only want the new address to appear on future orders. I don't want Access to update previous orders with an address that was not originally affiliated with that order. I also want to maintain a list of active and past addresses on the customer list. Please advise on the best ways for setting up the customer table and how to retain customer contact information on the order table.
To do this you need to take the customer address out of the Customer table and keep it in a separate CustomerAddress table. This new table has a primary key (of course), a foreign key back to the Customer table, all the address fields that you want to maintain history of and a Current flag (Yes/No). Your Order table then points directly to the CustomerAddress table instead of the Customer table (you can get from Order to Customer because of the FK link on CustomerAddress to Customer). Now your fun starts! You have to maintain your CustomerAddress table in such a way that for each Customer ID you should only have one Address record where Current is True.
The other alternative is to not have a Current flag on the CustomerAddress table, but instead have a CurrentAddress field in your Customer table - this ensures that only one Address can ever be the current one for a Customer. However you can't enforce both the CurrentAddress integrity and the CustomerAddress foreign key - you can't set the value of CurrentAddress until you've added the Address record, so Customer record has to be able to exist with NULL CurrentAddress (although I suppose you could have a dummy 'Not set' CustomerAddress record).
The simple method is to store the current customer information with the order.
The extended method is to store the customer table(s) as temporal tables, either using a custom method or a native as - for example - offered by the newest versions of SQL Server. Look up the term Temporal database for more information.
I'm running for office and have created a web app for tracking my door knocks to voters at their homes. The database contains a table called voters that contains all the necessary information about voters in my community.
I'd like to add a new feature to track donors to my campaign. Not all of these donors live in the community and do not vote in the district where I'm running for office. I do not need to track the same kind of info for these individuals as I do for the voters so I'm going to place these individuals into a table called nonvoters.
Now, the individuals in my "voters" table can also make donations, and I want to track those as well.
To track the donations from both voters and nonvoters, I'd like to set up a new table called "donations." This table would contain the appropriate details about the donation.
But I'm uncertain as to what the best structure is for linking the donations table to the "voters" and "nonvoters" table. If I create a column called voter_id in the table to key it to the donors information, there's no way to know which table that ID refers to. So do I set up two columns, nonvoter_id and voter_id and insert the ID into the applicable column depending on whether the donor is a voter? This seems weird.
Or maybe I create a column in both the voters and nonvoters table called donor_id that I can use to link my data in the donations table. If I went this route, it seems like I'd have to do a some behind the scenes work to ensure the donor_id was unique and was keyed to the data inside the donations table.
Or maybe there are other approaches I'm not familiar with. Any guidance is appreciated.
I would use a single table for voters and non-voters, let's say persons. You can have a flag in the persons table that indicates if the person is a voter or you may even derive this from their address (if that's possible).
I would create a donations table and link each donation to a person (or persons) in the persons table using the id in the persons table. If a donation can be given by multiple people, then you will need a 3rd connection table with person id and donation id as 2 fields. These 2 fields would be the primary key for the connection table.
I'm working on a very simple DB.
Imagine I've table customer and table seller.
The customer is able to request a quotation for some products
There will be a simple form that allow to customers to select products and submit the quotation.
Now, should I create table : "Quotation" and store all quotations (with id_quotation..etc)?
Thank you all
Without knowing all of the business rules that govern the requirements of this database, perhaps the following design will help to answer your question and explain a few concepts in the process.
In database terms, an entity is a person, place, or thing about which we want to collect and store data. From your description we can already see two entities: seller and customer. This is important since the entities we identify conceptually become database tables in their own right.
The seller table should contain data applicable only to sellers. Thus, the qualities (attributes) about sellers that we want to store become columns in our seller table. Each row (record) in the seller table represents an individual seller. Each individual seller is uniquely identified in the seller table with a unique value stored in it's primary key column, which we can name seller_id.
A simplified version of such a table could look like this:
In a similar manner, the customer table should contain data only applicable to customers. The qualities (attributes) about customers that we wish to store become the columns in the customer table. Each row (record) in the customer table represents an individual customer. Each individual customer is uniquely identified in that table with a unique value in it's primary key column, which we can declare as customer_id.
A simplified version of this table:
I'm guessing the business rules state that any customer is able to request any number of products, from any seller, any number of times...since surely any seller would want as many sales and customers as possible!
How can we express and record the interactions (relationship) between seller and customer?
This is done with a new kind of entity: a composite entity. It becomes a new table, having it's own primary key, and contains seller_id and customer_id as foreign keys. The foreign keys in this table connect (relate) the seller table to the customer table.
We can name this new table quotation (if that is your preferred name). Each row of this table is intended to capture and record each and every individual transaction between a customer and a seller. The columns (attributes) of this table are the data that apply to a transaction between a customer and seller, such as amount or date of sale.
A very simplified version of this composite entity:
Note that the foreign key values that exist in this table must already exist in their respective tables as a primary key value. That is, a foreign key value cannot be entered into this table unless it exists already as a primary key value in it's own table. This is important, and it is called referential integrity - it ensures that there is no record of a customer purchasing from a non-existent seller, etc.
In the example above we can see that Builder B requested a quotation from Acme Construction in the amount of $3500.00. They then requested another quotation at another time for the amount of $1800.00. What else does it reveal? All existing customers have ordered something. Acme Lumber has not made a sale at all (yet), etc.
A design such as this enables the database to store any number of transactions between sellers and customers. Likewise, it supports the addition of any number of new customers and sellers, even if they have not sold or purchased anything yet. Queries can be run that reveal which sellers have sold the most or least, and so on.
Good luck with your studies!
I'm currently designing a billing app that can be used for a consultant to bill their customers. I currently have 3 tables in mysql for this the database to store information. The tables are activity, customer and expenses.
In the activity table I've got activity_id, activity_name, percent_rate, hours
In the customer table I've got customer_id, and all the information on the customer
In the expense table I've got expense_id, description, cost, quantity
I'm trying to figure out how to design the database that I can keep track of the hours spent on activity per customer. I want it to be used for multiple customers, but can't figure out how to structure the database for this.
Is it best to use a foreign key like custId in the activity table?
Yes.
But a lot depends on your overall structure. That's a pretty simple data model. If for instance you had something like "project", that the activities are related to, you'd put the customer id in the project table. Then again, if there were multiple customers for that activity, you'd have another table, with activity_id and customer_id in it, just to show that relationship. So, it depends on the problems you're trying to model.
Sounds like it. Does each activity have one (and only one) customer? Then you could have activity_id be the primary key of the activity table, and customer_id be a foreign key. For each customer you can get a list of activities, and for each activity you can figure out the # of hours the consultant worked for that customer on that activity.