More, smaller databases? Manage your checklists, our featured blog of the week for business intelligence…Also, the hotmail outage and SQL Server, 3rd party tools and more.
[Watch the Show]
Special Fireside Version: SelecTViews – SQL Server 2011 upcoming features, SQL Server tip, recent news and more.
[Watch the Show]
Devin Knight on the show today talking about dynamic security inside of Analysis Services. Also, hear from Rick Pleczko of Idera about some exciting capabilities and features that are now in production.
[Watch the Show]
Featured Script
Reordering Primary Keys
An example of a brute-force method, meant for one-time use (on DB migration). User is responsible for switching columns out … (read more)
Internationalization in SQL Server
Creating a database that may be used in more than one language or country has interesting implications.
Looking only at languages that don’t require Unicode data types in order to provide enough characters there are still enough differences in database development. For example, write a stored procedure in English. Must our German, Spanish, Latin, Greek, and the huge number of talented friends with other languages learn and/or translate English in order to understand the code that was written?
Obviously, the object names for tables, columns and programmables generally reflects an action or noun for the language in which it is written. So, taking an English language database and writing code for it in Spanish would be similar to writing code working with a database that is obfuscated. It would be like working with the MS Accounting software that had all stored procedures, views and tables named with a number or code. You needed a dictionary to decrypt the table, columns etc.
Even still there are other issues at hand you must take into account. For example, when working with dates, different countries use different methods and order of precedence when displaying a date.
You don’t have to be in the software industry for long to know that the issues with Internationalization are bigger than database code and code techniques. We have issues with the different addressing and phone number schemes used from one country to the next. Currency is managed differently as well. Creating a database that handles more than one of these capabilities is a skill in itself.
Often we have an instance of a database that may handle one of many different cultures. But the difficult database is the one that must maintain data from multiple cultures, and translate the data into that of another culture. Examples of this might be Time Zone Conversion, so that if I enter a customer order at 18:00 Pacific Time, I am able to display that order to someone in Tokyo at their native time without them having to calculate the time difference.
Other hurdles may be currency conversion. An order placed in British Pounds may need to be converted to the Euro, the Yen, etc. This conversion may not be a static value; it may depend on the exchange rate at a point in time, or calculate differently based on the exchange rate over time, or even a projected exchange rate.
I’d be really interested to hear from those of you who are actually working with true Internationalized databases. What are the kinds of hurdles you have had to manage? What kinds of solutions do you find effective? Are there third party products that made the design better? Anything you would recommend to our readers in this regard?
Send your tips or comments to btaylor@sswug.org.
Cheers,
Ben