I have labored for clients which had a lot of distinct, promising small to mid-sized projects, each getting together with one another via correctly defined connects to talk about data, although not reading through and conntacting exactly the same database. Each had their very own separate database, their very own cache, their very own file servers/system that they devoted use of, and they also never triggered any problems. One of these simple clients is really a mobile content vendor, so they are lucky in ways that they don't have to manage exactly the same issues that everyday business programs do. They are able to create all individuals separate compartments where their components happily reside in isolation from the others.
However, for a lot of business programs, no chance. I have labored having a couple of clients, among whose programs I'm doing the development support for, where you will find "bad data issues" per hour. Yeah, it's that crazy. Some data records from among the instances (less than production, obviously) could have been run a few days ago, and triggered another user's data to obtain corrupted. After which, an information script must be written to repair this problem. And I have seen this happening a lot with this particular client that I must request.
I have seen this happening in a moderate rate along with other clients, but that one just appears to become from order.
If you are dealing with business programs that share a lot of data by reading through and conntactingOrin the same database, are "bad data issues" that common inside your atmosphere?
Bad data issues occur constantly. The only real reasonably effective defense is really a correctly designed, stabilized database, preferrably getting together with the outdoors world only through saved methods.
For this reason you should place the needed data rules in the database level and never the applying. (Obviously, it appears that lots of systems think before in the application level either.)
Additionally, it appears that alot of people that design data imports, think before to wash the information before putting it within their system. Obviously it's difficult to find all of the possiblity to screw up the information, I have done imports for a long time and that i get surprised sometimes. My personal favorite was the organization where their data entry people clearly did not worry about the area names and also the application just went to another area once the first area was busy. I acquired names like: "McDonald, Ja" within the surname area and "mes" within the name area.
I actually do data imports from many, many clients and suppliers. From 100s of various imports I have developed, I'm able to think about just one or two in which the data was clean. For whatever reason the e-mail area appears to become particularly bad and it is frequently employed for notes rather than emails. It is difficult to send an e-mail to "His secretary may be the hot blonde."
Sad but true...i observe that kind of issues arise at companies.
Fortunately that kind of information mill not our clients :-)
Yes, common. Obtaining the customer to know the extent of the issue is another matter. At one customer I needed to turn to writing a credit card applicatoin which examined their database and beeped each time it enountered an archive which did not match their very own released data format. I required laptops using their DB installed to some meeting and went this program, then viewed all of the heads while dining swivel around to stare at their DBA while my machine beeped crazily without anyone's knowledge. There is nothing that can compare with grinding the customer's nose in the own problems to achieve attention.
I do not think you're speaking about bad data (however it would simply be polite individuals to reply to the different questions elevated in comments) but invalid data. For instance, '9A!' saved inside a area that's designed to consists of a 3-character ISO ccurrency code is most likely invalid data, and really should happen to be caught at data entry time. Bad is data usually come to be equal to corruption triggered by disk errors etc. The previous are very common, based on the standard from the data input programs, as the latter are pretty rare.