タグ: SQL

JTVT2019現在のデータベース構造

まだまだ refineせねばならないと思いますが、現段階での Database DDLを記録しておきます

 ###############################################################################################
 ### SQL for JTVT2019 
 ### Based on this DDL, the program is constructed.
 ### Programmed by Shigeru SAITO, MD, FACC, FSCAI, FJCC
 ### on March 4th, 2018.
 ### revised on April 12th, 2018
 ###
 ### DB Name : jtvt2019
 ###############################################################################################

CREATE TABLE IF NOT EXISTS `hp_tbls` (
  `id` INT( 11 ) NOT NULL AUTO_INCREMENT,
  `hp_code` VARCHAR( 11 ) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL DEFAULT '',
  `hp_name` VARCHAR( 128 ) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL DEFAULT '',
  `zip_code` VARCHAR( 7 ) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL DEFAULT '',
  `ken_name` VARCHAR( 10 ) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL DEFAULT '',
  `hp_address` VARCHAR( 256 )CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL DEFAULT '',
  `country_code` TINYINT( 2 ) NOT NULL DEFAULT '1',			/* Country Code; By using this code , 1: JAPAN*/
                              /* interface such as feet or lb can be aplied. >10: feet/lb */
  PRIMARY KEY (`id`),
  UNIQUE(`hp_code`)
) ENGINE = InnoDB CHARACTER SET utf8 COLLATE utf8_general_ci AUTO_INCREMENT=0;

CREATE TABLE IF NOT EXISTS `dr_tbls` (
  `id` INT( 11 ) NOT NULL AUTO_INCREMENT,
  `kanji_sirname` VARCHAR( 64 ) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL DEFAULT '',
  `kanji_firstname` VARCHAR( 64 ) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL DEFAULT '',	
  `english_sirname` VARCHAR( 64 ) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL DEFAULT '',
  `english_firstname` VARCHAR( 64 ) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL DEFAULT '',	
  `hp_tbl_id` INT( 11 ) NOT NULL DEFAULT '0',
  `hp_name`  VARCHAR( 128 ) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL DEFAULT '',
  `job_kind` TINYINT( 2 ) NOT NULL DEFAULT '1',
  `email` VARCHAR( 128 ) NOT NULL DEFAULT '',
  `dr_pwd` VARCHAR( 512 ) NOT NULL DEFAULT '',
  `clue` TINYINT( 1 ) NOT NULL DEFAULT '1',
  `hint` VARCHAR( 512 )NOT NULL DEFAULT '',
  `login_date` DATE NOT NULL DEFAULT '0000-00-00 00:00:00',
  `ip` VARCHAR( 15 ) NOT NULL DEFAULT '000.000.000.000',
  `dr_url` VARCHAR( 60 ) NOT NULL DEFAULT '',
  `is_active` BOOLEAN NOT NULL DEFAULT '0',
  `is_usable` BOOLEAN NOT NULL DEFAULT '1',
  `is_deleted` BOOLEAN NOT NULL DEFAULT '0',
  `created` DATETIME NOT NULL DEFAULT '0000-00-00 00:00:00',
  `modified` DATETIME NOT NULL DEFAULT '0000-00-00 00:00:00',
  PRIMARY KEY (`id`),
  UNIQUE(`email`),
  INDEX(`email`)
) ENGINE = InnoDB CHARACTER SET utf8 COLLATE utf8_general_ci AUTO_INCREMENT=0;

CREATE TABLE IF NOT EXISTS `login_logs` (
  `id` INT( 11 ) NOT NULL AUTO_INCREMENT,
  `dr_tbl_id` INT( 11 ) NOT NULL DEFAULT '0',
  `login_date` DATETIME NOT NULL DEFAULT '0000-00-00 00:00:00',
  `login_ip` VARCHAR( 15 ) NOT NULL DEFAULT '000.000.000.000',
  PRIMARY KEY(`id`),
  INDEX(`dr_tbl_id`)
) ENGINE = InnoDB CHARACTER SET utf8 COLLATE utf8_general_ci AUTO_INCREMENT=0;

CREATE TABLE IF NOT EXISTS `abstract_tbls` (
  `id` INT( 11 ) NOT NULL AUTO_INCREMENT,
  `hp_tbl_id` INT( 11 ) NOT NULL DEFAULT '0',
  `dr_tbl_id` INT( 11 ) NOT NULL DEFAULT '0',
  `submission_date` DATETIME NOT NULL DEFAULT '0000-00-00 00:00:00',
  `abstract_topic1` tinyint( 2 ) NOT NULL default '0', /* TAVI, MitraClip, etc  */
  `abstract_topic2` tinyint( 2 ) NOT NULL default '0', /* Complications, etc  */
  `abstract_title` VARCHAR( 200 ) NOT NULL DEFAULT '',
  `abstract_content` VARCHAR( 2000 ) NOT NULL DEFAULT '',
  `is_selected` BOOLEAN NOT NULL DEFAULT '1',
  `is_deleted` BOOLEAN NOT NULL DEFAULT '0',
  `created` DATETIME NOT NULL DEFAULT '0000-00-00 00:00:00',
  `modified` DATETIME NOT NULL DEFAULT '0000-00-00 00:00:00',
  `last_access_date` DATETIME NOT NULL DEFAULT '0000-00-00 00:00:00',
  PRIMARY KEY  (`id`)
) ENGINE=InnoDB  DEFAULT CHARSET=utf8 AUTO_INCREMENT=0;

CREATE TABLE IF NOT EXISTS `time_slot_tbls` (
  `id` INT( 11 ) NOT NULL AUTO_INCREMENT,
  `begin_time` DATETIME NOT NULL DEFAULT '0000-00-00 00:00:00',
    `end_time` DATETIME NOT NULL DEFAULT '0000-00-00 00:00:00',	
  PRIMARY KEY (`id`)
) ENGINE = InnoDB CHARACTER SET utf8 COLLATE utf8_general_ci AUTO_INCREMENT=0;

CREATE TABLE IF NOT EXISTS `dr_role_tbls` (
  `id` INT( 11 ) NOT NULL AUTO_INCREMENT,
  `dr_tbl_id` INT( 11 ) NOT NULL DEFAULT '0',
  `time_slot_tbl_id` INT( 11 ) NOT NULL DEFAULT '0',
  `session_tbl_id` INT( 11 ) NOT NULL DEFAULT '0',
  `role_kind` tinyint( 2 ) NOT NULL default '0',
  `is_active` BOOLEAN NOT NULL DEFAULT '0',
  `is_usable` BOOLEAN NOT NULL DEFAULT '1',
  `is_deleted` BOOLEAN NOT NULL DEFAULT '0',
  `created` DATETIME NOT NULL DEFAULT '0000-00-00 00:00:00',
  `modified` DATETIME NOT NULL DEFAULT '0000-00-00 00:00:00',
  PRIMARY KEY (`id`)
) ENGINE = InnoDB CHARACTER SET utf8 COLLATE utf8_general_ci AUTO_INCREMENT=0;

CREATE TABLE IF NOT EXISTS `session_tbls` (
    `id` INT( 11 ) NOT NULL AUTO_INCREMENT,
  `session_typing_japanese` VARCHAR( 100 ) NOT NULL DEFAULT '',
  `session_typing_english` VARCHAR( 100 ) NOT NULL DEFAULT '',
    `session_sub_title_japanese` VARCHAR( 100 ) NOT NULL DEFAULT '',
  `session_sub_title_english` VARCHAR( 100 ) NOT NULL DEFAULT '',
  `session_begin_time` DATETIME NOT NULL DEFAULT '0000-00-00 00:00:00',
    `session_end_time` DATETIME NOT NULL DEFAULT '0000-00-00 00:00:00',	
  `session_objective_japanese` VARCHAR( 300 ) NOT NULL DEFAULT '',
  `session_objective_english` VARCHAR( 300 ) NOT NULL DEFAULT '',
  `is_deleted` BOOLEAN NOT NULL DEFAULT '0',
  `created` DATETIME NOT NULL DEFAULT '0000-00-00 00:00:00',
  `modified` DATETIME NOT NULL DEFAULT '0000-00-00 00:00:00',
  PRIMARY KEY (`id`)
) ENGINE = InnoDB CHARACTER SET utf8 COLLATE utf8_general_ci AUTO_INCREMENT=0;

 

SELECTで選択した列数を PDOで PHPに渡すには

これはしばしば行う間違いなのですが、気が付かないと結構しつこいバグの原因となりますね

$sql = "SELECT COUNT(*) FROM `dr_tbl` WHERE `email` = :email AND `conf_id` = :conf_id;";
$stmt = $pdo->prepare($sql);
$stmt->bindValue(":email", $_SESSION['email'], PDO::PARAM_STR);
$stmt->bindValue(":conf_id", $_SESSION['conf_id'], PDO::PARAM_INT);
$stmt->execute();
    //$rowCount = $stmt->rowCount();
    //echo 'Executed!'.$rowCount.'<br>';
if ($stmt->fetchColumn() > 0) {	// 既に登録されているので弾く
        // この時 fetchColumn()が戻す値は SQL文で得られた count(*)ということになります
        // この結果 SELECT文から正しい件数を知ることができます

 

二日間バグで苦しみ

どうにも納得行かなかったのです　それは、http://www.tri-international.orgのサイトをサーバー移行した時に始まったのです

そもそもこちらの都合でサーバー移行したのではありません　サーバー運営会社の意向に沿って移行したのです　これまでずっと使用してきた Rental Serverは FirstServerだったのですが、それが時代の移り変わりと共に、Zenlogicという次世代のサーバー環境になったのです　正直僕はここら Cloudとか詳しくないので何が違うのか良く分かりません

この移行の時に、これまでの全データも移行したのですが、問題は MySQL Database Server Dataだったのです　これも移行したのですが、それと共に phpMyadminという MySQLサーバーデータ管理の秀逸のソフトがそのままでは作動しなくなり、改めてインストール必要でした　そしてこの時に、port 3307にインストールされたのです　これが問題だったのです

そもそも現在はMySQL5.1が port 3307で作動し、MySQL5.0が port 3306で作動している、という変な状況が続いているのです　だいたい port番号なんて普段意識せずに使っているのですよっ

そしてサーバー移行前のデータは MySQL5.0から MySQL5.1に自動的にコピーされ、一見すると同じデータが2つの DB serverにあるのです

さて、PHPプログラムでは Internetアクセスした時には、

$db_host = '127.0.0.1';
//$db_port = '3307';//コメントアウトしているので port3306のまま
$db_user = '**A';
$db_password = '**B';

という風に　普段は port 3306の MySQL databaseに接続しているのです　しかし管理ソフトの phpMyadminは port 3307で接続していたのです　当初は同じDBがコピーされていたので、phpMyadminでいくらデータをいらっても　これは 3307接続ですから、PHP programからはその変更は見えません

結果的にわけのわからないことになってしまったのです　この portの問題に気づくまでには丸一日かかりました　そして現在は $db_port = ‘3307’;　この一文を活かしているので、全てが port 3307で作動している MySQLでプログラム全体が動いているのです

いやあこのバグは判明にずいぶんかかりました　しかし、僕の頭脳が未だ明晰であることが証明されてある意味嬉しいですね

Distal Radial Approach (DRA) vs Conventional Radial Approach (CRA)

さて、そろそろこの秘密のテクニックについて公表する時が来ました　何れにしてもライブでは皆の眼に触れることになるのでこれ以上秘密にしていても仕方ありません

DRAに関しては最近僕が推進している三文字略語ですが、未だ主流とはなっていません　しかし、臨床試験を企画していますのでそれで主流となるでしょう dTRAとかも使われていますし、PPA (Princeps Pollicis Artery) Approachとか、も使われています　これに対して通常の橈骨動脈アプローチについては、区別するために、僕は三文字略語として Conventionalを用いたいと思っています

さて、何故今 DRAが注目されるのでしょうか?　未だに経大腿動脈的冠動脈インターベンション (TFI: Trans Femoral Intervention)にこだわっている頭の固い先生方はここでは相手にはしませんが、経橈骨動脈的冠動脈インターベンション (TRI: Trans Radial Intervention)の優れた点は世界中で明らかになっています　しかし、その最大の欠点は術後の橈骨動脈閉塞 (RAO: Radial Artery Occlusion)です　これはTRIが生まれた時から悩ましき問題として注目されていました　既に論文にもなっている僕が仕掛けた大規模医師主導型臨床試験である RAP and BEAT trialでもこの点が Primary Endpointとされました

さて、DRAにおいては穿刺部位が何しろ CRAよりも末梢であるため、原理的にRAOが起こる可能性は低いと考えられます　しかし、問題は何しろ新しい方法なのでデータがありません　想像のみで医療はできません　そこで、僕はこの問題を解決するために無作為臨床試験を規格しているのです　これに参加して頂ける施設と医師を求めています　もちろん医師主導型臨床試験ですので、基本的にはボランティアとしての参加です　真実を知りたい、という知的意欲の下で参加して頂きたいのです

徐々にその全貌を明らかにしていきたいと思います　例によって、症例登録は Webで行います　お金が無いとか色々ありますので、例によって僕が自分の知識を駆使して、html5 + css3 + Javascript + jQuery + Ajax + SQL + PHPでその全てのプログラムを書きます　というよりも、既に成功裏に終了した RAP and BEAT試験のプログラムを改変するのです　これが、僕が次に考えている大きな仕事です

何と　そうだったのか

ここに二つのテーブルがあります　そう、片方は doctor_tblsであり、今一つは role_tblsです　簡単にすれば

doctor_tblsは

doctor_tbl_id name is_male
1 saito 1
2 shigeru 1
3 hanako 0

このようにしましょう is_maleは性別であり、男性であれば、1 女性であれば 0としましょう

もう一つのテーブルは役割配置表 role_tblsで　その構造は

role_tbl_id doctor_tbl_id role_kind
1 2 chair
2 2 speaker
3 1 moderator

のように例えばなります　つまり、saitoさんは doctor_tbl_id = 1ですが、 role表の中の role_tbl_id = 3に配置されていますね　そして役割は moderatorということになります　これをSQL文で記述すれば

SELECT * FROM `doctor_tbls` INNER JOIN `role_tbls` 
ON `doctor_tbls`.`doctor_tbl_id` = `role_tbls`.`doctor_tbl_id`;

ということになります　ここで良くあるように

role_tbl_id doctor_tbl_id role_kind
1 2 chair
2 2 speaker
3 1 moderator
4 1 speaker
5 1 chair

のようにsaitoさんの役割分担が三つに増えたとしましょう　この時に、役割が2つの人を探す SQL文について考えみました　なかなか正解には至らなかったのですが、色々調べてようやく分かりました　それは

SELECT `dr_tbl_id`, count(`dr_tbl_id`) as `Frequency` FROM `role_tbls` group by `dr_tbl_id` HAVING `Frequency` = '2'

というものです　ここで HAVING句を用いるのと、仮想列名 Frequencyというのを用いるのがミソなのです 素晴らしいですね

とにかく SQLというのはプログラミング言語の中でも異色のものであり、集合演算をするのです　これを理解しないと無駄足を踏むことになりますね

昨日より札幌

昨日より札幌に入っています　昨日朝　札幌には雪が降りましたが、流石にこの季節　街に積もっていた雪は溶けています　昨日はあまり元気が無く、早々と寝たのですが、01:00AMには覚醒し、それからずっとプログラム書いていました

Web上のプログラムで、TRI Maniac Confenceなどの登録サイトです。相当に securityに気を使いながら書いています。いわゆる Zendや、CakePHPなどのPHP Frameworkは使用せずに、最初からコーディングしています　どうもFrameworkの中のいろいろな取り決めが嫌いで、Frameworkには馴染めません　もっとも、jQueryは違います、これはFrameworkというより Javascript Libraryと言うべきかも知れませんが、これは随分と使っています

あれ程なかなか転化できなかった PDO (PHP Data Object)の世界ですが、今ではすっかり馴染んで使用しています　何しろ PDOを用いれば、SQL Injection攻撃を完璧に跳ね返すことができるので、とても貴重です　今回も MySQL Databaseとの間で SQL文を用いてデータのやり取りが何回も何回もあるのですが、その全てで PDOを用いています。これは僕にしてみれば相当な進歩です

以前PDOに馴染めなかったのは、SQL文のデバッグがしづらかったからです

  print_r($pdo->errorInfo());
  exit;

とすることにより、エラーが起きているかどうかは分かるのですが、SQL文の何処にエラーがあるのか、それがなかなかわかりづらかったので敬遠していました　しかし、ローカルで立ち上げたデータベースに対して phpMyAdminを用いて SQL文を発行して、デバッグする方法を思いついたので、この壁も乗り越えることができました

という訳で今は PDOを使いまくっています

phpMyBackupProによるSQL backup dataの文字化け

ついに見つけたツール　phpMyBackupProは非常に優れたものです。完璧に SQLでバック・アップが可能なのです。本当に素晴らしいと思います。しかも、フリーでダウンロードできるのです。

ただ、日本語には対応していません。このため、backupしたデータの日本語が文字化けしてしまい、そのままでは使い物になりません。データベースには UTF-8の文字コードでデータが蓄積されているので、phpMyBackupProそのもののデータ読み書きを UTF-8にすれば良いわけです。少しプログラムを見ていくと、どうやら Latinという文字コードがdefaultとして設定されているのです。まあ、どうやらイギリスで開発されているプログラムなので、かの国ではそれが標準なのでしょう。しかし、日本語対応させようと思えば、SJISあるいはEUC-Jという文字コード、そして現在の流れとしては UTF-8に対応せねばなりません。

そもそも Latinという文字コードでは一文字が 1Byte = 8 bitsであらわされます。これに対して、UTF-8では基本的に 3Bytes = 24 bitsで一文字があらわされます。日本語では、文字の数が何万とあるので、情報量として3Bytes必要なのです。

phpMyBackupProで同様の悩みをかかえて、それを解決された方がおられるのでは? と探したところ、やはりありましたね。ここ(A)です。

実は、もっと有望な解説も見つけました。それはここ(B)です。このサイトでは、何と日本語化した phpMyBackupProをダウンロードできるようにしていました。しかし、その versionが 2.1とあり、現在の version 2.3よりも古いのが少し気になります。

そこで、(A)を参考に、functions.inc.phpをエディタで開いて、その 636行目に以下の文を発見しました

        // select db
        @mysql_select_db($db);

ここに 2行を追加しました:

        // select db
        @mysql_select_db($db);
		$sql = "SET NAMES utf8";		// utf8に設定する
		$res= mysql_db_query($db,"$sql");

この簡単な追加により、見事に日本語データが文字化けせずにきちんと backupされ、downloadできるようになりました。もっとも、未だテスト段階ですので、このパソコンのローカルに設定した偽装インターネット環境での確認です。

そのようにしてダウンロードした SQL文を用いて、サーバー・データが破壊されても、再構築が完璧にできるか否かを検証したところ、問題がおこりました。

きちんと SQL文では日本語が文字化けせずにダウンロードできているのに、何故か SQL文を実行して再構築すると、データベース上のデータが文字化けするのです。これは変です。 SQL文を読んでもきちんと

DEFAULT CHARSET=utf8

と設定されているのです。そこで吐き出された SQL文を最初から見ると何とその最初に

# http://www.phpMyBackupPro.net

### used character set: Latin ###
set names Latin;

というのを発見しました。折角データをutf8で設定しているのに、肝心の書き込み段階で Latinに設定されているのです。これが原因でした。
それで、この部分の Latin -> utf8に変更したところ、見事に完全データ復旧ができるようになったのです。素晴らしいです。もう少しテストしてからサーバーに実際に uploadしてみます。何はともあれ、今度のサーバー障害により色々なことを学びました。失敗から多くを学び、発展させることができました。

ついに見つけたか

これまで PHP, MySQLを用いて Web上にデータベースを構築してきましたが、そのバック・アップには少し困っていました。

MySQL自体にバック・アップのためのコマンドを持っていますが、それを作動させるためには、コマンド・ラインから起動したりせねばなりません。つまり、まあだいたい LAMPでサーバーを構築していますから、L=Linux, A=Appache, M=MySQL, P=PHP or Perlなので、OSであるLinuxのシェルを直接起動できる権限を有していないとなりません。しかしながら、我々の用いているレンタル・サーバーでは当然のことながらこれは不可能です。
また、PHPより Sytem()コマンドなどで直接MySQLのコマンドを発行することもできますが、それも大概のレンタル・サーバーでは危険な命令語として、禁じられ、潰されています。
となると、最近のレンタル・サーバーには最初からインストールしてある、phpMyAdminという秀逸のツールを用い、その上でデータベースを選択し、エキスポート・コマンドによる SQL dumpを得る、それしか現実的な選択は無くなります。
もちろんこれでこれまでバック・アップしてきたのです。しかし、そこには問題があります。

  1. phpMyAdminを用いればデータベースの全てにアクセスできてしまうので、万が一操作を間違えば全てのデータベース消失という危険な事態になりかねない
  2. 従って、この操作権限を行使するためには、プログラミングについて相当の知識が無いといけない
  3. phpMyAdminの実行を自動スケジュールすることは困難である
  4. phpMyAdminの実行を自動化することも困難である

これらの問題点から　知らない人々からは「どうしてバック・アップを私たちにさせてくれないの?」　などという非難を浴びつつ、そんなこと説明するためにはどれだけたくさんの知識をあらかじめ教授せねばならないの?　と、そんな非難を自分の中で噛み潰してきたのです。

次の解決法としては、PHPでデータベースにアクセスするプログラムを書き、データのみをテーブル毎にダンプして、それをバック・アップすることです。もちろんこのプログラム作成はそれ程大変な作業ではありません。しかし、問題点としては、データというものの概念の中に、データ同士の関係、という重要な意味がある、ということなのです。特に MySQLなどの SQLデータベースは、関係データベースと称されるように、個々のテーブルに蓄えられたデータの互いの関連が重要な意味を持っているのです。

このPHPによるデータ・バック・アップでは、個々のテーブルデータをダウンロードすることはできますが、関係そのものを記録することは困難です。そのためには、 SQLにより記述したデータベース構造が必要なのです。 phpMyAdminを用いれば、SQL dumpが可能ですので、個々のテーブルデータのみならず、SQLで記述したデータ構造をもダンプできるのです。従って、データベースから全てが消失してもデータベースの完全復旧が可能なのです。

先日の、サーバー・データ消失事件においても、僕がこの SQL dumpをしていたためにデータ復旧が可能だったのです。これに反して、”Where is Dr. Saito?”で用いていたデータベースでは、このバック・アップがされていなかったため、未だに復旧できていないのです。

前置きはさておいて、ついに見つけました。素晴らしいバック・アップ・ツールを　しかも完全にフリーなのです。その名前は、phpMyBackupProです。試みにこれをダウンロードしてローカルにインストールしました。素晴らしい、の一言です。しかし、大きな問題が一つ、それは　データの中の日本語が文字化けしているのです。

まあ、これはMySQLにアクセスする部分でUTF-8を指定するようにプログラムを書きなおせば済むでしょう。何しろ、この優れたツールは全て PHPで記述された膨大なプログラムなのです。ですから、その部分をエディタで探して、UTF-8指定を入れればいいでしょう。チャレンジしましょう。

Ajax

Ajaxを用いて NAUSICA AMI試験の監査ツールを実装しました。Ajaxの仕組みなんてすっかり忘れていたのですが、プログラム書いている内にすぐに回復しました。やはりAjaxを用いると従来の Webページからは信じられないような画面の書き換えが行われ、プログラムを書いた甲斐があります。

その骨子は三つのパートです

  1. 主要画面
    1. ここではデータベースから受け取ったデータを cssを用いて見てくれを整えて出力する
    2. さらに、データを受信するためのボタンをつける
  2. データを受け取る Javascript (Ajax)
    1. ここがAjaxの根幹です
    2. ブラウザの Document Object Model (DOM)を用いてダイナミックに画面を書き換えます
  3. 裏で動くデータ加工プログラム
    1. データベース MySQLに対して SQLを発行してデータを得ます
    2. それを一定の形に加工します
    3. 加工の仕方としては、 JSONや HTMLを用いるのが一般的ですが、 TEXTでも良いのです　今回は HTMLを用いました

    忘れないようにおいおいプログラムを書き記します

知らなかった

何とこんなことも知りませんでした　今 NAUSICA AMI試験監査用インターフェースを作成しているのですが、そこで発行する SQLで例えば　病院毎にかつ、登録日順に並び変えるという、ごく普通の操作をすることに対して　これは ORDER BY句に複数指定すれば良いだろう、ということは容易に想像つきます　そこで自然に

SELECT * FROM `pt_tbl` ORDER BY `hp_id` AND `registration_date`;

としたのですが、これはとんでもない結果を返します　きっと、二つの項目を合成して並び替えするのです
正解は

SELECT * FROM `pt_tbl` ORDER BY `hp_id`, `registration_date`;

なのです。こんなとも知らなかったとは驚くべしでした