定期的なデータベースバックアップの実行を信じていないデータベース管理者（DBA）はほとんどいませんが、最善の方法については多くの意見があります。どちらのアプローチを支持する場合でも、データベーススキーマのコピーを保持する理由は十分にあります。データが失われた場合は、スキーマからデータベース構造を復元し、最新のデータバックアップを使用してデータを取り込むことができます。
MySQLなどの一部のデータベースベンダーは、データベース構造を単独でバックアップするための無料のユーティリティ（つまりmysqldump）を提供していますが、それには特定の管理ツールを必要とするベンダーもあります。Navicat ユーザーの場合、外部ツールは必要ありません。データのバックアップはバックアップウィザードを使用して実行できますが、スキーマはデータ転送ツールを使用してコピーできます。このブログでは、その方法を学びます。
先週の記事では、SELECTクエリの外部結合に光を当てました。関連するテーブルから一致した行と一致しない行の両方を返すJOINのタイプです。残念ながら、これはMySQLを含む全てのデータベース（DB）ベンダーでサポートされているわけではありません。しかし、大丈夫です。なぜなら、外部結合は、他の3つのJOINのタイプ、つまり、LEFT JOIN（左結合）、INNER JOIN（内部結合）、およびRIGHT JOIN（右結合）を組み合わせることでエミュレートできるためです。この記事では、JEFT JOINとRIGHT JOINについて詳しく説明し、INNER JOINと組み合わせてOUTER JOINを作成する方法について説明します。
外部結合は、全てのSQL結合タイプの中で最も理解されていないものです。おそらく、外部結合が他の結合タイプよりも必要とされる頻度がやや少ないためです。いずれにせよ、外部結合について本質的に奇妙なことは何もありません。このブログ記事で説明するように、実際の外部結合のいくつかの例は、それらについての誤解や混乱を明確にするのに十分なはずです。
このブログでは、最初にOuter Joinステートメントの構文と目的について説明し、いくつかの実例を次に示します。
情報技術（または、より一般的に知られているIT）の領域では、列挙型は、定義済みの定数のセットをカプセル化する特別なデータ型です。そのため、変数は、定義済みの値の1つしか保持できません。一般的な例には、北、南、東、西のコンパス方位や曜日などがあります。
列挙型をデータベーステーブルに格納する際の複雑な要因の1つは、列挙型の値が数値またはアルファベット（つまり、文字列）である可能性があることです。さらに、許容される列挙型セットの一部ではない値をユーザーがテーブルに追加できないようにする必要があるでしょう。本日のブログでは、これらの問題の両方に対処します。
プライマリキーとしての文字列
リレーショナルデータベースのプライマリキーの選択に関するこのシリーズの最終回となる第3回では、文字列データをプライマリキー（PK）として使用する理由のいくつかを検討します。パート1で、ナチュラルプライマリキーとサロゲートプライマリキーについて説明し、一方を選択する理由を検討したことを思い出してください。パート2では、プライマリキーとしての文字列と数値のデータ型を調査し、どちらが好ましいかを確認しました。ここで記録を整理し、文字列（またはアルファベット）データが適切なPKを作成できるかどうかを結論付けます。
