9

Railsのようなフレームワークは、制約や外部キーのようなものでさえ、データベースから多くのロジックを移動することを奨励してきました-私の意見では。より管理しやすく、変更が簡単なため、より良い結果が得られます。それでも、一部の操作はより簡単で、SQLでのみ可能です。

MongoDB、CassandraなどのnoSQLデータベースの人気の最近の爆発は、データベース開発のベストプラクティスへのアプローチをさらに根本的に変えました。

私の質問：参照データの整合性はもはや必要ではありませんか？

多くの場合、仕事に最適なツールを選択することになりますが、トランザクションを持つことが必須である金融アプリケーションや同様のタイプのアプリを除外し、お金を稼ぐが銀行レベルの整合性を必要としないより一般的なアプリに焦点を当てましょう。

参照データの整合性はどの程度必要ですか？誰かがそれを使用していないときに彼らが持っていたいくつかの問題をリストすることができますか？

より重要なデータにはPostgreSQLのようなデータベースを使用し、重要性は低いが要求の高いデータにはMongoDBを使用するのが賢明な戦略ですか？どのデータが「重要」で何が「非重要」であるかを正確に定義することをどのように提案しますか？

4

7 に答える 7

3

ここでの質問とほとんどの回答は同じことを言っているように思えます: データの整合性 (RI はデータの整合性の一般的な側面の 1 つにすぎません) は間違いなく必要であり、これまでと同じように重要です。ガバナンス、規制、データ保護に関する懸念が高まっている今日、データの完全性はおそらく過去よりもさらに重要になっています。

たまたま、DBMS が必要な機能を提供していないことがわかり、他の場所で整合性ルールを実装しようとしています。結局のところ、DBMS はデータに最も近いため、ビジネス ルールを効率的に実装するには最適な場所に配置する必要があるため、これは奇妙です。宣言型のルールは、手続き型のルールよりも保守と検証が容易であるべきです。また、ルールをデータベースで一元管理することは、他の多くのレイヤーやアプリケーションにルールを分散させるよりも費用対効果が高いはずです。

私の結論は、これらのことが一部の人にとって真実であることが証明されていない場合、それは実際には、今日のデータベース ソフトウェアの欠陥について多くを語っているということです。完全性が重要ではないという意味ではありません。まったく逆です。

于 2010-09-01T22:05:46.390 に答える
2

データを関連付けて参照する場合、参照整合性は常に有効な問題です。現代の問題は、それが必要かどうかではなく、プログラマーとデータベース管理者が管理するインデックスを通じて外部キー フィールドを検証する従来の SQL データベースの方法で管理するかどうかです。オブジェクト アクセスに合わせて調整された単純なデータベースは、従来のデータ整合性メソッドを隠したり、例外としてプログラムで問題を管理したり、そのような懸念を手動で管理したりできます。

そうは言っても、従来の方法はほとんどのアプリケーションでうまく機能します (ただし、明らかに eBay ではありません)。参照整合性は、回復が困難な整合性の問題が発生するまではばかげているように見えます。実装するのは簡単なので、それから始めて、他の手段では満たすことができないパフォーマンスの必要性が明らかになった場合にのみ削除する必要があります。

mongo に関しては、アプリケーションの実装と保守が容易になる場合に使用します。必要に応じて、間違いなく両方を使用できます。

于 2010-08-31T23:17:48.297 に答える
2

2 つのデータ ストアを持つことについてのあなたの最後のコメントは、出てくる新しい中規模アプリのほとんどの未来だと思います。サイトのコア コンポーネントを接続するための参照整合性を持つ 1 つのバックエンドと、より大規模なインターネット規模のデータ用の別のバックエンド。

eBay のようなレガシー企業は、厳密な QA を実施し、開発者が行うすべての影響を熟考するためのリソースを持っているため、比較対象として使用すべきではありません。典型的な中小規模のスタートアップにはこれらのリソースがなく、参照整合性を備えたストアに重要なデータを保持することで、多くのアプリケーションの欠陥がサイトに長期間黙って留まるのを防ぐことができます.

複数のデータベースに対するDjango のサポートを確認してください。ACID データストアから CRUD データストアへの移行は、その逆よりもはるかに簡単であることに注意してください。

于 2010-08-31T17:19:05.093 に答える
1

他に考慮すべきことは、アプリケーションとデータ ストアのライフサイクルです。データ ストアがビジネスに役立つ場合、複数のアプリケーションからアクセスされたり、他のデータ ストアへのインターフェイスを持ったりする可能性があります。参照整合性が存在するデータに近いほど、インターフェイスまたは他の何かが不適切な更新を行うリスクが少なくなります。

そして、あなたが現在取り組んでいるアプリケーションにはインターフェースがあるかもしれませんが、7 年後にはどうなるでしょうか? (平均的なビジネス アプリケーションは 7 年間保持されるようです) ビジネスが成長すると、他のツールが使用されます (たとえば、同じビジネスへの実装または別のビジネスの買収による)。

于 2010-09-01T00:42:55.627 に答える
1

私はデータベースが巨大な会社 (ebay.com) で働いていました。データベースで参照整合性を使用することは想定されていません。この制限は、パフォーマンス要因のみを念頭に置いて配置されました。ORM (Object Relational Mapping) レベルでは何も定義しません。すべてを論理的に処理する必要があります。想像するのも少し難しいことはわかっていますが、それでもパフォーマンスが向上します。

さて、あなたの質問ですが、ORM レベルであまりにも多くの抽象化が行われているため、人々はデータベース側で何が起こっているのかさえ気にしていません。少なくともコーディングに出てきた新しいものは、ストアプロシージャを書くことで多くのことができるデータベース（オラクルなど）で参照整合性を直接宣言し、トリガーを書くことをほとんど気にしません. それでも、人々は ORM レベルですべてをコーディングすることを好み、より簡単だと感じています。だから、私はそれが古い帽子になっていると感じています。

于 2010-08-31T12:23:53.450 に答える