web-dev-qa-db-ja.com

データベース内のスキーマのないデータ？

構造やスキーマを事前に定義する必要のないデータベーステクノロジーがあるかどうか疑問に思っていますか？たとえば、1つの列または行から開始し、ユーザーが必要に応じて、その場でさらに列と行をテーブルに追加し続ける場合があります。

database-designschemajsoneav
2
Jeno

クエリを適切に記述し、SELECT *を回避すると、リレーショナルデータベースでは、アプリケーションを調整しなくても、列やテーブルをさらに追加できます。もちろん、SQLで参照する前に、各列をDBMSに宣言する必要があります。

NoSQLは「スキーマレス」であるという主張は少し誤解を招くと思います。実際、NoSQL永続性を使用するアプリケーションにはスキーマがあります。違いは、スキーマがアプリケーションコードに保持され、そのスキーマを適用するのは、アプリケーションの存続期間を通じてコードに触れるすべてのプログラマーの責任であるということです。リレーショナルデータベースでは、データ構造がサービスに対して宣言され、その後もそれらのルールを適用する責任があります。 NoSQLの真の柔軟性は、同じ「バケット」（DBMSによって定義が異なる）内の2つの行が異なる構造を持つことができることです。

2
Michael Green

これを行う現在の方法は2つあり、非常に人気があります。

  • JSON SQL：2016、

    SQL 2016では、標準化されたスキーマレスタイプJSONがあります。ほとんどのデータベースはそれを実装しており、多くのデータベースにもバイナリ形式があります（ PostgreSQL 、 MySQL など）。このフォームが利用できる場合は、それを使用する必要があります。 EAVよりもタイピングが優れており、インデックス作成が簡単です。さらに階層をサポートでき、クエリが簡単で、JSONAPIおよびRESTプロトコルですぐに使用できます。

    CREATE TABLE foo ( foo_id int, name text, other_data jsonb );
INSERT INTO foo VALUES ( 5, 'foo', '{"json_key":5,"foo":"baz"}' );

SELECT *
FROM foo
WHERE other_data @> '{"foo": "baz"}';

  • EAV-エンティティ属性値 このメソッドを使用して、キーと値の関係を表すテーブルを作成します。

    CREATE TABLE entity ( entity_id, name text );
CREATE TABLE eav ( entity_id int, attribute text, value text );

    さらに、リンクテーブルを使用して、

    CREATE TABLE entity ( entity_id PRIMARY KEY, name text );
CREATE TABLE eav ( eav_id int PRIMARY KEY, attribute text, value text );
CREATE TABLE eav_entity (
  eav_id int REFERENCES eav,
  entity_id REFERENCES entity
);

    ここでの考え方は、attribute（キー）と値が独自のテーブルにあるということです。これには、attributesがすべて同じタイプを共有する必要があるという欠点があります。 valuesも同じタイプを共有する必要がありますが、それらのタイプはattributesと同じである必要はありません。

1
Evan Carroll

データの構造がまだ定義されていないときに使用できるEAVと呼ばれるデータアーキテクチャがあります。ユーザーは、（Entity、Attribute、Value）と呼ばれるトリプルの3番目の要素としてすべての値を入力します。必要に応じて、新しいエンティティまたは属性を含めることができます。

この構造は完全に動的ですが、ほぼ完全に制御不能です。問題は、データの所有者が、構造化データベースを使用して安価で簡単な同じ種類の結果を求めている場合に発生します。レポート、抜粋、およびその他の一般的な標準出力について話しています。これは、EAVで達成するのが非常に困難で費用がかかることがよくあります。

0
Walter Mitty