Learning Mandarin vs Cantonese

I had a former colleague ask me the other day if he should learn Cantonese or Mandarin. He was going to spend a few months in Hong Kong and southern China.

Here are my opinions. I’m sure there are many who might differ but this is how I see it today.

Hong Kong is a tricky one. A large number of people there can speak Mandarin given the difficult relationship between “mainland” China and Hong Kong, even locals who can speak it don’t treat you the same as if you speak Cantonese. Many just aren’t happy about aspects of how China now runs Hong Kong. But the way that I see it, is that resist as they might, they will be “integrated”.

In the meantime, and probably for another generation, Cantonese is certainly where it’s at. Already though, China makes all children in Hong Kong learn Mandarin.

People don’t seem to understand how determined the Chinese government is to achieve standardisation. In the end, it’s the only way you can run such a large country without anarchy. They even have a single time zone for the whole of China. I can’t see any chance of them supporting 900 or so dialects going forward. It would probably scare the Cantonese speakers today to think about it, but I think that eventually Cantonese will be like Aboriginal languages are in Australia: more of a curiosity. Clearly, that will take some time.

Personally, I wouldn’t put any effort into Cantonese but you might decide differently if you are intending to be in a majority Cantonese-speaking country for quite a while. You certainly get treated better by locals if you use at least some of their dialect. Same thing happens in Shanghai. Add some Shanghai-ese into your Mandarin, and they are so happy.

Another thing I’ve liked about learning Chinese is that the writing system is essentially the same for all dialects. So even when I see signs written in Hong Kong, I can still read most of it. I have no idea what the words are in Cantonese (although I can easily guess some), but I know what the sign means, and that’s what counts the most.

The challenge with Chinese reading and writing is simplified vs traditional systems. In the 1950’s and 1960’s, the Chinese government decided to simplify the writing system as they had so many people that were illiterate. So they took a bunch of characters and made simplified versions of them. The simplified ones are now used widely. However, once again, Hong Kong is a hold-out. Most people in Hong-Kong or Taiwan still use traditional characters. So there are some characters that I have to stop to try to work out what they are.

The younger people in Hong Kong are learning Simplified characters. Other countries like Singapore have standardised on Simplified. Even in the middle of China, however, there are movements to try to reinstate Traditional characters as they are seen as more meaningful. I can’t see that prevailing and simplified characters will be the future.

Most older Chinese writing that I see in Australia is Traditional as many of the Chinese that originally came here did so from Hong Kong, and many came before Simplified writing was introduced. Most new Chinese that you see in Australia is Simplified. That’s what all the Chinese tourists and students tend to use. When I ride the trains in Melbourne, I used to predominantly hear Cantonese. Now I predominantly hear Mandarin, largely due to an influx of people from other areas of China, and particularly due to younger students.

I’ve been using a variety of methods for learning Mandarin over the years. My main effort at present is to attend 3 x 1 hour one-on-one lessons from Hanbridge Mandarin each week. (http://www.hanbridgemandarin.com)

I’ve got other posts that I’ll update soon, on the other methods that I’m using, but the online lessons (my current teachers are from ShenZhen) have increased my abilities the fastest of any method that I have tried.

And I just speak to every Chinese person that I get an opportunity to do so.

SQL Down Under Show 66–Riccardo Muti and Chris Finlan–SQL Server 2016 Reporting Services

Hi Folks,

I recently got to record a new podcast with Riccardo Muti and Chris Finlan from the SQL Server Reporting Services team.

Over recent years, Reporting Services seemed to be in a rut without forward momentum.

2016 however promises to be a really big year for Reporting Services.

You’ll find the show here: http://www.sqldownunder.com/podcasts

Enjoy!

R Tools for Visual Studio

In recent months, I’ve been brushing up my R skills. I’ve had a few areas of interest in this:

* R in Azure Machine Learning

* R in relation to Power BI and general analytics

* R embedded (somewhat) in SQL Server 2016

As a client tool, I’ve been using RStudio. It’s been good and very simple but it’s a completely separate environment. So I was excited when I saw there was to be a preview of new R tooling for Visual Studio.

I’ve been using a pre-release version of R Tools for Visual Studio for a short while but I’ve already come to quite like it. It’s great to have this embedded directly within Visual Studio. I can do everything that I used to do in RStudio but really like the level of Intellisense, etc. that I pick up when I’m working in R Tools for Visual Studio.

So today I was pleased to see the announcement that these tools have gone public. You’ll find more info here in today’s post from Shahrokh Mortazavi in the Azure Machine Learning blog: https://blogs.technet.microsoft.com/machinelearning/2016/03/09/announcing-r-tools-for-visual-studio-2/

Data Tales #7: Database on a diet (part 2)

Hi Folks,

My series of articles for SQL Server Magazine continues. Last month, I started a short series about a large database that needed to go on a diet. This month, I look at a bit of the internals of row and page compression, to see what happens with you use this.

http://sqlmag.com/database-administration/data-tales-7-case-database-diet-part-2

Enjoy!

Extra Power BI single day course in Melbourne May 10th

We normally run our Power BI Core Skills class as the 2nd day of the week in our 5 day BI Core Skills.

We’ve had extra demand for the Power BI day so we’ve added an extra one in Melbourne on May 10th. Details are here: http://www.sqldownunder.com/Training/Courses/20

image

Early bird pricing ends April 26th.

Interesting to get a report card–more on learning Chinese

I’m continuing to learn Chinese (Mandarin) in my spare time. (Although I’m not sure I really have any).

This year I made a change in how I’m doing things. I decided to give the team at Hanbridge Mandarin a try. I’m doing online Skype/Webex based video classes 3 times per week for about an hour, one on one with a teacher. Teachers for Hanbridge mostly seem to be ShenZhen based.

It continues to be fun to keep on with my learning. Last year I managed to pass HSK3 and this year I plan to take the HSK4 exam. I’m a little concerned about it as each level seems to get twice as hard as the previous level. HSK5 seems to be about the level required for university entry in China.

One thing that I’ve found interesting with Hanbridge is that they send a report card every few months. It feels like being back in school. I was happy with this one and am looking forward to expanding my abilities this year.

image

BETWEEN vs >= and <=

I love it when I get queries that are actually easy to answer.

Today, one of my developer friends asked me if it was better to use BETWEEN or to use >= and <= when filtering for a range of dates.

From a logic perspective, I like the idea that a single predicate expresses your intent rather than needing two predicates to do the same. For example, consider the following two queries:

image

I’d argue that the first one expresses the intent slightly more clearly than the second query. The intent is to find orders in a particular range of dates. Having that as a single predicate expresses that intent slightly more clearly than having to assemble the intent from multiple predicates. At least I think so.

But the bigger question is about performance. It’s easy to see that they are identical. If you enter the following query against the AdventureWorks database:

image

Then request an estimated execution plan (Ctrl-L), you’ll see this:

image

 

The missing index warning isn’t relevant to this discussion and if you hover over the Clustered Index Scan, you’ll see this:

image

Note under the Predicate heading that SQL Server has converted the original BETWEEN predicate into a pair of >= and <= predicates anyway. You’ll find it does the same for LIKE predicates as well. LIKE ’A%’ becomes >= ’A’ AND < ’B’.

So performance is identical. It’s more of a style issue, and I think that BETWEEN is (only very) slightly more expressive so I’d prefer it.

UPDATE: Aaron Bertrand posted a pertinent comment on this. I would only lean to using BETWEEN if I’m strictly working with dates or other types of discrete values (ints, etc.), not with datetime values that actually contain times. If that was the case, I’d definitely lean towards the separate predicates.