QA@IT
«回答へ戻る

表現を少し修正

20
     なお、最近のバージョンの PostgreSQL では、新しい SQL 構文により これの代替手段が提供されています。
 
 ### 個人的な所見
-他の RDBMS から移行するときには PostgreSQL のほうが危険な罠は少ないように思えます。
+他の RDBMS から移行するときには PostgreSQL のほうが、すべてを台無しにするような危険な罠のタグイは少ないように思えます。

業務システム構築において、他の RDBMS から移行するという観点をもとに回答します。

MySQL で困ること

MySQLでは、1 つのクエリに対して、1 つのテーブルにつき 1 つのインデックスしか使用できない

参考: http://labs.unoh.net/2007/06/mysql5.html

他の RDBMS から MySQL に移行した時に、特に困るのが この仕様です。
これを避けるために、なにやら 他の RDBMS では ふつーはおこなわない謎のクエリ構造を組み上げる営みが、往々にして必要となります。

ストレージエンジンに MyISAM を選択したテーブルはテーブルロックになる

参考: http://mysql.manual.php.to/storage-engines.html#storage-engine-choosing

特に困るのがバックアップ実行時です。バックアップ実行中に該当テーブルがバックアップ終了するまでテーブルロックが発生してしまいます。
これは通常運用時に特に困ります。(バックアップ機能が、スナップショットを取得してからバックアップ、という流れの方式になっていないようです) バックアップ中にシステムがフリーズするのを避けるには、なにかしら方式を工夫する必要があります。

JDBC ドライバーのデフォルト値が とてつもなく変

参考: http://sourceforge.jp/projects/manjyu/wiki/JNDI_MySQL
JDBC ドライバーのデフォルト値が、とても変です。これは歴史的経緯によるものですが、、、。
他の RDBMS の JDBC ドライバーと似た挙動をさせたい場合には、驚くほどの大量の追加設定をおこなう必要があります。

PostgreSQL で困ること

トランザクション中に SQL 例外が発生すると、トランザクションが完了するまで、それ以降の SQL 文がすべて例外状態になってしまう【JDBC ドライバ経由でしか裏取っていません】

たとえばトランザクション中に一意制約違反の SQL 例外を発生させてしまうと、以降の SQL 文がすべてエラーになってしまいます。
業務的に一意制約違反を発生させて、それ以降の処理を分岐しようというのに慣れている人は注意しましょう。
なお、最近のバージョンの PostgreSQL では、新しい SQL 構文により これの代替手段が提供されています。

個人的な所見

他の RDBMS から移行するときには PostgreSQL のほうが、すべてを台無しにするような危険な罠のタグイは少ないように思えます。

業務システム構築において、他の RDBMS から移行するという観点をもとに回答します。

### MySQL で困ること
#### MySQLでは、1 つのクエリに対して、1 つのテーブルにつき 1 つのインデックスしか使用できない
参考: http://labs.unoh.net/2007/06/mysql5.html

    他の RDBMS から MySQL に移行した時に、特に困るのが この仕様です。
    これを避けるために、なにやら 他の RDBMS では ふつーはおこなわない謎のクエリ構造を組み上げる営みが、往々にして必要となります。
#### ストレージエンジンに MyISAM を選択したテーブルはテーブルロックになる
参考: http://mysql.manual.php.to/storage-engines.html#storage-engine-choosing

    特に困るのがバックアップ実行時です。バックアップ実行中に該当テーブルがバックアップ終了するまでテーブルロックが発生してしまいます。
    これは通常運用時に特に困ります。(バックアップ機能が、スナップショットを取得してからバックアップ、という流れの方式になっていないようです) バックアップ中にシステムがフリーズするのを避けるには、なにかしら方式を工夫する必要があります。
#### JDBC ドライバーのデフォルト値が とてつもなく変
参考: http://sourceforge.jp/projects/manjyu/wiki/JNDI_MySQL
    JDBC ドライバーのデフォルト値が、とても変です。これは歴史的経緯によるものですが、、、。
    他の RDBMS の JDBC ドライバーと似た挙動をさせたい場合には、驚くほどの大量の追加設定をおこなう必要があります。

### PostgreSQL で困ること
#### トランザクション中に SQL 例外が発生すると、トランザクションが完了するまで、それ以降の SQL 文がすべて例外状態になってしまう【JDBC ドライバ経由でしか裏取っていません】
    たとえばトランザクション中に一意制約違反の SQL 例外を発生させてしまうと、以降の SQL 文がすべてエラーになってしまいます。
    業務的に一意制約違反を発生させて、それ以降の処理を分岐しようというのに慣れている人は注意しましょう。
    なお、最近のバージョンの PostgreSQL では、新しい SQL 構文により これの代替手段が提供されています。

### 個人的な所見
他の RDBMS から移行するときには PostgreSQL のほうが、すべてを台無しにするような危険な罠のタグイは少ないように思えます。

リンクを追加

20
     特に困るのがバックアップ実行時です。バックアップ実行中に該当テーブルがバックアップ終了するまでテーブルロックが発生してしまいます。
     これは通常運用時に特に困ります。(バックアップ機能が、スナップショットを取得してからバックアップ、という流れの方式になっていないようです) バックアップ中にシステムがフリーズするのを避けるには、なにかしら方式を工夫する必要があります。
 #### JDBC ドライバーのデフォルト値が とてつもなく変
+参考: http://sourceforge.jp/projects/manjyu/wiki/JNDI_MySQL
     JDBC ドライバーのデフォルト値が、とても変です。これは歴史的経緯によるものですが、、、。
     他の RDBMS の JDBC ドライバーと似た挙動をさせたい場合には、驚くほどの大量の追加設定をおこなう必要があります。
 

業務システム構築において、他の RDBMS から移行するという観点をもとに回答します。

MySQL で困ること

MySQLでは、1 つのクエリに対して、1 つのテーブルにつき 1 つのインデックスしか使用できない

参考: http://labs.unoh.net/2007/06/mysql5.html

他の RDBMS から MySQL に移行した時に、特に困るのが この仕様です。
これを避けるために、なにやら 他の RDBMS では ふつーはおこなわない謎のクエリ構造を組み上げる営みが、往々にして必要となります。

ストレージエンジンに MyISAM を選択したテーブルはテーブルロックになる

参考: http://mysql.manual.php.to/storage-engines.html#storage-engine-choosing

特に困るのがバックアップ実行時です。バックアップ実行中に該当テーブルがバックアップ終了するまでテーブルロックが発生してしまいます。
これは通常運用時に特に困ります。(バックアップ機能が、スナップショットを取得してからバックアップ、という流れの方式になっていないようです) バックアップ中にシステムがフリーズするのを避けるには、なにかしら方式を工夫する必要があります。

JDBC ドライバーのデフォルト値が とてつもなく変

参考: http://sourceforge.jp/projects/manjyu/wiki/JNDI_MySQL
JDBC ドライバーのデフォルト値が、とても変です。これは歴史的経緯によるものですが、、、。
他の RDBMS の JDBC ドライバーと似た挙動をさせたい場合には、驚くほどの大量の追加設定をおこなう必要があります。

PostgreSQL で困ること

トランザクション中に SQL 例外が発生すると、トランザクションが完了するまで、それ以降の SQL 文がすべて例外状態になってしまう【JDBC ドライバ経由でしか裏取っていません】

たとえばトランザクション中に一意制約違反の SQL 例外を発生させてしまうと、以降の SQL 文がすべてエラーになってしまいます。
業務的に一意制約違反を発生させて、それ以降の処理を分岐しようというのに慣れている人は注意しましょう。
なお、最近のバージョンの PostgreSQL では、新しい SQL 構文により これの代替手段が提供されています。

個人的な所見

他の RDBMS から移行するときには PostgreSQL のほうが危険な罠は少ないように思えます。

業務システム構築において、他の RDBMS から移行するという観点をもとに回答します。

### MySQL で困ること
#### MySQLでは、1 つのクエリに対して、1 つのテーブルにつき 1 つのインデックスしか使用できない
参考: http://labs.unoh.net/2007/06/mysql5.html

    他の RDBMS から MySQL に移行した時に、特に困るのが この仕様です。
    これを避けるために、なにやら 他の RDBMS では ふつーはおこなわない謎のクエリ構造を組み上げる営みが、往々にして必要となります。
#### ストレージエンジンに MyISAM を選択したテーブルはテーブルロックになる
参考: http://mysql.manual.php.to/storage-engines.html#storage-engine-choosing

    特に困るのがバックアップ実行時です。バックアップ実行中に該当テーブルがバックアップ終了するまでテーブルロックが発生してしまいます。
    これは通常運用時に特に困ります。(バックアップ機能が、スナップショットを取得してからバックアップ、という流れの方式になっていないようです) バックアップ中にシステムがフリーズするのを避けるには、なにかしら方式を工夫する必要があります。
#### JDBC ドライバーのデフォルト値が とてつもなく変
参考: http://sourceforge.jp/projects/manjyu/wiki/JNDI_MySQL
    JDBC ドライバーのデフォルト値が、とても変です。これは歴史的経緯によるものですが、、、。
    他の RDBMS の JDBC ドライバーと似た挙動をさせたい場合には、驚くほどの大量の追加設定をおこなう必要があります。

### PostgreSQL で困ること
#### トランザクション中に SQL 例外が発生すると、トランザクションが完了するまで、それ以降の SQL 文がすべて例外状態になってしまう【JDBC ドライバ経由でしか裏取っていません】
    たとえばトランザクション中に一意制約違反の SQL 例外を発生させてしまうと、以降の SQL 文がすべてエラーになってしまいます。
    業務的に一意制約違反を発生させて、それ以降の処理を分岐しようというのに慣れている人は注意しましょう。
    なお、最近のバージョンの PostgreSQL では、新しい SQL 構文により これの代替手段が提供されています。

### 個人的な所見
他の RDBMS から移行するときには PostgreSQL のほうが危険な罠は少ないように思えます。

説明を補足

20
 参考: http://mysql.manual.php.to/storage-engines.html#storage-engine-choosing
 
     特に困るのがバックアップ実行時です。バックアップ実行中に該当テーブルがバックアップ終了するまでテーブルロックが発生してしまいます。
-    これは通常運用時に特に困ります。(バックアップ機能が、スナップショットを取得してからバックアップ、という流れの方式になっていないようです)
+    これは通常運用時に特に困ります。(バックアップ機能が、スナップショットを取得してからバックアップ、という流れの方式になっていないようです) バックアップ中にシステムがフリーズするのを避けるには、なにかしら方式を工夫する必要があります。
 #### JDBC ドライバーのデフォルト値が とてつもなく変
     JDBC ドライバーのデフォルト値が、とても変です。これは歴史的経緯によるものですが、、、。
     他の RDBMS の JDBC ドライバーと似た挙動をさせたい場合には、驚くほどの大量の追加設定をおこなう必要があります。

業務システム構築において、他の RDBMS から移行するという観点をもとに回答します。

MySQL で困ること

MySQLでは、1 つのクエリに対して、1 つのテーブルにつき 1 つのインデックスしか使用できない

参考: http://labs.unoh.net/2007/06/mysql5.html

他の RDBMS から MySQL に移行した時に、特に困るのが この仕様です。
これを避けるために、なにやら 他の RDBMS では ふつーはおこなわない謎のクエリ構造を組み上げる営みが、往々にして必要となります。

ストレージエンジンに MyISAM を選択したテーブルはテーブルロックになる

参考: http://mysql.manual.php.to/storage-engines.html#storage-engine-choosing

特に困るのがバックアップ実行時です。バックアップ実行中に該当テーブルがバックアップ終了するまでテーブルロックが発生してしまいます。
これは通常運用時に特に困ります。(バックアップ機能が、スナップショットを取得してからバックアップ、という流れの方式になっていないようです) バックアップ中にシステムがフリーズするのを避けるには、なにかしら方式を工夫する必要があります。

JDBC ドライバーのデフォルト値が とてつもなく変

JDBC ドライバーのデフォルト値が、とても変です。これは歴史的経緯によるものですが、、、。
他の RDBMS の JDBC ドライバーと似た挙動をさせたい場合には、驚くほどの大量の追加設定をおこなう必要があります。

PostgreSQL で困ること

トランザクション中に SQL 例外が発生すると、トランザクションが完了するまで、それ以降の SQL 文がすべて例外状態になってしまう【JDBC ドライバ経由でしか裏取っていません】

たとえばトランザクション中に一意制約違反の SQL 例外を発生させてしまうと、以降の SQL 文がすべてエラーになってしまいます。
業務的に一意制約違反を発生させて、それ以降の処理を分岐しようというのに慣れている人は注意しましょう。
なお、最近のバージョンの PostgreSQL では、新しい SQL 構文により これの代替手段が提供されています。

個人的な所見

他の RDBMS から移行するときには PostgreSQL のほうが危険な罠は少ないように思えます。

業務システム構築において、他の RDBMS から移行するという観点をもとに回答します。

### MySQL で困ること
#### MySQLでは、1 つのクエリに対して、1 つのテーブルにつき 1 つのインデックスしか使用できない
参考: http://labs.unoh.net/2007/06/mysql5.html

    他の RDBMS から MySQL に移行した時に、特に困るのが この仕様です。
    これを避けるために、なにやら 他の RDBMS では ふつーはおこなわない謎のクエリ構造を組み上げる営みが、往々にして必要となります。
#### ストレージエンジンに MyISAM を選択したテーブルはテーブルロックになる
参考: http://mysql.manual.php.to/storage-engines.html#storage-engine-choosing

    特に困るのがバックアップ実行時です。バックアップ実行中に該当テーブルがバックアップ終了するまでテーブルロックが発生してしまいます。
    これは通常運用時に特に困ります。(バックアップ機能が、スナップショットを取得してからバックアップ、という流れの方式になっていないようです) バックアップ中にシステムがフリーズするのを避けるには、なにかしら方式を工夫する必要があります。
#### JDBC ドライバーのデフォルト値が とてつもなく変
    JDBC ドライバーのデフォルト値が、とても変です。これは歴史的経緯によるものですが、、、。
    他の RDBMS の JDBC ドライバーと似た挙動をさせたい場合には、驚くほどの大量の追加設定をおこなう必要があります。

### PostgreSQL で困ること
#### トランザクション中に SQL 例外が発生すると、トランザクションが完了するまで、それ以降の SQL 文がすべて例外状態になってしまう【JDBC ドライバ経由でしか裏取っていません】
    たとえばトランザクション中に一意制約違反の SQL 例外を発生させてしまうと、以降の SQL 文がすべてエラーになってしまいます。
    業務的に一意制約違反を発生させて、それ以降の処理を分岐しようというのに慣れている人は注意しましょう。
    なお、最近のバージョンの PostgreSQL では、新しい SQL 構文により これの代替手段が提供されています。

### 個人的な所見
他の RDBMS から移行するときには PostgreSQL のほうが危険な罠は少ないように思えます。

リンクが利くようにする

20
 ### MySQL で困ること
 #### MySQLでは、1 つのクエリに対して、1 つのテーブルにつき 1 つのインデックスしか使用できない
 参考: http://labs.unoh.net/2007/06/mysql5.html
+
     他の RDBMS から MySQL に移行した時に、特に困るのが この仕様です。
     これを避けるために、なにやら 他の RDBMS では ふつーはおこなわない謎のクエリ構造を組み上げる営みが、往々にして必要となります。
 #### ストレージエンジンに MyISAM を選択したテーブルはテーブルロックになる
-    参考: http://mysql.manual.php.to/storage-engines.html#storage-engine-choosing
+参考: http://mysql.manual.php.to/storage-engines.html#storage-engine-choosing
+
     特に困るのがバックアップ実行時です。バックアップ実行中に該当テーブルがバックアップ終了するまでテーブルロックが発生してしまいます。
     これは通常運用時に特に困ります。(バックアップ機能が、スナップショットを取得してからバックアップ、という流れの方式になっていないようです)
 #### JDBC ドライバーのデフォルト値が とてつもなく変

業務システム構築において、他の RDBMS から移行するという観点をもとに回答します。

MySQL で困ること

MySQLでは、1 つのクエリに対して、1 つのテーブルにつき 1 つのインデックスしか使用できない

参考: http://labs.unoh.net/2007/06/mysql5.html

他の RDBMS から MySQL に移行した時に、特に困るのが この仕様です。
これを避けるために、なにやら 他の RDBMS では ふつーはおこなわない謎のクエリ構造を組み上げる営みが、往々にして必要となります。

ストレージエンジンに MyISAM を選択したテーブルはテーブルロックになる

参考: http://mysql.manual.php.to/storage-engines.html#storage-engine-choosing

特に困るのがバックアップ実行時です。バックアップ実行中に該当テーブルがバックアップ終了するまでテーブルロックが発生してしまいます。
これは通常運用時に特に困ります。(バックアップ機能が、スナップショットを取得してからバックアップ、という流れの方式になっていないようです)

JDBC ドライバーのデフォルト値が とてつもなく変

JDBC ドライバーのデフォルト値が、とても変です。これは歴史的経緯によるものですが、、、。
他の RDBMS の JDBC ドライバーと似た挙動をさせたい場合には、驚くほどの大量の追加設定をおこなう必要があります。

PostgreSQL で困ること

トランザクション中に SQL 例外が発生すると、トランザクションが完了するまで、それ以降の SQL 文がすべて例外状態になってしまう【JDBC ドライバ経由でしか裏取っていません】

たとえばトランザクション中に一意制約違反の SQL 例外を発生させてしまうと、以降の SQL 文がすべてエラーになってしまいます。
業務的に一意制約違反を発生させて、それ以降の処理を分岐しようというのに慣れている人は注意しましょう。
なお、最近のバージョンの PostgreSQL では、新しい SQL 構文により これの代替手段が提供されています。

個人的な所見

他の RDBMS から移行するときには PostgreSQL のほうが危険な罠は少ないように思えます。

業務システム構築において、他の RDBMS から移行するという観点をもとに回答します。

### MySQL で困ること
#### MySQLでは、1 つのクエリに対して、1 つのテーブルにつき 1 つのインデックスしか使用できない
参考: http://labs.unoh.net/2007/06/mysql5.html

    他の RDBMS から MySQL に移行した時に、特に困るのが この仕様です。
    これを避けるために、なにやら 他の RDBMS では ふつーはおこなわない謎のクエリ構造を組み上げる営みが、往々にして必要となります。
#### ストレージエンジンに MyISAM を選択したテーブルはテーブルロックになる
参考: http://mysql.manual.php.to/storage-engines.html#storage-engine-choosing

    特に困るのがバックアップ実行時です。バックアップ実行中に該当テーブルがバックアップ終了するまでテーブルロックが発生してしまいます。
    これは通常運用時に特に困ります。(バックアップ機能が、スナップショットを取得してからバックアップ、という流れの方式になっていないようです)
#### JDBC ドライバーのデフォルト値が とてつもなく変
    JDBC ドライバーのデフォルト値が、とても変です。これは歴史的経緯によるものですが、、、。
    他の RDBMS の JDBC ドライバーと似た挙動をさせたい場合には、驚くほどの大量の追加設定をおこなう必要があります。

### PostgreSQL で困ること
#### トランザクション中に SQL 例外が発生すると、トランザクションが完了するまで、それ以降の SQL 文がすべて例外状態になってしまう【JDBC ドライバ経由でしか裏取っていません】
    たとえばトランザクション中に一意制約違反の SQL 例外を発生させてしまうと、以降の SQL 文がすべてエラーになってしまいます。
    業務的に一意制約違反を発生させて、それ以降の処理を分岐しようというのに慣れている人は注意しましょう。
    なお、最近のバージョンの PostgreSQL では、新しい SQL 構文により これの代替手段が提供されています。

### 個人的な所見
他の RDBMS から移行するときには PostgreSQL のほうが危険な罠は少ないように思えます。

なぜにリンクが利かない?

20
 
 ### MySQL で困ること
 #### MySQLでは、1 つのクエリに対して、1 つのテーブルにつき 1 つのインデックスしか使用できない
-    参考: http://labs.unoh.net/2007/06/mysql5.html
+参考: http://labs.unoh.net/2007/06/mysql5.html
     他の RDBMS から MySQL に移行した時に、特に困るのが この仕様です。
     これを避けるために、なにやら 他の RDBMS では ふつーはおこなわない謎のクエリ構造を組み上げる営みが、往々にして必要となります。
 #### ストレージエンジンに MyISAM を選択したテーブルはテーブルロックになる

業務システム構築において、他の RDBMS から移行するという観点をもとに回答します。

MySQL で困ること

MySQLでは、1 つのクエリに対して、1 つのテーブルにつき 1 つのインデックスしか使用できない

参考: http://labs.unoh.net/2007/06/mysql5.html
他の RDBMS から MySQL に移行した時に、特に困るのが この仕様です。
これを避けるために、なにやら 他の RDBMS では ふつーはおこなわない謎のクエリ構造を組み上げる営みが、往々にして必要となります。

ストレージエンジンに MyISAM を選択したテーブルはテーブルロックになる

参考: http://mysql.manual.php.to/storage-engines.html#storage-engine-choosing
特に困るのがバックアップ実行時です。バックアップ実行中に該当テーブルがバックアップ終了するまでテーブルロックが発生してしまいます。
これは通常運用時に特に困ります。(バックアップ機能が、スナップショットを取得してからバックアップ、という流れの方式になっていないようです)

JDBC ドライバーのデフォルト値が とてつもなく変

JDBC ドライバーのデフォルト値が、とても変です。これは歴史的経緯によるものですが、、、。
他の RDBMS の JDBC ドライバーと似た挙動をさせたい場合には、驚くほどの大量の追加設定をおこなう必要があります。

PostgreSQL で困ること

トランザクション中に SQL 例外が発生すると、トランザクションが完了するまで、それ以降の SQL 文がすべて例外状態になってしまう【JDBC ドライバ経由でしか裏取っていません】

たとえばトランザクション中に一意制約違反の SQL 例外を発生させてしまうと、以降の SQL 文がすべてエラーになってしまいます。
業務的に一意制約違反を発生させて、それ以降の処理を分岐しようというのに慣れている人は注意しましょう。
なお、最近のバージョンの PostgreSQL では、新しい SQL 構文により これの代替手段が提供されています。

個人的な所見

他の RDBMS から移行するときには PostgreSQL のほうが危険な罠は少ないように思えます。

業務システム構築において、他の RDBMS から移行するという観点をもとに回答します。

### MySQL で困ること
#### MySQLでは、1 つのクエリに対して、1 つのテーブルにつき 1 つのインデックスしか使用できない
参考: http://labs.unoh.net/2007/06/mysql5.html
    他の RDBMS から MySQL に移行した時に、特に困るのが この仕様です。
    これを避けるために、なにやら 他の RDBMS では ふつーはおこなわない謎のクエリ構造を組み上げる営みが、往々にして必要となります。
#### ストレージエンジンに MyISAM を選択したテーブルはテーブルロックになる
    参考: http://mysql.manual.php.to/storage-engines.html#storage-engine-choosing
    特に困るのがバックアップ実行時です。バックアップ実行中に該当テーブルがバックアップ終了するまでテーブルロックが発生してしまいます。
    これは通常運用時に特に困ります。(バックアップ機能が、スナップショットを取得してからバックアップ、という流れの方式になっていないようです)
#### JDBC ドライバーのデフォルト値が とてつもなく変
    JDBC ドライバーのデフォルト値が、とても変です。これは歴史的経緯によるものですが、、、。
    他の RDBMS の JDBC ドライバーと似た挙動をさせたい場合には、驚くほどの大量の追加設定をおこなう必要があります。

### PostgreSQL で困ること
#### トランザクション中に SQL 例外が発生すると、トランザクションが完了するまで、それ以降の SQL 文がすべて例外状態になってしまう【JDBC ドライバ経由でしか裏取っていません】
    たとえばトランザクション中に一意制約違反の SQL 例外を発生させてしまうと、以降の SQL 文がすべてエラーになってしまいます。
    業務的に一意制約違反を発生させて、それ以降の処理を分岐しようというのに慣れている人は注意しましょう。
    なお、最近のバージョンの PostgreSQL では、新しい SQL 構文により これの代替手段が提供されています。

### 個人的な所見
他の RDBMS から移行するときには PostgreSQL のほうが危険な罠は少ないように思えます。

H2 -> H3 的なタイトル下げ

20
 業務システム構築において、他の RDBMS から移行するという観点をもとに回答します。
 
-## MySQL で困ること
-### MySQLでは、1 つのクエリに対して、1 つのテーブルにつき 1 つのインデックスしか使用できない
+### MySQL で困ること
+#### MySQLでは、1 つのクエリに対して、1 つのテーブルにつき 1 つのインデックスしか使用できない
     参考: http://labs.unoh.net/2007/06/mysql5.html
     他の RDBMS から MySQL に移行した時に、特に困るのが この仕様です。
     これを避けるために、なにやら 他の RDBMS では ふつーはおこなわない謎のクエリ構造を組み上げる営みが、往々にして必要となります。
-### ストレージエンジンに MyISAM を選択したテーブルはテーブルロックになる
+#### ストレージエンジンに MyISAM を選択したテーブルはテーブルロックになる
     参考: http://mysql.manual.php.to/storage-engines.html#storage-engine-choosing
     特に困るのがバックアップ実行時です。バックアップ実行中に該当テーブルがバックアップ終了するまでテーブルロックが発生してしまいます。
     これは通常運用時に特に困ります。(バックアップ機能が、スナップショットを取得してからバックアップ、という流れの方式になっていないようです)
-### JDBC ドライバーのデフォルト値が とてつもなく変
+#### JDBC ドライバーのデフォルト値が とてつもなく変
     JDBC ドライバーのデフォルト値が、とても変です。これは歴史的経緯によるものですが、、、。
     他の RDBMS の JDBC ドライバーと似た挙動をさせたい場合には、驚くほどの大量の追加設定をおこなう必要があります。
 
-## PostgreSQL で困ること
-### トランザクション中に SQL 例外が発生すると、トランザクションが完了するまで、それ以降の SQL 文がすべて例外状態になってしまう【JDBC ドライバ経由でしか裏取っていません】
+### PostgreSQL で困ること
+#### トランザクション中に SQL 例外が発生すると、トランザクションが完了するまで、それ以降の SQL 文がすべて例外状態になってしまう【JDBC ドライバ経由でしか裏取っていません】
     たとえばトランザクション中に一意制約違反の SQL 例外を発生させてしまうと、以降の SQL 文がすべてエラーになってしまいます。
     業務的に一意制約違反を発生させて、それ以降の処理を分岐しようというのに慣れている人は注意しましょう。
     なお、最近のバージョンの PostgreSQL では、新しい SQL 構文により これの代替手段が提供されています。
 
-## 個人的な所見
+### 個人的な所見
 他の RDBMS から移行するときには PostgreSQL のほうが危険な罠は少ないように思えます。

業務システム構築において、他の RDBMS から移行するという観点をもとに回答します。

MySQL で困ること

MySQLでは、1 つのクエリに対して、1 つのテーブルにつき 1 つのインデックスしか使用できない

参考: http://labs.unoh.net/2007/06/mysql5.html
他の RDBMS から MySQL に移行した時に、特に困るのが この仕様です。
これを避けるために、なにやら 他の RDBMS では ふつーはおこなわない謎のクエリ構造を組み上げる営みが、往々にして必要となります。

ストレージエンジンに MyISAM を選択したテーブルはテーブルロックになる

参考: http://mysql.manual.php.to/storage-engines.html#storage-engine-choosing
特に困るのがバックアップ実行時です。バックアップ実行中に該当テーブルがバックアップ終了するまでテーブルロックが発生してしまいます。
これは通常運用時に特に困ります。(バックアップ機能が、スナップショットを取得してからバックアップ、という流れの方式になっていないようです)

JDBC ドライバーのデフォルト値が とてつもなく変

JDBC ドライバーのデフォルト値が、とても変です。これは歴史的経緯によるものですが、、、。
他の RDBMS の JDBC ドライバーと似た挙動をさせたい場合には、驚くほどの大量の追加設定をおこなう必要があります。

PostgreSQL で困ること

トランザクション中に SQL 例外が発生すると、トランザクションが完了するまで、それ以降の SQL 文がすべて例外状態になってしまう【JDBC ドライバ経由でしか裏取っていません】

たとえばトランザクション中に一意制約違反の SQL 例外を発生させてしまうと、以降の SQL 文がすべてエラーになってしまいます。
業務的に一意制約違反を発生させて、それ以降の処理を分岐しようというのに慣れている人は注意しましょう。
なお、最近のバージョンの PostgreSQL では、新しい SQL 構文により これの代替手段が提供されています。

個人的な所見

他の RDBMS から移行するときには PostgreSQL のほうが危険な罠は少ないように思えます。

業務システム構築において、他の RDBMS から移行するという観点をもとに回答します。

### MySQL で困ること
#### MySQLでは、1 つのクエリに対して、1 つのテーブルにつき 1 つのインデックスしか使用できない
    参考: http://labs.unoh.net/2007/06/mysql5.html
    他の RDBMS から MySQL に移行した時に、特に困るのが この仕様です。
    これを避けるために、なにやら 他の RDBMS では ふつーはおこなわない謎のクエリ構造を組み上げる営みが、往々にして必要となります。
#### ストレージエンジンに MyISAM を選択したテーブルはテーブルロックになる
    参考: http://mysql.manual.php.to/storage-engines.html#storage-engine-choosing
    特に困るのがバックアップ実行時です。バックアップ実行中に該当テーブルがバックアップ終了するまでテーブルロックが発生してしまいます。
    これは通常運用時に特に困ります。(バックアップ機能が、スナップショットを取得してからバックアップ、という流れの方式になっていないようです)
#### JDBC ドライバーのデフォルト値が とてつもなく変
    JDBC ドライバーのデフォルト値が、とても変です。これは歴史的経緯によるものですが、、、。
    他の RDBMS の JDBC ドライバーと似た挙動をさせたい場合には、驚くほどの大量の追加設定をおこなう必要があります。

### PostgreSQL で困ること
#### トランザクション中に SQL 例外が発生すると、トランザクションが完了するまで、それ以降の SQL 文がすべて例外状態になってしまう【JDBC ドライバ経由でしか裏取っていません】
    たとえばトランザクション中に一意制約違反の SQL 例外を発生させてしまうと、以降の SQL 文がすべてエラーになってしまいます。
    業務的に一意制約違反を発生させて、それ以降の処理を分岐しようというのに慣れている人は注意しましょう。
    なお、最近のバージョンの PostgreSQL では、新しい SQL 構文により これの代替手段が提供されています。

### 個人的な所見
他の RDBMS から移行するときには PostgreSQL のほうが危険な罠は少ないように思えます。

回答を投稿

業務システム構築において、他の RDBMS から移行するという観点をもとに回答します。

MySQL で困ること

MySQLでは、1 つのクエリに対して、1 つのテーブルにつき 1 つのインデックスしか使用できない

参考: http://labs.unoh.net/2007/06/mysql5.html
他の RDBMS から MySQL に移行した時に、特に困るのが この仕様です。
これを避けるために、なにやら 他の RDBMS では ふつーはおこなわない謎のクエリ構造を組み上げる営みが、往々にして必要となります。

ストレージエンジンに MyISAM を選択したテーブルはテーブルロックになる

参考: http://mysql.manual.php.to/storage-engines.html#storage-engine-choosing
特に困るのがバックアップ実行時です。バックアップ実行中に該当テーブルがバックアップ終了するまでテーブルロックが発生してしまいます。
これは通常運用時に特に困ります。(バックアップ機能が、スナップショットを取得してからバックアップ、という流れの方式になっていないようです)

JDBC ドライバーのデフォルト値が とてつもなく変

JDBC ドライバーのデフォルト値が、とても変です。これは歴史的経緯によるものですが、、、。
他の RDBMS の JDBC ドライバーと似た挙動をさせたい場合には、驚くほどの大量の追加設定をおこなう必要があります。

PostgreSQL で困ること

トランザクション中に SQL 例外が発生すると、トランザクションが完了するまで、それ以降の SQL 文がすべて例外状態になってしまう【JDBC ドライバ経由でしか裏取っていません】

たとえばトランザクション中に一意制約違反の SQL 例外を発生させてしまうと、以降の SQL 文がすべてエラーになってしまいます。
業務的に一意制約違反を発生させて、それ以降の処理を分岐しようというのに慣れている人は注意しましょう。
なお、最近のバージョンの PostgreSQL では、新しい SQL 構文により これの代替手段が提供されています。

個人的な所見

他の RDBMS から移行するときには PostgreSQL のほうが危険な罠は少ないように思えます。

業務システム構築において、他の RDBMS から移行するという観点をもとに回答します。

## MySQL で困ること
### MySQLでは、1 つのクエリに対して、1 つのテーブルにつき 1 つのインデックスしか使用できない
    参考: http://labs.unoh.net/2007/06/mysql5.html
    他の RDBMS から MySQL に移行した時に、特に困るのが この仕様です。
    これを避けるために、なにやら 他の RDBMS では ふつーはおこなわない謎のクエリ構造を組み上げる営みが、往々にして必要となります。
### ストレージエンジンに MyISAM を選択したテーブルはテーブルロックになる
    参考: http://mysql.manual.php.to/storage-engines.html#storage-engine-choosing
    特に困るのがバックアップ実行時です。バックアップ実行中に該当テーブルがバックアップ終了するまでテーブルロックが発生してしまいます。
    これは通常運用時に特に困ります。(バックアップ機能が、スナップショットを取得してからバックアップ、という流れの方式になっていないようです)
### JDBC ドライバーのデフォルト値が とてつもなく変
    JDBC ドライバーのデフォルト値が、とても変です。これは歴史的経緯によるものですが、、、。
    他の RDBMS の JDBC ドライバーと似た挙動をさせたい場合には、驚くほどの大量の追加設定をおこなう必要があります。

## PostgreSQL で困ること
### トランザクション中に SQL 例外が発生すると、トランザクションが完了するまで、それ以降の SQL 文がすべて例外状態になってしまう【JDBC ドライバ経由でしか裏取っていません】
    たとえばトランザクション中に一意制約違反の SQL 例外を発生させてしまうと、以降の SQL 文がすべてエラーになってしまいます。
    業務的に一意制約違反を発生させて、それ以降の処理を分岐しようというのに慣れている人は注意しましょう。
    なお、最近のバージョンの PostgreSQL では、新しい SQL 構文により これの代替手段が提供されています。

## 個人的な所見
他の RDBMS から移行するときには PostgreSQL のほうが危険な罠は少ないように思えます。