6

Postgres 9.3 での JSON のサポートについて、なぜこれほど騒がれているのだろうかと思います。ユーザー定義型 (UDT) に対する JSON の利点は何ですか? UDT を使用する際の落とし穴は何ですか? UDT を使用したテーブルへのアクセスは非効率的ですか? ALTER TYPE ADD 属性は遅いですか? UDT は Postgres によって物理的にどのように保存されますか?

説明し、追加情報へのリンクを提供してください。

4

4 に答える 4

3

以前の回答の 1 つでRoman Pekarが述べたように、 JSONサポートははるかに柔軟性が高く、リレーショナルでNoSQLの動作を模倣する可能性を提供します。

さらに、クライアント サーバー アプリケーションで、クライアントから直接データベースに送信された JSON 値を簡単に保存できるようになります。

フィールドの 30% をアプリケーションのクライアントに使用し、30% を別のクライアントに使用することができ、複数のテーブルや多数の列セットを含むテーブルを定義する必要はありません。したがって、異質な情報の大きなチャンクを 1 つの場所に格納できます。

最後になりましたが、JSON は標準であり、多くの主要なプログラミング言語でサポートされています。

(現在、プロジェクトでこの機能を使用しています (ベータ版から使用しています)。さらに、これがアプリケーションにPostgresを選択した主な理由でした。主に分離された情報を持つ大きな DB が必要だったからです。NoSQL を使用してみました。しかし、情報を格納するために必要なテーブルが多すぎて、「結合」にコストがかかりました. 一方、リレーショナル DB だけでは対応が困難だったので、半リレーショナル半非リレーショナルではなく、 、Postgresの JSON サポートを選択しました。)

于 2013-09-23T12:39:16.180 に答える
3
  • JSON はユーザー定義型よりもはるかに柔軟だと思います。必要なオプションの属性を追加したり、ネストしたり、リストに入れたりできます。
  • JSON は非常に読みやすい形式です。
  • JSON は多くの言語 (Javascript、Python) の標準オブジェクト表記であるため、テーブルからデータを読み取って使用できます。
  • データを処理したいときにいつでも新しい型を作成する必要はありません。JSON を作成して処理し、後は忘れるだけです。
于 2013-08-23T14:12:15.413 に答える
2

それほど深刻ではありませんが、それは少しマーケティングです:)。もっと真剣に - 内部 JSON サポートは、このトピックに関する数年間の作業の最終段階です。内部型と UDT の間に大きな違いはなく、多くの内部型 (および機能) は UDT または UDF として開始されます。アップストリームへの移行は比較的難しいプロセスであり、概念 (および API) はほとんどテストされず、議論されません。そのため、内部実装により、大幅に高い品質と高い安定性 (エラーの減少、より​​安定した API) とサポートが保証されます。コミュニティは、「これは私たちにとって興味深い機能であり、強化およびサポートしたいと考えています」と述べています。他に違いはありません - (パフォーマンスまたはストレージ形式)。

于 2013-08-08T07:21:21.090 に答える
0

ユーザー定義型に関するいくつかのこと:

  1. それらは固定形式です（JSONはスキーマレスです）
  2. それらについて推測することができます。
  3. インデックス作成の問題に柔軟に対応できます。
  4. 複合型 (UDT の 1 つの形式) は、JSON 属性を持つことができます。

ユーザー定義型を使用すると、これらの型に関して JSON よりもかなり確実に SQL を拡張できますが、JSON を使用すると柔軟性が大幅に向上します。また、ネストされた型は、 9.3 の JSON オブジェクトとしてよりも複合型として実行された方が、サポートの点ではるかに柔軟です (ただし、これはある時点で変更される可能性があります)。9.3 では、JSON オブジェクトがネストされている場合、JSON オブジェクトを複合型に変換することはできません。

于 2013-11-05T10:15:05.533 に答える