Cheater is a tool that can generate random database based on rules. It's being widely used within the LineZing team of Taobao.com.

Compared to other similar tools, cheater has the following advantages:

it can automatically handle the association and foreign key restrictions among data tables, so it's the real "database instance generator".
It defines a SQL-like little language to specify the data model that we want to generate from.
It supports powerful {a, b, c} discrete enumation sets, numerical/time/date interval syntax a..b, Perl regular expressions /regex/, constant values 'string', 1.32, and etc, to describe the value range of data table field.
It can generate JSON or SQL insert statements to ease importing to RDMBSes like MySQL/PostgreSQL.

In this MySQL forum post, Erik runs into the confusing situation whereby he has to tell mysqldump to use the Latin-1 character set in order to get UTF-8 output. Bizarre magic? Well, no.

In any database-driven application, the encoding needs to be specified in several different places. If you’re a good developer, you’ll be using some Unicode encoding, quite possibly UTF-8. The problems arise when you send those UTF-8 bytes to your database.

It used to be the case (I don’t know if it still is) that the default encoding used by MySQL, unless you specified otherwise, would be Latin-1 (the collation rules applied would be those for Sweden, incidentally). Out of the box, with the defaults left alone, all of the text fields in all of your tables will be specified as containing Latin-1. In addition, your database connections will also use Latin-1. Amazingly, though, everything will seem to work.

Good is the enemy of Great
Latin-1 is the enemy of UTF-8
You write web apps. You understand the web is global, and want to support internationalization. You want UTF-8.
UTF-8 is extremely sane. Well, as sane as an encoding can be that features backwards-compatibility with ASCII.
Everything you care about supports UTF-8. Trust me: you want it everywhere.
Problem is, every last part of the web-application stack will fight you on your quest towards UTF-8 purity. What follows is a playbook to win your pervasive-UTF-8 battle.

I am not having any trouble if I always use /Applications/acquia-drupal/mysql/bin/mysql -u$username -p$password $dbname when trying to work with a database on the DAMP stack and remember to use /usr/local/bin/mysql/bin/mysql ( the default) at other times.

Thanks!
That command line parameter actually works - well, you have to use double dash (--) like this:

mysql -h host -u username -p password --default_character_set utf8 database < file.sql

Silly me hadn't tried it before because I'd read in a forum that it only applies to the connection and the database - not the file :-) Maybe that was true in a previous version of mysql...
Now it works!

If you haven't already heard, Drupal 7 will default to using the InnoDB storage engine instead of MyISAM for MySQL (though a MyISAM database will continue to work just fine in Drupal 7). This is fairly substantial change within Drupal core, and as the thread in the issue queue I linked to shows, there were a lot of questions and apprehension about it. However...

...we are going to just skip over a lot of that apprehension and get down to point of this article - there's no good reason not to hop right into using InnoDB today on your Drupal 5 or Drupal 6 site. The rewards are; a possibly significant improvement in performance, a definite improvement in scalability (most highly trafficked Drupal sites have been using InnoDB for some time now because of this), and you'll start getting used to working with what will be more and more common in your Drupal-life, InnoDB.

I mentioned earlier on Twitter that my home computer downloaded a 22 GB database dump every three days as part of Instapaper’s backup method, and a lot of people expressed interest in knowing the full setup.

The code and database are backed up separately. The code is part of my regular document backup which uses a combination of Time Machine, SuperDuper, burned optical discs, and Backblaze.

The database backup is based significantly on MySQL replication. For those who aren’t familiar, it works roughly like this:

The “master” database is configured to write a binary log (“binlog”) of every change it makes to the data.
A snapshot of the entire database is taken, noting the current position in the binlog, and copied to the “slave” server.
The slave server can then start itself up with that snapshot, knowing what binlog position it needs to start from, and continuously stream the binlog data from the master, replicating every change that the master makes, to keep itself up to date.
And the binlogs can be decoded, edited, or replayed against the database however you like. This is incredibly powerful: given a snapshot and every binlog file since it was taken, you can recreate the database as it was at any point in time, or after any query, between the time it was taken and the time your binlogs end.

Suppose your last backup was at binlog position 259. Someone accidentally issued a destructive command, like an unintentional DELETE or UPDATE without a WHERE clause on a big table, at binlog position 1000. The database is now at position 1200 (and you don’t want to lose the changes since the bad query).

If so, is there a consensus as to what indexes might be appropriate that would not otherwise exist without creating them?

Any place that you have a View that has filters or arguments on non-primary-key, MySQL may require an additional index. But only if those queries are showing up in your slow query log. Beyond the default indexes I don't think you'll find a consensus as to what additional indexes to add (and if you do find a consensus then it should be in the appropriate module).

You are looking for a magic bullet to improve your SQL performance, but there isn't one. You need to analyze your slow query log, try to improve queries, and weigh the benefits/costs of your optimizations for overall performance.

NewsForge recenserar Drupal 4.7.

Hur man installerar en lokal kopia av ens WordPress-blogg på sin mac, på enklaste sätt. Inklusive instruktioner för att installera MySQL.

En guide till hur man sätter upp Ruby, Ruby on Rails, FastCGI mm för Mac OS X.

Ett enkelt smidigt litet diskussionsforum i PHP med MySQL/PostgreSQL. Jag byggde in detta i Travinorrs hemsida för en framtida ny Anslagstavla.

PunBB är ett litet smidigt diskussionsforum skapat av Rickard Andersson. Byggt i PHP och använder sig av MySQL eller PostgreSQL.