| Author |
 Topic  |
|
|
work mule
Senior Member
USA
1358 Posts |
 Posted - 17 September 2002 : 17:14:03
|
If you use Snitz and SQL Server 7/2000, you may want to evaluate whether or not you need to use Unicode data types for your forum.
If you don't need to support Unicode, then you might want to consider converting your Unicode data types to the traditional data types. This can help increase performance and reduce storage requirements for your database. This is especially important if you're paying for SQL Server disk space. Seriously, if all of your members (or majority) of your members use English (or languages which don't require Unicode support) you may want to ask if it's worth the extra cost to use Unicode data types, especially if you're on a limited budget or limited disk space.
Storage Requirements:
Traditional Data Types (1 byte per character)
char, varchar, text
Unicode Data Types (unicode uses 2 bytes to encode each character)
nchar, nvarchar, ntext
To make the change before setting up Snitz, do a find and replace in your setup.asp file and replace all instances of nchar with char, nvarchar with varchar, and ntext with text. If you already have your database setup, then you'll have to do a little bit more work (but worth it).
(excerpt):
International Features in Microsoft SQL Server 2000
http://msdn.microsoft.com/library/default.asp?URL=/library/techart/IntlFeaturesInSQLServer2000.htm
Storage Space Issues
The actual amount of space required for the Unicode data types is 2 bytes per character, and the amount of space for the non-Unicode data types is 1 byte for all non-DBCS text and 2 bytes for Asian languages that use DBCS. Therefore, unless your data is on one of the Asian code pages, you will be using twice as much space to store the data. This must be considered when you upgrade existing databases or when you are deciding on the proper data types of new projects. If you are storing data only in a column that is on a single (non-Asian) code page, you might prefer to not use Unicode so you can save the space on disk and in memory.
Speed Issues
The speed issue is a complicated one. Here are some of the issues:
- If you are running on Windows NT or Windows 2000, the kernel is expecting Unicode data, and thus non-Unicode columns will have to be converted in many cases, such as when you display data or use the operating system services.
- There is the additional time needed to load the larger amount of data that must also be considered when you are dealing with DBCS data.
- If you are dealing with a Windows 95 or Windows 98 client or server, much of the information can also face conversions from Unicode when operating-system services, such as data display, are needed.
- If you are working between servers (see Communication Between Server and Client later in this article), database server products, or other products, the number of conversions can also play a great role in the performance battle.
- If you are dealing with Asian languages, Unicode will actually be faster than using the language-specific DBCS code page. This is because DBCS data does not have fixed width; it is a mixture of double-byte and single-byte characters.
- If you are dealing with non-Asian languages, sorting Unicode data can be up to 30-percent slower than non-Unicode data. This can be considered one cost of being able to represent global data.
Important: To realistically evaluate a performance issue, you must test to get conclusive data about the situation.
Moved from the Help: Database: MS SQL Server by Ruirib |
Edited by - ruirib on 17 September 2002 19:37:58 |
|
|
Deleted
deleted
4116 Posts |
Posted - 17 September 2002 : 17:36:42
|
Although these are correct, using unicode is not avoidable if you want to go global. Instead of optimizing for today, I'd like to design for tomorrow  .
For Access users: If you use Access 2000 or Access XP, you already use unicode (no, you cannot avoid it).
|
 Stop the WAR! |
 |
|
|
pweighill
Junior Member
United Kingdom
453 Posts |
Posted - 17 September 2002 : 18:11:44
|
| If you setting up a new forum, and want the varchar and text data types, rather than the nvarchar and text, then select SQL Server 6.5 when asked which version you are using. |
|
|
|
work mule
Senior Member
USA
1358 Posts |
Posted - 18 September 2002 : 03:05:48
|
quote:
Originally posted by bozden
...using unicode is not avoidable if you want to go global.
I'd expect nothing less coming from the Internationalization Moderator. 
Snitz appears to have a pretty good variety of people from all around the globe. Maybe I'm wrong, but it would seem that English is used quite extensively here.
The point I brought up initially, is really directed to forum owners who don't plan on supporting a forum which allows people to post in any language. If someone doesn't plan on allowing for members using other languages besides English or even the Latin-1 character set, then they could save themselves a bit of disk space, possible save on hosting fees depending on the size of the database and their host's plan, and maybe benefit a bit on the performance of their database.
Latin1 covers most West European languages, such as French (fr), Spanish (es), Catalan (ca), Basque (eu), Portuguese (pt), Italian (it), Albanian (sq), Rhaeto-Romanic (rm), Dutch (nl), German (de), Danish (da), Swedish (sv), Norwegian (no), Finnish (fi), Faroese (fo), Icelandic (is), Irish (ga), Scottish (gd), and English (en), incidentally also Afrikaans (af) and Swahili (sw), thus in effect also the entire American continent, Australia and much of Africa.
http://czyborra.com/charsets/iso8859.html
I think that for some people that would pretty much cover it.
For anyone who wants to read more about Unicode, here's a good place to start. http://www.unicode.org/
|
|
|
|
n/a
deleted
593 Posts |
Posted - 19 September 2002 : 16:50:23
|
Most of international Snitz designers or users are using in a single locale language envionrment (a la my impression).... whether they are in Latin 1 group or other ISO group language enviornment - including Japanese, Chinese, etc. and at best, along with English. Other ISO group, like Japanese, contains Latin 1 charsets as a base, so actually, you really don't need to have a unicode (utf8, double byte unicode) enviornment to accommodate a "bi-lingual" enviornment, at least if it is in a locale-US English combo, since defaulting to a Japanese or Chinese, for example, you can use both JA or CZ along with English. If you base your default encoding with English, this is not possible, as Latin 1 do not contain other extended charsets or special chars exist in other ISO groups.
So, yes, you really don't need to use Unicode, if you are dealing with a single locale language envionrment (think English as one of the locales). Your point is quite correct for the reasons you mentioned, though.
Unicode (esp. UTF8 and above) are designed and best suited for handling "multilingual" contents with a single charset encoding system (unicode charset) rather than deploying n x locale ISO encoding system.... so more languages you handle and more complex the contents, unicode becomes more effective.... as a general rule.
Also, M$S is deploying unicode (UTF8) as a core internal encoding system for their sw and apps - like ACCESS 2000 and all .NET Framework now.... ASP.NET will be, as I understand, supporting/using UTF16 while using UTF8 internally....So, unicode seems to be increasingly getting into server side arenas as well... (Well, M$S is designing their product offerings on an increasingly globalized platform...) so, seems like you cannot avoid unicode implementation issue.
|
Taku
|
|
|
| |
Topic |
|
|
|
Topic Locked
