I looked over some of the other answers here and they did not answer the question I have.
How would I go about this problem. If an invoice is created with the following database schema:
id
customer_id
invoice_date
status
the invoice is created, paid etc. If the customer information changes, the invoice information will change since its a FK. How would I create the invoice table to record customers information at that give moment in time, so if the customer change their address in the future for example the past invoices will stay the same with the previous address.
Just wanted to see if it makes sense to copy customer information into the invoice table with their address etc. but then it will adhere to normalizing the database.
Please let me know what your thoughts are in regards to this challenge. Invoices in one example, this can also apply to Purchase orders that were created in the past should have definite information that was recorded in the past no matter what has changed now.
There are different considerations for an order management system or a reporting system.
Within an application, data duplication may prove cumbersome at volume. Will prove cumbersome at high enough volume. So you'll want to be as normalized as possible in that environment.
For reporting and history, though, it would be preferable (maybe mandatory depending on your industry and locale) to have the address info for each invoice.
It would be better to have an address table that joins to your customer table. The addresses would each have their own id field, and then you could just reference that id in the invoice table, too. Probably both the billing address and the shipping address if they're both in play in your business model.
If you don't have the flexibility to introduce a stand alone address table, then copying the address information over to the invoice table becomes a necessary evil. But dead useful information to have.
Related
I know that there is not a "good" answer to my question, and it is opinion based. But since I am now learning those things on my own, I need advice.
I have a table on Mysql about "Customer". In this table there are columns referred to customer's info like name, surname, date of birth, address, and so on.
Each customer has his own credentials (username, password).
Now my question is: It is better to keep credentials in "customer" table, or it has sense to create a separate table, in order to guarantee the protection of these credentials, and also keep track of the changes of them along time, without wasting space repeating all the others customers' info?
You need to answer some questions about your data:
Do the columns change? People change names, addresses, and so on.
The credentials will change, at least the password.
What sort of history do you need?
My recommendation would be different sets of tables for different purposes:
One table that defines the customer id and whatever other immutable information there is (perhaps the date of becoming a customer and related information).
One or more tables with PII (personally identifiable information). You want to keep PII separate for regulatory and privacy reasons.
Tables for history. How you do this depends on your data model and what you need. A simple method is a single archive table per table in your data model. However, I might recommend type-2 tables (i.e. those having version effective and end dates).
Separate tables for credentials. These are even more sensitive than PII and you will want to control access.
Remember to never store clear-text passwords. And often you want to keep a history of passwords to prevent users from using the previous one.
It is better to create personal information in the person table and additional customer information in another table that has a relationship with the customer, and if you have any other information about the person in another table and link it to the table of persons.
I'm working on my final project for an intro to Access DB class. My assignment is a general "Create a DB with at least 3 tables, of which 2 are linked," with some specific requirements for types of tables (customer relations, financial management, product/service-related data).
I decided to create a database for a fictional airline. I need to track financial information, particularly the sale of tickets. I have a tblFlights table that includes a BaseFare field, a tblAirports table that includes airport fees and airport taxes and a tblInvoice table that currently only has invoice number and customer ID fields in it. I suppose that I would use a report to generate an actual invoice, not a table, right? So, I don't want to store a bunch of financial data in an invoice table, and maybe I shouldn't even have an invoice table? How do I keep track of how much money customers owe and how much they have paid?
I suppose that I would use a report to generate an actual invoice, not a table, right?
Yes, use a report.
So, I don't want to store a bunch of financial data in an invoice table, and maybe I shouldn't even have an invoice table? How do I keep track of how much money customers owe and how much they have paid?
Well, I suppose some industries might be able to get an airline to send them in invoice, but I've never heard of that myself. In my experience, you pay first, then they give you the ticket. So I'd expect a table of tickets, which would identify the flight, the seat (or its equivalent), the person's name, and something to indicate that it's paid (a Boolean flag, a price, something like that).
We have a requirement in our application where we need to store references for later access.
Example: A user can commit an invoice at a time and all references(customer address, calculated amount of money, product descriptions) which this invoice contains and calculations should be stored over time.
We need to hold the references somehow but what if the e.g. the product name changes? So somehow we need to copy everything so its documented for later and not affected by changes in future. Even when products are deleted, they need to reviewed later when the invoice is stored.
What is the best practise here regarding database design? Even what is the most flexible approach e.g. when the user want to edit his invoice later and restore it from the db?
Thank you!
Here is one way to do it:
Essentially, we never modify or delete the existing data. We "modify" it by creating a new version. We "delete" it by setting the DELETED flag.
For example:
If product changes the price, we insert a new row into PRODUCT_VERSION while old orders are kept connected to the old PRODUCT_VERSION and the old price.
When buyer changes the address, we simply insert a new row in CUSTOMER_VERSION and link new orders to that, while keeping the old orders linked to the old version.
If product is deleted, we don't really delete it - we simply set the PRODUCT.DELETED flag, so all the orders historically made for that product stay in the database.
If customer is deleted (e.g. because (s)he requested to be unregistered), set the CUSTOMER.DELETED flag.
Caveats:
If product name needs to be unique, that can't be enforced declaratively in the model above. You'll either need to "promote" the NAME from PRODUCT_VERSION to PRODUCT, make it a key there and give-up ability to "evolve" product's name, or enforce uniqueness on only latest PRODUCT_VER (probably through triggers).
There is a potential problem with the customer's privacy. If a customer is deleted from the system, it may be desirable to physically remove its data from the database and just setting CUSTOMER.DELETED won't do that. If that's a concern, either blank-out the privacy-sensitive data in all the customer's versions, or alternatively disconnect existing orders from the real customer and reconnect them to a special "anonymous" customer, then physically delete all the customer versions.
This model uses a lot of identifying relationships. This leads to "fat" foreign keys and could be a bit of a storage problem since MySQL doesn't support leading-edge index compression (unlike, say, Oracle), but on the other hand InnoDB always clusters the data on PK and this clustering can be beneficial for performance. Also, JOINs are less necessary.
Equivalent model with non-identifying relationships and surrogate keys would look like this:
You could add a column in the product table indicating whether or not it is being sold. Then when the product is "deleted" you just set the flag so that it is no longer available as a new product, but you retain the data for future lookups.
To deal with name changes, you should be using ID's to refer to products rather than using the name directly.
You've opened up an eternal debate between the purist and practical approach.
From a normalization standpoint of your database, you "should" keep all the relevant data. In other words, say a product name changes, save the date of the change so that you could go back in time and rebuild your invoice with that product name, and all other data as it existed that day.
A "de"normalized approach is to view that invoice as a "moment in time", recording in the relevant tables data as it actually was that day. This approach lets you pull up that invoice without any dependancies at all, but you could never recreate that invoice from scratch.
The problem you're facing is, as I'm sure you know, a result of Database Normalization. One of the approaches to resolve this can be taken from Business Intelligence techniques - archiving the data ina de-normalized state in a Data Warehouse.
Normalized data:
Orders table
OrderId
CustomerId
Customers Table
CustomerId
Firstname
etc
Items table
ItemId
Itemname
ItemPrice
OrderDetails Table
ItemDetailId
OrderId
ItemId
ItemQty
etc
When queried and stored de-normalized, the data warehouse table looks like
OrderId
CustomerId
CustomerName
CustomerAddress
(other Customer Fields)
ItemDetailId
ItemId
ItemName
ItemPrice
(Other OrderDetail and Item Fields)
Typically, there is either some sort of scheduled job that pulls data from the normalized datas into the Data Warehouse on a scheduled basis, OR if your design allows, it could be done when an order reaches a certain status. (Such as shipped) It could be that the records are stored at each change of status (with a field called OrderStatus tacking the current status), so the fully de-normalized data is available for each step of the oprder/fulfillment process. When and how to archive the data into the warehouse will vary based on your needs.
There is a lot of overhead involved in the above, but the other common approach I'm aware of carries even MORE overhead.
The other approach would be to make the tables read-only. If a customer wants to change their address, you don't edit their existing address, you insert a new record.
So if my address is AddressId 12 when I first order on your site in Jamnuary, then I move on July 4, I get a new AddressId tied to my account. (Say AddressId 123123 because your site is very successful and has attracted a ton of customers.)
Orders I palced before July 4 would have AddressId 12 associated with them, and orders placed on or after July 4 have AddressId 123123.
Repeat that pattern with every table that needs to retain historical data.
I do have a third approach, but searching it is difficult. I use this in one app only, and it actually works out pretty well in this single instance, which had some pretty specific business needs for reconstructing the data exactly as it was at a specific point in time. I wouldn't use it unless I had similar business needs.
At a specific status, serialize the data into an Xml document, or some other document you can use to reconstruct the data. This allows you to save the data as it was at the time it was serialized, retaining original table structure and relaitons.
When you have time-sensitive data, you use things like the product and Customer tables as lookup tables and store the information directly in your Orders/orderdetails tables.
So the order table might contain the customer name and address, the details woudl contain all relevant information about the produtct including especially price(you never want to rely on the product table for price information beyond the intial lookup at teh time of the order).
This is NOT denormalizing, the data changes over time but you need the historical value, so you must store it at the time the record is created or you will lose data intergrity. You don't want your financial reports to suddenly indicate you sold 30% more last year because you have price updates. That's not what you sold.
I'm in the process of creating a website and would like some advise on my database schema as I don't have very much experience in that field.
Say I had a site where 2 products were for sale, product1 and product2.
When a user buys either product they get a user account with a key to access their account. A user can download their product from their account page. That user can then at a later date purchase the remaining product and the product gets added to their account allowing them to download both product1 and product2 using the key given to them when purchasing the first product.
Payment information (payment method, transaction id, timestamp, etc) will also be stored.
I currently have my schema planned as so:
I feel that the way I'm doing it is not optimal and there are better ways to organize it. Any advise?
Hope you can help and thanks in advance :)
It is a good idea to start off identifying the objects your schema will store. It looks like candidate components might be
user
(user data)
product
purchase
These entities will be the tables you start out with. Add relationships appropriately.
Identifying the entities in your schema will (hopefully) keep you from outwardly expanding tables. You don't want to have to revise your whole schema for example every time you add a product. Similarly, you would not want to add a new table each time.
Once you've identified these, start putting them in normal form. 3rd normal form is generally recommended. You will likely find, as you have indicated in your schema, there is much redundant data that would fall under the purchase entity that separating it out to another table makes for a more maintainable schema.
This will eliminate redundant data in your tables which might later fall out of synch and help to identify where some data is out of place.
Good Day,
I'm currently designing database structure for a website of mine. I need community assistance in one aspect only as I never did something similar.
Website will include three types of the payments:
Internal payments (Escrow kind payments). User can send payment to another user.
Deposits. Users add fund to their accounts.
Withdrawal. User can request a withdrawal. Money will be sent to their bank/PayPal account.
Basically, I need some tips to get the best design possible.
Here's what I'm thinking about:
deposits - this table will store info about deposits
deposits_data - this table will store info about deposit transaction (ex. data returned by PayPal IPN)
payments - table to store internal payments
withdrawals - table to store info about withdrawal request
transactions - table to store info about ALL transactions (with ENUM() field called type with following values possible: internal, deposit, withdrawal)
Please note that I have already a table logs to store every user action.
Unfortunately, I feel that my design approch is not the best possible in this aspect. Can you share some ideas/tips?
PS. Can I use a name "escrow" for internal payments or should I choose different name?
Edit
DEPOSITS, PAYMENTS and WITHDRAWALS tables store specific transaction details. TRANSACTIONS table stores only limited info - it's a kind of logs table - with a details field (which contains a text to display in user log section, ex: "User 1 sent you a payment for something")/
Of course I have users tables, etc.
Can I use a name "escrow" for internal
payments or should I choose different
name?
Escrow has a specfic financial/legal meaning, which is different from how you seem to mean it: "a written agreement (or property or money) delivered to a third party or put in trust by one party to a contract to be returned after fulfillment of some condition" (source)
So choosing a different name seems like a good idea.
As for design, what data will DEPOSITS, PAYMENTS and WITHDRAWALS store which TRANSACTIONS won't? Also, you need an ACCOUNTS table. Or are you planning to just use your existing USERS table (I presume you have such a thing)? You probably ought to have something for external parties, even if you only intend to support PayPal for the time being.