On 5/31/05, Paul Hastings <[EMAIL PROTECTED]> wrote: > John Paul Ashenfelter wrote: > > distributed, in-memory redundant databases to the table. And if you > > need to internationalize your application, there is simply no > > competition with MySQL as far as support of mutliple character sets > > and collations at the *column* level. > > sorry, no, that's not going slide to on by. mysql *just* got unicode. > having a plethora of encodings is not a good thing for real i18n work. > you always want unicode to simplify things & mysql was, until the latest > version, kind of joke for that kind of complex i18n work.
There's a difference between unicode support (which came into MySQL last year in the 4.1.x branch) and supporting character sets and collations, which is not a joke at all. Now it may be a bit of a joke that MySQL ships with the Swedish collation on by default (of course the company's Swedish....). I'm not so sure you *always* want unicode the way you claim though I'll concede the point for i18n -- but not necessarily for l10n (localization). > sql server has > been able to do unicode & has been able to use any collation it knows > about since 7 (you can cast to a collation via the COLLATE clause). Sure you can cast to a collation in MS-SQL (of course you have to be careful about the underlying collation of the server so you know when you need to cast, right?). But to change the server character set, you have to rebuild your databases. In MySQL I can change it at the *column* level using ALTER TABLE. I can change the collation at the column level the same way. And I can use a complete set of functions for managing the casting in the SQL itself, just like MS-SQL. Let's say you're building a data warehouse -- doubling the size of the text columns in the fact tables (from varchar to nvarchar) to make them unicode as opposed to using the correct character set makes a noticable difference in size. If I've got a German client, I'd rather use the appropriate character set for the varchar columns instead supporting unicode; but if I have a mix of Cyrillic, Western, and Big5 data I'd certainly use Unicode just like I would in MS-SQL. I think it's probably fair to say that dealing with Windows code pages as far as they interact with MS-SQL is a pain in the butt though -- (I ....fondly....NOT... remember running the German version of Windows to support a German install of MS-SQL that had to be pulled into our English MS-SQL data warehouse...) I'll happily let that stuff live in the MySQL binary so I don't have to worry any further down the application stack about settings and configuration. -- John Paul Ashenfelter CTO/Transitionpoint (blog) http://www.ashenfelter.com (email) [EMAIL PROTECTED] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:208112 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
