You no doubt have heard this old philosophical question that completes with, "Does it Make a Sound?" As nerds, we all know that the answer is that it certainly does make a sound. However, take the question to a more technical place, how much sound does it make, and what is the impact of that sound, is far more interesting, and far more complex.
This brings me to my data question. If an order is processed in a store, but the expected data is not created, did that order ever occur?
Very often, the staff of a business are very focused on pleasing the customer, making sure they get their product, but due to software limitations, may not end up not capturing information about every sale in a satisfactory manner. Most of the blame I have seen lies in software that doesn't meet the requirements of a customer, making capturing desired details tedious to achieve when the process is in the norm. Very often the excuse programmers give is that too much work of the work to build a system would need to be done for the atypical cases, but requirements are requirements, and it is generally essential that every action that occurs in a business is captured as data.
In the same way that we know that the tree made a sound, we know that the order did actually occur. However, without data being captured about the transaction, this lack of evidence may cause several things to occur.
1. If the customer comes back later with a receipt that has a transaction number that was never written to the database, they may be questioned as if they have stolen the product. Calling a customer a thief is not optimum for most businesses that file taxes.
2. The income from the sale is like going to make cash balances off, causing headaches trying to reconcile cash amounts. (Alternatively, income may be stolen. I never did this when I worked in retail, but sometimes an employee takes a sale, they fake the paperwork, pockets the money. Again, I never did this, and the statute of limitations surely has passed in any case.)
3. Inventory counts will be off, since product has left the building and hasn't been counted.
The issues noted are just the short term, functional issues. Generally speaking though, the most important reason we store data is to report on data.
From a data science perspective, when data is not stored about a transaction, it is impossible to determine how important that transaction was. Every order a customer places is important from the individual purchase income, naturally. But it is also important to help predict the next sale. Information like when the sale occurred, if any discounts or coupons were applied, demographics of the purchaser help to land the next sale both from that same customer and future customers.
Now, consider when incomplete, or inaccurate information is entered because the database won't allow fringe cases to be stored? Somethings might be acceptable (if you can at least capture the income and inventory changes), but incomplete information can be worse than no information for reporting. If all transactions appear to be of the typical variety, it will look like fringe cases never occur (And sometimes the fringe cases turn out to be an interesting percentage of what is occurring, leading to opportunities with other similar customers.)
So poorly created and managed databases could actually be harming future business. So while pleasing the customer is always important, equally important is making sure that the systems that we are creating as architects and programmers actually mirror the reality that is occurring for our clients. So when the tree falls, not only is someone there to hear it, the impact of the loss of the tree (reduced oxygen, loss of bird and squirrel habitats, future fire hazards) is calculable and turned into actions (like building the squirrels new housing complexes!)