July 2012 - Training for MySQL in Brisbane, Sydney and Canberra

 

Hi Visitor, and welcome to the July 2012 issue of the Open Query Newsletter.

In this issue:

  • short news
  • training with "BYO laptop"
  • training schedule
  • events
  • tip: Internationalisation (i18n)

 

Short News

With the closing of the financial year now out of the way for our clients in Australia, we have a special focus this month on our upcoming training courses, including a new format.

Do you follow the Open Query blog? We recently identified security issues with one-way password encryption as used in many applications. Following us on Twitter (@openquery) is a good way to catch new posts and other topical items we identify. After all, this newsletter is only monthly.

 

Training with "BYO Laptop"

For our public courses we've generally worked in training facilities and preconfigured computers. While that still works best for some of the modules (for instance our backup & replication workshop), it's not always necessary. So, depending on the topic, location and combination with other modules, we're going to be offering "BYO laptop" course days. As we then pay less for the facilities, this works out up to 40% cheaper for you! It does of course mean that for those days, bringing your own laptop is not optional but a pre-requisite. You have to make sure you have a working basic MySQL setup on your laptop to be able to participate in the course day.

 

Upcoming Training Schedule

We currently have a number of Developer and DBA course days scheduled in Sydney, Canberra and Brisbane. MariaDB and related enhancements are of course covered as well as stock MySQL Server. You can register for Open Query course days/modules individually to suit your time, budget and current needs. Your trainers for these days are Daniel and Arjen.

Secure your seat today!

Sydney

Canberra

Brisbane (BYO laptop)

For bookings and questions, contact us today! All prices excluding GST.

 

Upcoming Events

  • Hobart TAS Australia 17-18 Aug 2012: PyCon Australia 2012, the national conference for users of the Python programming language. No specific sessions, but you can meet up with our engineer Daniel Black.
  • Cairns QLD Australia, 2-5 Oct 2012: SAGE-AU 2012, the annual conference of the Australian System Administrators' Guild. Arjen will be teaching a tutorial "MySQL Administration and Tuning Treasures".
  • Brisbane QLD Australia, first Tuesday of the month: Brisbane Web Tech meetup, incorporating MySQL and many other relevant technologies. Arjen co-organises.

 

Tip: internationalisation (i18n)

Our general guide on "what character set should I use?" is to stick with latin1 (swedish_ci collation) unless you have to deal with other languages that require UTF-8 for proper handling. This because MySQL's architecture allows you to gain speed, storage and RAM advantages when using purely latin1. But when you need UTF-8, of course that's fine. You don't want to just stuff UTF-8 into latin1 fields!

When choosing utf8, it's preferred to do so on a server-wide basis. Architecturally and in line with the SQL standard, MySQL allows you to have different character set and collation settings on the server, database, table and even column level. But that really makes no sense from a maintainability perspective. We generally advise to set UTF-8 for an entire application, which means either the database or the server level. In some cases, it does make sense to have some tables use a different character set.

Your application, and tools like mysql command line client and mysqldump, all need to make sure that the connection is also using UTF-8 encoding. Otherwise data can still get mangled. From applications the SQL command "SET NAMES=UTF8" should be executed immediately after opening a connection. From the command line clients, --default-character-set=utf8 takes care of that. If you don't have this, chances are your SQL dumps or restores are not actually clean!

Finally, if you use PHP, use the mysqli extension and mysql_real_escape_string() as the old mysql_escape_string() is not character set aware, and also remember to use the appropriate multi-byte string functions as the built-in string functions of PHP are not UTF-8 safe. Apart from mangling data, incorrect processing of query data could result in security vulnerabilities!

If you feel uncomfortable with character sets and collations but you need to deal with them in your application, just ask us for help. We've done all this stuff many times before.

 

Until next time!

Feedback welcome through http://openquery.com/contact
You can also access this issue online: http://openquery.com.au/newsletter/2012-07, other issues can be viewed at http://openquery.com.au/category/newsletter/open-query-newsletter-2014news1l6

 

-- the OQ team

We aim to keep our newsletter in plain text, apart from links. If you're reading the Open Query Newsletter online or received it via someone else, you can subscribe for your own copy through http://openquery.com/user/register and http://openquery.com.au/newsletter/confirm/add/