2

私は何年もリレーショナル データベースの仕事をしてきましたが、最近は Cassandra/Redis の領域に移行しました。NoSQL は私たちがやっていることに意味があるので、それで問題ありません。

今日、Cassandra 列ファミリーの定義に取り組んでいるときに、ある疑問が浮かびました。リレーショナル データベースでは、データベース エンジン自体が結果として生じる一貫性の問題をネイティブに管理できるように、DDL で非正規化ルールを定義できないのはなぜですか。言い換えれば、リレーショナル データベース プログラマーがパフォーマンス目標を達成するために非正規化するとき、なぜ専用 SQL を介して一貫性を維持する必要があるのでしょうか?

たぶん、私が行方不明になっていることが明らかな何かがありますか？このような提案がばかげている理由は何かありますか?なぜなら、この機能を持っていると非常に便利なように思えるからです.

編集：

これまでのフィードバックに感謝します。私はまだ答えられていない質問を抱えているように感じます (おそらく、うまく表現されていないためでしょう)。マテリアライズド ビューは、非正規化されたデータに対してエンジン管理の一貫性を提供しようとしていることを理解しています。ただし、基になるテーブルが変更されてもすぐには更新されないことを理解しています。これが本当なら、それはエンジンが本当にそうではないことを意味します非正規化に起因する一貫性の問題の管理...少なくとも書き込み時ではありません。私が理解しているのは、複雑なリレーショナル モデルに対して読み取り負荷の高いシステムをスケーリングするときに、真の機能豊富なエンジン管理の非正規化を使用しない正規化されたデータ構造は、リレーショナル データベース エンジンを妨害するということです。マテリアライズド ビューのリフレッシュ レートを調整することは、Cassandra などの NoSQL エンジンによって提供される調整可能な「結果整合性」に等しいというのは本当だと思います。エンジンがどれだけ効率的にマテリアライズド ビューを同期できるかを調べる必要があります。NoSQL オプションと比較して実行可能であると見なされるためには、ビューの同期にかかる時間が、追加/更新された行の数に比例して増加する必要があります。

とにかく、もう少し考えて再編集します。うまくいけば、想像上の DDL の代表的な例がいくつかあります。

4

2 に答える 2

2

一部のリレーショナル データベース システムは、非正規化されたデータの一貫性をある程度維持できます (私があなたの言いたいことを正しく理解している場合)。

ではOracle、これは-で呼ばmaterialized viewsれます。SQL Serverindexed views

基本的に、これは、クエリの結果として自己管理された非正規化テーブルを作成し、SQLそれにインデックスを付けることができることを意味します。

CREATE VIEW a_b
WITH SCHEMABINDING
AS
SELECT  b.id AS id, b.value, b.a_id, a.property
FROM    dbo.b b
JOIN    dbo.a a
ON      a.id = b.a_id

結果のビュー はa_b、それが実際のテーブルである場合、 が候補キーでないものに機能的に依存している2NFため、違反します。ただし、データベース システムはこの機能の依存関係を維持しており、たとえば に複合インデックスを作成できます。propertya_id(value, property)

MySQLマテリアライズド ビューをネイティブにサポートしていないとであっても、PostgreSQLある種の非正規化テーブルを維持できます。

たとえば、FULLTEXTで列または一連の列にインデックスを作成するMySQLと、一度に 2 つのインデックスが取得されます。最初のインデックスには、各レコードの個別の単語ごとに 1 つのエントリが含まれ (元のレコードへの参照を含むid)、2 番目のインデックスにはテーブル全体の単語ごとに 1 つのレコードと、合計単語数が含まれます。これにより、単語の高速検索と関連性による順序付けが可能になります。

もちろん、総単語数テーブルは個々の単語テーブルに依存するため、違反5NFしますが、システムはこの依存関係を維持します。

同様のことがGINと のGISTインデックスに対しても行われますPostgreSQL。

もちろん、考えられるすべての非正規化を維持できるわけではありません。つまり、クエリをリアルタイムで実体化してインデックス化することはできません。維持するにはコストがかかりすぎるものもあれば、理論的には可能でも実際のシステムに実装されていないものもあります。

ただし、トリガー、ストアドプロシージャなどで独自のロジックを使用してそれらを維持することができます。それがまさにその目的です。

于 2011-05-04T21:21:18.920 に答える
1

RDBMS での非正規化は特殊な​​ケースであり、標準ではありません。証明されたケースがある場合にのみ、これを行います。非正規化されたデータを前もって設計すると、すでに負けています。

それぞれのケースが定義上「特別」であるとすると、非正規化されたデータを維持するための標準 SQL 構造はどのように存在するのでしょうか。

RDBMS は、正規化された設計で動作するように設計されているという点で NoSQL とは異なります。私見、このようにRDBMSとNoSQLを比較することはできません

于 2011-05-09T16:37:26.057 に答える