International Database Mistakes

While English is the common language of global business, you cannot always be sure that every piece of data you need to store will be in English. Other countries have their own ways of writing dates, unique currency symbols, and addresses. There are a number of international issues to watch for to ensure your data can be stored and processed correctly:

1. Using an RDBMS that can't handle all necessary languages
2. Working with data stored in different formats

Most data generated in the United States will be in English, though there are literally millions of citizens whose first language is not English. If Stories on CD wants to expand its client base beyond native English speakers, they can offer CDs with stories presented in Spanish (with the letter ñ), French (with accented letters like é), or any number of Asian languages which do not use the Roman alphabet. Most recent versions of popular RDBMSs should work with any of these character sets, but you should check the system's documentation to be sure.

One simple yet significant difference between the U.S. and Europe is a difference in how we write dates. Americans put the month first, so 7/12/2000 means July 12, 2000. Europeans write the day first, however, so the same entry would be read as December 7, 2000. Other examples of data incompatibilities are phone numbers (the U.S. and Canadian system of a three-digit area code, three-digit exchange, and four-digit extension isn't replicated throughout the world), addresses (Canada uses a different form of postal code, e.g. T2G 3Y5), and currency symbols.
The next lesson addresses the process of evaluating a database.

This problem is closely related to Thinking too Small and Too Much Normalization. Some developers perform little or no testing before releasing a database into the wild. They run through a few tests to check correctness (the better ones go through all of the use cases) and assume that everything will work in the field. Then when customers try to use it under realistic conditions, the whole thing falls apart. They discover bugs that the testers missed and the performance is unacceptable.
Be sure to test the database and any attached applications thoroughly. Fully testing every nook and cranny of a system takes a lot of work, but it’s necessary. You need to be sure you exercise every piece of code, every table, and every constraint. You also need to perform load testing to see if the database can handle the expected load. If you do not find all of the bugs and bottlenecks, sooner or later the user will, guaranteed!
It is also pretty safe to assume that every non-trivial application contains at least some bugs no matter how much testing you perform. In that case, you cannot find every bug so you may be temped not to even try. The goal is not really to catch every bug, but to find enough of them and to find the most likely to occur so the probability of the users finding a bug is very small. The bugs will still be hiding in there, but if you only get one or two user complaints per year, you’re doing pretty well.

Before moving on to the next lesson, click the Exercise link below to reinforce your knowledge of international issues.
International Issues-Exercise