注釈
この記事では、2つの無料の無料データベース管理システム（DBMS）、MySQLとPostgreSQLの比較分析を紹介しています。 分析は、軽負荷および中負荷のアプリケーションでこれらのDBMSを使用するという観点から行われます。 数百万ドルのオーディエンスを持つプロジェクトのスケーリングと最適化の問題は考慮されていません。 パフォーマンス比較データは提供されません。 MySQL 5.1およびPostgreSQL 8.3が考慮されます。
データ型
開発者が最初に対処する必要があるのは、使用可能なデータ型です。 利用可能なデータ型を比較しましょう。
整数および浮動小数点数
可能な値の範囲は示しませんが、情報容量はバイト単位で示します。
。 | MySQL | PostgreSQL
TINYINT | 1バイト|
SMALLINT | 2バイト| 2バイト
MEDIUMINT | 3バイト|
INTEGER、INT | 4バイト| 4バイト
BIGINT | 8バイト| 8バイト
FLOAT、DOUBLE、REAL | 4または8バイト| 4または8バイト
10進数、数値|小数点以下65桁| 制限なし
シリアル、BIGSERIAL | 8バイト| 4または8バイト
BIT |彼は| 彼は
注：1）MySQLはUNSIGNED型をサポートしていますが、これはSQL標準の一部ではありません。
2）浮動小数点型の場合、PostgreSQLは
IEEE 754標準形式を使用するため、値+ Inf、-Inf、およびNaNを保存できますが、これらの値を数学演算で使用することはできません。
表からわかるように、2つのDBMSのデータ型はほぼ同じです。 違いは、MySQLでは使用可能なメモリをより詳細に使用できることですが、文字表現での数値の操作は65桁に制限されています。 このような文字数の数値の実用的なアプリケーションは見当たらないため、このセクションのMySQLとPostgreSQLの機能は同一であると想定できます。
行とデータ
寸法はバイト単位です。 1文字に対してUTF-8を1〜4バイトで使用できることを忘れないでください。
。 | MySQL | PostgreSQL
バイナリ、CHAR | 255 | 10485760
VARCHAR、VARBINARY | 65535 * | 10485760
TINYBLOB、TINYTEXT | 2 ^ 8 |
BLOB、TEXT、bytea | 2 ^ 16 | 限定されない
MEDIUMBLOB | 2 ^ 24 |
LONGBLOB | 2 ^ 32 |
*この制限は、65535バイトに等しい最大文字列長によって引き起こされますが、実際には最大長ははるかに短くなります。
この表は、2つのDBMSの文字列データ型の容量が実質的に変わらないことを示しています。また、MySQLを使用すると、ハードディスク上のデータストレージのフォーマットをより厳密に制御できます。 ただし、MySQLのこの柔軟性により、設計段階で2つの小さな問題が発生します。データのタイプとサイズの混乱です。
根拠にならないように、例を挙げます-ユーザーデータを保存します。 ユーザーの名前、姓、愛用者だけでなく、住所と電話番号についても保存する必要があるが、ユーザーをプロファイルに保存するために提供できるものがわからないとします。 SQLの観点から、これにはCHAR型とVARCHAR型を使用する必要があります。 また、MySQLでは、すべてが約65535バイト与えられているため、姓の最大長、名前の最大長、アドレスの最大長を決定する必要があります。 同時に、PostgreSQLでは、必要に応じてMySQLで許可されているよりもはるかに多くのデータを格納できるVARCHARテーブルのすべての列の型として指定するだけです。 （これらの目的のためにMySQLでTEXTを使用することを提案しないようお願いします。）
日時
2つのベースの日付と時刻のタイプはほぼ同じで、通常は問題を引き起こしません。
カスタムタイプ
PostgreSQLは、配列、構造、IPおよびMACアドレスを格納するための型、幾何学的形状のパラメーターを格納するための型など、MySQLには完全に存在しない作業用のデータ型のグループを提供しています。 興味のある方は、
PostgreSQLデータ型に独自に慣れることができ
ます 。
UPD MySQLには、幾何学図形のデータ型があります。
詳細はコメントにあります。データ型に関する結論
1）2つのDBMSが提供するデータ型は、機能的な観点からは同一です。
2）これらのタイプを使用すると、任意のDBMSにデータを保存できますが、MySQLでは、開発者は設計の初期段階で文字列データの長さを人為的に制限することを余儀なくされます。これはシステムの使いやすさにプラスの影響を与えません。
3）PostgreSQLで非標準型を使用すると、開発が大幅に簡素化されますが、別のDBMSへの移行が複雑になります。
4）MySQLでは、保存されたデータの構造を正確に制御できますが、同時に開発者の利便性が犠牲になります。
データ管理機能
ここで、開発者に提供される追加機能に関して2つのDBMSを比較します。 この機能の一部は標準SQLに含まれています。
ストアドプロシージャ
最も単純なストアドプロシージャから始めましょう。 大まかに言うと、MySQLにはストアドプロシージャの機能はまったくありません。 もっと正確に言えば、一般的にはそうですが、むしろarbitrary意的です。 そのため、たとえば、レプリケーションが有効になっている場合、ストアドプロシージャは読み取り専用にしかできません。 そのため、ストアドプロシージャを介してユーザー権限を制限するためのかなり一般的なスキームは、MySQLにはまったく実装されていません。
インデックスとキー
この点では、MySQLはその機能を発揮しません。 キーサイズごとに1000バイトの制限-どこに収まりますか？ ユーザーが任意の言語（UTF-8）でアカウントを作成できるようにします。 ログインの最大長については、512文字を選択します。 ログインは一意でなければならないので、列に一意のキーを課す必要があるという結論に達しましたが、キーは1000バイトに収まらないため、できません。 最初の333文字でのみ譲歩し、一意にする必要があります。 信じられない人は誰でも独立してcreate table t（t varchar（512）、key（t））character set = utf8の結果を見ることができます。
PostgreSQLは、このような複雑さの影響を受けませんが、必要なサイズの一意のキーを作成するだけです。
アップロード段階でのデータの検証
SQL標準では、テーブルに追加されたデータが満たす必要がある式を設定するCHECKステートメントが提供されていました。 MySQLのマニュアルでは、この指示について「CHECK句は解析されますが、すべてのストレージエンジンで無視されます」と簡単に説明されています。
トランザクションと外部キー
デフォルトでは、MySQLはテーブルにMyISAMエンジンを使用しますが、これはトランザクションまたは外部キーをサポートしていません。 これは歴史的に起こりましたが、パフォーマンスの観点からデータベースを操作することを検討する場合、このアプローチには言い訳があります。 トランザクションと外部キーが必要な場合は、ストレージエンジンInnoDBの使用が必須であることに気付くでしょう。 当然、PostgreSQLでは、トランザクションと外部キーは完全に機能します。
結論
MySQLとPostgreSQLは、異なるタスクに直面しているデータベース管理システムであり、それらの違いを明確に理解する必要があります。 実用的な推奨事項として、MySQLはHighLoad領域でその利点を示していると言えますが、開発者によるより慎重なアプローチが必要であり、格納されたデータとDBMS機能チャネルにかなり深刻な制限を課します。
一般に、数百万人の出席に焦点を当てていないプロジェクト、および学術目的では、PostgreSQLを使用することをお勧めします。 MySQLは、多数の単純な単一テーブルクエリを使用するデータベースでその利点を発揮し、開発者側の細心の注意が必要です。