SSWUG.Org Virtual Workshop: Query Plans and Processing – Tomorrow
This Friday, January 21, from 9AM – 12PM PST
Here’s your opportunity to get a handle on making your queries work for you. Kalen Delaney, a name well known for things SQL Server will be hosting this workshop. That alone makes it worth the time.
This is definitely the real thing. Kalen provides authoritative, in depth understanding about what makes your queries work, and how to improve performance with the tools available right out of the box.
Select Views At by the Fire
You gotta come check out the new layout with the SSWUG fireside chat. See Steve as he talks about some of the new features coming up in SQL Server 2011. He’ll also bring us some SQL Server tip, recent news and more. Better than going to the winter Olympics.
[Watch the Show]
Featured Script
GetTbColValues
This stored procedure can be used to return all tables and table’s columns, which contain the particular text value. The Get… (read more)
Internationalization Ideas
I did receive some feedback on Internationalization. Some good points were made about the fact that much of the Internationalization requirements are not necessarily a database issue. I agree very much.
There are some things that can impact your schema or even the way you the data within your schema.
Dates:
Store the date you receive from real world data in the time zone the event was created
Translate dates into a standard such as the local time of the corporate office, or GMT. Then translate the date/time back to the appropriate localized value. But, what do you store in your database.
Create some kind of date/time dimension in your database, and simply point data to the correct dimension record. Let the dimension handle all date/time conversions.
Store date and time as the local value, and also store the time zone for the data, so that it can be converted to any other date/time zone.
Money
Always convert….Convert always from/to corporate standard, store all currency in corporate standard form.
Store in native currency, and only translate when needed to any other currency.
Store in native currency, and translate to corporate standard and from corporate standard to a different currency (if not corporate standard)
Translate and store in all supported currencies, and select the desired currency when outputting so the translation is only done once during storage.
Addresses
Lots of ways to skin this cat. I have found that a master address table that has four columns for LIne1-Line4 and a column for the localization works as a start. Everything is formatted in the four line columns according to the location. Then, since we search on address data, a sub-type table is used for each localization supported. Those tables have columns specific to the local. The US, for example, has City, County, State, Zip Code. External functions are used to format the contents of line1-line4 based on the local.
Presentation
Style Sheets or even reference files may be used for presentation. However, it is often useful to modify your database to have pointers to these presentation sources rather than relying only on a browser for the presentation pieces to be used.
Character Data
Are you going to support oriental languages. If so, you have to use Unicode character data types in your storage. If not, you can save a LOT of space by not using the Unicode character data types. Mixing can have a huge impact on performance if you have to compare or sort mixed character data types.
As you can see, internationalization is not a database only problem, but, your database will be impacted by your implementation of internationalization. It can really impact the performance of your application if you don’t think about it.
Here is a response from one of our readers on this topic.
Kent replies:
Excellent points. Programming languages are pretty universally US-centric in terms of their natural-language antecedents. I often think about this when looking at the wealth of helpful forum posts by our international colleagues: they’re pedaling uphill.
Some of the factors you cited are better dealt with in the application layer, probably. But in order to facilitate that, the database layer should be designed with it in mind.
Based on my own experience, I can make this recommendation: select a non-US vendor, and it’s far more likely that you’ll get a platform with currency, date, and language variability “baked in.” Concepts like VAT and other transactional elements not common in US-style business also tend to be present already. I’ve worked with three different publishing systems (one each British, Russian, and Norwegian) and they all have such Easter Eggs. Furthermore, internationalization is a good reason to look closely at open-source options, because their developer communities are global. They live and breathe things that feel like extra requirements to many of us who learned our craft exclusively in the US.
Keep the good stuff coming.
Do you have other insight you’d like to share on the topic? Please send your comments to btaylor@sswug.org.
Cheers,
Ben