International Database Mistakes

English may be the common language of global business, but you can't assume every piece of data your database ever needs to store will arrive in English, or fit the assumptions English-speaking, US-centric design tends to bake in by default. Other countries write dates differently, use different currency conventions, structure names differently, and format addresses in ways a US-shaped schema simply doesn't accommodate. This lesson works through the specific mistakes that show up when a database gets designed around one culture's assumptions and then has to expand beyond them — covering language and character encoding, date and data formats, name structures, addresses, and currency, one at a time.

The United States is a large market — but it's only one member of a much larger global community. Alongside a growing multicultural population within the U.S. itself, the internet has made it dramatically easier for customers anywhere in the world to buy from anyone anywhere else. It's genuinely possible for it to cost more for a customer in South Africa to buy a book from a store in their own country than to order the same book from a U.S. retailer and have it shipped to Johannesburg. You can't plan for every contingency in advance — but if your database has any commercial presence on the web, accounting for that global community in your design isn't optional, it's just part of doing the job correctly.

Most data generated in the United States is in English — but millions of U.S. residents have a first language that isn't English, and that's before you consider customers outside the U.S. entirely. If Stories on CD wants to expand beyond native English speakers, it needs to offer CDs with stories in Spanish (with letters like ñ), French (with accented characters like é), or any number of Asian languages that don't use the Roman alphabet at all. Most current relational database systems handle all of these character sets without difficulty — but "should work" isn't the same as "verified to work," and it's worth checking your specific system's documentation rather than assuming.

There are two related but distinct technical concepts hiding behind "does this database handle other languages correctly": character encoding, which governs how text gets stored as raw bytes, and collation, which governs how that text gets sorted and compared.
Get encoding wrong, and the damage is immediate and visible. A legacy encoding like Latin-1, or an encoding that doesn't allocate enough bytes per character — MySQL's plain utf8 setting, notably, doesn't reserve enough space for the full range of Unicode characters, unlike its own utf8mb4 variant — will silently corrupt non-Latin characters and emoji into unreadable garbled text, a failure mode commonly called "mojibake." The fix is to standardize on full UTF-8 (or utf8mb4 specifically, if you're on MySQL) consistently across the database, every table, every column, and the connection string your application actually uses to talk to it — a mismatch at any one of those levels can reintroduce the exact same corruption even if everything else is configured correctly.
Collation is the quieter problem, because it doesn't corrupt anything — it just sorts incorrectly, which is easy to miss until a local user notices their own name is sorting in the wrong place. Without the right collation setting, a database might sort "Z" before "Ä" (A-umlaut), which is simply wrong by the conventions of languages that treat accented letters as belonging near their unaccented counterparts. Encoding determines whether the data survives intact; collation determines whether it makes sense once it's displayed.

One simple but genuinely significant difference between the U.S. and much of the rest of the world is how dates get written. Americans put the month first, so 7/12/2000 reads as July 12, 2000. Most of Europe writes the day first, so that exact same entry reads as December 7, 2000 — the identical string, two different dates, depending entirely on which convention the reader assumes. Store dates as ambiguous strings instead of using your database's actual date type, and you've built that ambiguity permanently into your data.

Other data formats carry the same kind of hidden assumption. Phone numbers built around the U.S./Canada pattern — a three-digit area code, three-digit exchange, four-digit line number — simply isn't how phone numbers are structured everywhere else in the world. Canadian postal codes (T2G 3Y5, for example) are alphanumeric, not the numeric-only ZIP code pattern a US-first schema tends to assume by default.

The single most common internationalization mistake in real applications is storing timestamps — an order date, a log entry, anything time-stamped — in local time, whether that's the server's local time or a user's. It seems intuitive at first: the timestamp matches what the person actually saw on their clock. The problem shows up later. If the user travels, if daylight saving time shifts, or if you ever move your servers to a different region, that timestamp loses its absolute anchor in time entirely — and sorting events chronologically across users in different regions becomes genuinely unreliable, since "14:00" means something different depending on which local time zone produced it.

The fix is straightforward: always store the absolute moment in time as UTC. If you also need to know what time the user actually experienced — for display purposes, say — store their time zone identifier (America/New_York, for example) in a separate column, and convert for display at read time rather than baking a specific local time into the stored value itself.

Assuming every person has exactly one first name and one last name is a distinctly Western assumption, and it doesn't hold globally. Cultures that use mononyms (a single name), patronymics, or name orders where the family name comes first will all break against a schema that strictly requires separate first_name and last_name fields — and the practical result is users typing fake data like "N/A" into a field just to get past a validation rule that was never designed with them in mind.

The more resilient approach is a single full_name column for display, billing, and shipping purposes — the actual string a person wants to be addressed by, stored as-is rather than decomposed into parts that don't universally apply. If a legal or regulatory requirement genuinely forces you to split names into components, keep those fields flexible and nullable rather than mandatory, so the schema bends around real name structures instead of forcing every name into a Western template.

Addresses carry the same kind of hidden assumption as names. Requiring a "State" field and a numeric ZIP code causes immediate friction the moment an international customer tries to sign up: many countries don't organize their addresses around states or provinces at all, and postal codes elsewhere — the UK's SW1A 1AA, or Canada's T2G 3Y5 mentioned above — are alphanumeric and often contain spaces, not the five-digit integer a US-shaped schema tends to assume.

The fix is the same pattern as the name-structure fix: generic, nullable columns — region_or_province instead of "State," and postal_code stored as a VARCHAR, never an INT — with actual format validation handled in application logic, driven by a country_code field, rather than baked rigidly into the column's data type or a fixed-length constraint.

Currency symbols are one more area where formats diverge across countries — but the deeper mistake goes beyond symbols entirely, down to how the actual monetary value gets stored. A system that stores money as a simple FLOAT, assuming the currency is always USD or always EUR, has two separate problems layered on top of each other. First, FLOAT introduces genuine precision loss through binary approximation — the exact kind of rounding error that makes accountants justifiably nervous about financial data stored this way. Second, and just as serious: a bare amount like 1000 means nothing on its own without knowing whether it's yen, pesos, or dollars. If you later need to support a second currency, you have no reliable way to distinguish which currency your existing historical data was actually recorded in.

The fix has two parts, and both matter: use exact numeric types (DECIMAL or NUMERIC, never FLOAT) for any monetary value, and pair every financial amount with an explicit ISO 4217 currency_code column in the same table — so 1000 and USD travel together, permanently and unambiguously, rather than the currency being an assumption baked into application code that can silently change out from under old data.

Taken together, these mistakes share a common root: a schema built around one culture's defaults — one language, one date format, one name structure, one address shape, one currency — that works perfectly until the moment real international data arrives and the assumptions underneath it turn out to have been assumptions all along. Designing with those assumptions loosened from the start, even for a database that begins with a purely domestic audience, costs very little up front and avoids exactly the kind of devastating, late-stage refactor that retrofitting internationalization support almost always requires.

The next lesson addresses the process of evaluating a relational database.

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