3

MySQL を PostgreSQL に移行しています。(REALbasic) プログラム全体で使用されるスキーマと SQL ステートメントを簡単に監査できます。ほとんどの SQL は、文字列変数を構築することによって構成されています。

SELECT LAST_INSERT_ID()の使用をUNIQUE制約のあるSERIAL列に置き換える必要があることはすでに知っています。

SQL ステートメントでは明らかに見えない2 つの違いがあるとすれば、どのような違いがあるのでしょうか? 自動コミットの違い、MySQL にはない制約を追加する必要など、動作に関する (おそらく微妙な) 仮定を探しています。

私は、どちらのデータベースの第一人者でもない、適度に頭が良くて気配りのある 2 人の男たちのために、落とし穴を見つけようとしています。

これは一方向のコミットメントであるため、新しい宣言を追加することで得られる大きなメリットがある場合は、指摘していただければ幸いです。

注: パラメータ化されたクエリは一切使用していません。はい、コードの必須監査としてインジェクション攻撃の問題を指摘しました。

はい、興味深いことに、この決定は GPL の問題によって引き起こされたものであり、ライセンスの支払いを嫌がっているわけではありませんが、残念ながら、MySQL 用の唯一の REALbasic ドライバーは GPL でした。2009 年 5 月の時点で、Real Software は GPL であり、適切にソースを含む新しい Community ドライバーをリリースしました。彼らは、近い将来、非 GPL エンタープライズ ドライバを約束しました。

その答えは、ベッドの下に目に見えない怪物がいないことかもしれないと信じる準備はできていますが、念のためお願いしたいと思います。

4

7 に答える 7

6

  • select count(*) from table;

    テーブル全体を読み取る必要があるため、遅くなります。大きなテーブルを頻繁にカウントする必要がある場合は、回避策が必要です。これは、マルチバージョンの同時実行制御を確実にするために必要です。

  • 最新バージョン (8.3) では、テキストへの暗黙的なキャストはありません。つまり、たとえば

    select 234 like '2%';

    エラーをスローします。次のような明示的なキャストが必要です。

    select 234::text like '2%';

  • 更新は実際には削除+挿入です。削除された行によって使用されたスペースはすぐには解放されないため、1 つのトランザクションでテーブル全体を更新すると、2 倍のスペースが必要になります。

Postgresql は非常に優れたデータベースであり、すぐに気に入っていただけるでしょう。他の商用データベースでは見逃してしまうような、非常に便利な機能がいくつかあります。たとえば、トランザクション データ定義言語やセーブポイントなどです。

于 2009-02-04T09:58:34.770 に答える
3

http://wiki.postgresql.org/wiki/Converting_from_other_Databases_to_PostgreSQL

于 2009-01-14T13:37:34.647 に答える
1

列の型付けで SQL92 に準拠していない限り、2 つの型の間で型の名前が異なることに遭遇します。

クエリ内変数の変更は、postgreSQL では機能しません。たとえば、これは MySQL では機能しますが、postgreSQL では機能しません (最近テストしていませんが、現在は機能している可能性があります)。

SET @a:=1 SELECT ID,@a:=@a+1 FROM some_table;

個人的には、postgreSQL の方がサブセレクトなどを含む複雑なクエリをより適切に処理できると信じています (ほとんどの MySQL ユーザーはこれを避けていました)。

編集：ああ、そして私はほとんど忘れていました！postgreSQL がテーブルを格納する方法は、MySQL が行う方法とはまったく異なります。これは、バックアップ/復元戦略にも影響を与える可能性があります。

于 2009-01-14T07:27:23.957 に答える
0

関連するクエリの量に応じて (また、社内にそれを行う人がいる場合)、すべてのクエリを抽出し、必要に応じてそれらを調整し、既存の DB の 2 つのコピー (1 つは mysql を実行し、もう 1 つは実行) で実行することが賢明な場合があります。ポスグレル。生成されたログを見て、結果のデータを比較すると、興味深いヒントが得られる場合があります。最初のステップは、アプリケーションの単体テスト、手動またはスクリプトベースのテストを実行することによっても実行できます。

于 2009-01-13T23:35:38.747 に答える
0

WikiVS の比較に基づいて、いくつかの興味深い点を見つけましたが、そのほとんどは実際には落とし穴ではありません。

そのサイトからPostgres の落とし穴リストにたどり着きました。このリストには、count(*) 速度と別のシーケンシャル スキャンの問題に関する詳細が記載されていました。Maxと Min はシーケンシャル スキャンです。これは、これまでに特定された他の何よりもパフォーマンスを損なう可能性がはるかに高い. ただし、その記事には Max(col) 回避策が含まれています。

SELECT col FROM table ORDER BY col DESC LIMIT 1
于 2009-02-08T04:45:13.073 に答える