多くのCRUDを含む通常のWeb開発にオブジェクトデータベースまたはリレーショナルデータベースを使用することの短所と長所は何ですか？
更新：私はネビルにそれを与えるために賞金報酬を再開しました。
6102 次
8 に答える
20
OODBMSの概念はかなり壊れており、過去数十年にわたって出現したさまざまな商用および無料の製品は、市場でほとんど機能していません。
リレーショナルモデルは、データに対して尋ねることができる質問の種類の点で、オブジェクトモデルよりも強力です。残念ながら、SQLはリレーショナルモデルが可能な表現力の多くを捨てましたが、この希薄な形式でも、一般的なOOデータベース（ORMまたはOODBMS）よりもSQLでクエリを表現する方が簡単です。
OODBMSでのクエリは、主にナビゲーションオペレーターによって駆動されます。つまり、販売データベースに販売担当者がいる場合、特定のSKUの月間販売のクエリは、ひどく遅くなるだけでなく、表現するのが非常に厄介になる可能性があります。従業員に建物へのアクセスを許可するセキュリティモデルも検討してください。これを表現する正しい方法はどれですか？従業員は、アクセスできる建物のコレクションを保持する必要がありますか、それとも建物にアクセスできる従業員のコレクションを保持する必要がありますか？さらに重要なのは、なぜどちらかのクラスがもう一方のコレクションをその設計に焼き付けなければならないのでしょうか。そして、どちらを選んだとしても、どのペアの従業員が共通してアクセスできる複数の建物を持っているかをどのように尋ねますか？そのような質問に答えることができる簡単なナビゲーションパターンはありません。
また、OODBMSで宣伝されているもう1つの大きな強み、メソッド、特に仮想メソッドによる継承についても検討してください。スポーツクリニックでは、アスリートの種類ごとに怪我のリスクの指標が異なる場合があります。ORMの世界では、これはルートにあるクラス階層とAthlete仮想メソッドとして自動的に表現されます。int InjuryRiskScore()各派生クラスによって実装されます。問題は、この方法がバックエンドではなくクライアントに常に実装されていることです。したがって、クリニックのすべてのスポーツで最もリスクの高い10人のアスリートを見つけたい場合、それを行う唯一の方法は、それらを配線し、クライアント側の優先キューに渡します。OODBMSの世界もわかりませんが、ストレージエンジンは通常、クライアントのプログラミング言語でオブジェクトを再水和するのに十分なデータしか格納しないため、同じ問題が発生すると思います。リレーショナルモデルまたはSQLでは、怪我のリスクのスコアリングをビューとして表現します。これは、単にアスリートごとのビューの結合である可能性があります。次に、質問するだけです。または、「先月の健康診断以来、怪我のリスクが最も高くなったのは誰ですか？」など、より複雑な質問をすることもできます。または、「昨年、どのリスクスコアが傷害の最良の予測因子であることが証明されましたか？」最も重要なことは、これらの質問はすべてDBMS内で回答でき、質問と回答はネットワーク上を移動するだけです。
リレーショナルモデルを使用すると、DBMSは述語論理に基づいて高度に蒸留された方法で知識を表現できます。これにより、そこに格納されているファクトのさまざまな次元を結合、投影、フィルタリング、グループ化、要約、または完全にアドホックに再配置できます。マナー。これにより、システムが最初に設計されたときに予期されていなかった方法でデータを簡単に作成できます。したがって、リレーショナルモデルは、私たちが知っている知識の最も純粋な表現を可能にします。要するに、リレーショナルモデルは純粋な事実を保持します—それ以上でもそれ以下でもありません（そして確かにオブジェクトやそのプロキシではありません）。
歴史的なメモとして、リレーショナルモデルは、当時の既存のネットワークと階層型DBMSとの悲惨な状況に対応して出現し、アプリケーション領域の小さなニッチを除いてすべて（そしておそらくこれらも）それらを大部分（そして当然のことながら）置き換えました主にSQLがRMの能力を発揮できなかったために残った）。業界の多くがネットワーク理論データベースの「古き良き時代」を本質的に切望していることは非常に皮肉なことです。これは本質的にOODBMSと現在のNoSQLデータベースが戻ってきているものです。これらの取り組みは、SQLが今日のニーズを満たしていないことを正しく批判していますが、残念ながら、SQLはリレーショナルモデルの忠実度の高い表現であると（間違って、おそらく純粋な無知から）想定していました。
于 2011-03-19T03:38:04.613 に答える
17
リレーショナルデータベース：
長所：
- 確立されたテクノロジー-多くのツール、開発者、リソース
- 幅広いオープンソースおよび商用製品
- 非常に大規模なサイトに拡張でき、スループットが非常に高いことが知られています
- 多くの問題のあるドメインを論理的かつ「プログラム可能な」方法で表現します
- かなり標準的な言語（SQL）
短所：
- オブジェクト指向の概念とのインピーダンスの不一致-データベースでの「継承」のモデリングは自然ではありません
- 階層構造には通常、言語に対するベンダー固有の拡張が必要です
- 非リレーショナルデータ（ドキュメントなど）は自然に適合しません
- スキーマが定義されると、ビジネスドメインの変更を実装するのが難しい場合があります
OOBDMS
長所：
- OOの概念により近い
- 理論的には、開発者は1つの言語で作業するだけで済み、永続性の詳細は抽象化されます。これにより生産性が向上するはずです
短所：
- 利用可能なツール/リソース/開発者が大幅に少なくなります。
- 広く受け入れられている基準はありません
- 永続性への「ブラックボックス」アプローチは、パフォーマンスの調整を困難にする可能性があります
- 永続性の詳細は、OOデザインに漏れることがよくあります（Marceloの例を参照）
于 2011-04-08T12:36:15.427 に答える
4
私がよく知っている1つのオブジェクトデータベースZODBに関してあなたの質問に答えることができます。
ZODBを使用すると、データモデルをほぼ完全に透過的に永続化できます。その使用量は次のようになります。
# 'Persistent' allows us to save things transparently
class Car(Persistent):
def set_wheels(number)
self.wheels = number
# 'database' is a ZODB database
database.car = Car()
database.car.set_wheels(3)
RDMBSでそのような読みやすさを見つけるには、長い時間をかける必要があります。WebアプリケーションでZODBを使用することには大きなメリットがあります。
Marcelloが概説しているように、大きな欠点は強力なクエリがないことです。これは、上記のイディオムの利便性の副作用の一部です。以下は完全にOKであり、すべてがデータベースに永続化されます。
database.car.colour = "yellow"
database.car.owner = "Trotter"
database.car.neighbour = Car()
ただし、この種の柔軟性により、異なるモデル間で複雑なクエリを最適化することは困難です。O(n)自分のインデックスを作成しない限り、隣人と一緒にすべての黄色い車のリストを作成するだけでも時間がかかります。
つまり、「定期的なWeb開発」の意味によって異なります。多くのWebサイトは、実際には複雑な多次元クエリを必要とせず、線形時間での検索はまったく問題ありません。そのような場合、RDBMSを使用すると、コードが複雑になりすぎる可能性があります。私は、オブジェクトデータベースのみを使用して多くのCMSタイプのアプリケーションを作成しました。多くのCRUDは特に入りません。ZODBは非常に成熟しており、スケーリングとキャッシュが非常にうまく機能します。
ただし、Google Analyticsに沿って複雑なビジネスレポーティングを行う必要のあるWebアプリケーションや、数テラバイトのデータを含むある種の倉庫在庫管理システムを作成している場合は、間違いなくRDBMSが必要になります。
要約すると、オブジェクトデータベースは、複雑なクエリパフォーマンスを犠牲にして、読みやすさと保守性を提供できます。もちろん、読みやすさは意見の問題であり、さまざまなオブジェクトデータベースの方言よりもはるかに多くの開発者がSQLを知っているという事実を無視することはできません。
于 2011-04-08T15:01:18.857 に答える
3
通常のWeb開発では、GemstoneでSeasideを使用しています。ほとんどのアプリケーションでは、それは私がゼロのデータベース接続コードを書くことを意味します。パフォーマンス、スケーリング、開発は約5倍高速です。
Web開発にリレーショナルデータベースを再び使用するのは、既存のデータベースに接続する必要があるときだけです。
利点：
- より少ないコード、より速い開発;
- はるかに優れたスケーラビリティ。
- はるかに複雑なモデルを処理できます。
- プロジェクトの敏捷性が大幅に向上します。
- 柔軟性について言及しましたか。
- データだけでなくコードも含めて、クラスモデルの変更を処理できます。
短所：
- おそらく、開発者を自分でトレーニングする必要があります。
- 必要なもの（宝石）は、大規模なシステムには多額の費用がかかります
于 2011-04-09T15:59:22.297 に答える
3
リレーショナルデータベース
- SQLと標準
- モデル化が簡単
- 標準タイプとベンダータイプのみを使用できます
- 参照整合性（数学的に堅実なリレーショナル集合論）
- 多くのツールとデータベースの実装
- プログラムとは別のデータ
- ストレージ管理とハイエンドインフラストラクチャのサポート
- 内で行われるトランザクションと同時実行の管理
- リレーショナルモデルは値ベースです。つまり、行は主キーによって識別されます
短所
- カスタムタイプなし
- 拡張可能なデータ型はありません
- インピーダンスの不一致
- 入れ子関係を表現できない
- 複雑なエンティティを単一のユニットとして使用することはできません
- データモデルレベルでキーとさまざまなタイプの関係を定義する必要があります
- バージョン管理の手順、必要に応じてトランザクションを作成する
オブジェクトDB
- ハイパフォーマンス
- 結合が不要なため、より高速になります
- 固有のバージョン管理メカニズム
- 操作用のナビゲーションインターフェイス（グラフトラバーサルなど）
- オブジェクトクエリ言語は宣言的にオブジェクトを取得します
- 複雑なデータ型
- オブジェクトのアイデンティティ、すなわち。equals（）では、オブジェクトIDは値や更新に依存しません
- オブジェクトの共有を容易にします
- クラスと階層（継承とカプセル化）
- 関係のサポート
- ODLのような永続言語と統合
- アトミック性のサポート
- ネストされた関係のサポート
- セマンティックモデリング
短所
- RDBとしての数学的基礎はありません（Coddを参照）
- オブジェクト指向の短所
- 複雑な構造では永続性が難しく、一部のデータは一時的なものでなければなりません
オブジェクトリレーショナルデータベース（UDTを見たことがあるかもしれません！）
- コレクション、マルチセットなどの複雑なデータ型のサポート
- オブジェクト指向データモデリング
- 拡張SQLとリッチタイプ
- UDT継承のサポート
- 強力なクエリ言語
アプリケーションごとに異なるアプローチ（OO、リレーショナルDB、またはOODB）が必要になる場合があります
参考文献
比較
http://en.wikipedia.org/wiki/Comparison_of_relational_database_management_systems
http://en.wikipedia.org/wiki/Comparison_of_object_database_management_systems
http://en.wikipedia.org/wiki/Comparison_of_object-relational_database_management_systems
于 2011-04-16T11:38:22.173 に答える
1
私はすべてがあなたの問題の詳細に依存すると思います。（私は本当にここで手足に出かけています、私は知っています。）
私たちが知っているのは、Web開発にDBを使用したいということだけであり、データに対して多くの操作を行うことになります。
自分自身に問うべき関連する質問の1つは、DBを操作するオブジェクトと緊密に統合することがどれほど重要かということです。必要が多ければ多いほど、オブジェクト指向DBはそれ自体を推奨します。
一方、データがリレーショナルモデルに適している場合は、リレーショナルDBの方が適している可能性があります。
実行する必要のある操作について考えてください。さまざまな属性を持つあらゆる種類のアイテムの分析が必要ですか？DBを将来にわたって利用できるようにするために必要な金額はどれくらいですか？
DBがかなり小さい可能性が高い場合、パフォーマンスは大きな問題にはならないことを付け加えておきます。しかし、実際にパフォーマンスが問題である場合は、OOとリレーショナルDBだけでなく、多くのことを心配する必要があります。（リレーショナルDBの世界から1つの例を選択するだけで、どの正規化形式を使用する必要がありますか？これは非常に重要で複雑な質問です。運用システムまたはデータウェアハウスを維持していますか？特定のクエリが最も重要なのか、それとも無視できるほど重要なのか？＆c。）
DBのパフォーマンスとオブジェクトモデルとの統合の問題以外にも、実際に尋ねるべき質問があります。ディスクスペース/サーバー/帯域幅の制限はありますか？Webユーザーに提供する操作の数はごくわずかですか、それとも知らない人が独自のクエリ/編集を作成している可能性がありますか？
他の、より重要な、現実の質問については、誰と協力しますか？彼らはすでに何を知っていますか（または好みますか）？そして、あなたがまだドメイン知識を持っていないのなら、多分あなたはあなたを一方向に押しやる個人的な好奇心を持っていますか？個人的なプロジェクトを開始する場合は、開始する前にパフォーマンスを心配するよりも、自分の好みに従う方が成功へのより良いガイドです。
これらの質問や同様の質問に答えることができれば、「わからない」と答えたとしても、より良い方向性を得ることができます。
于 2011-04-04T09:08:05.043 に答える
1
マルセロの徹底的でよく考えられた応答との契約で、私はあなたの質問「定期的なウェブ開発」の言い回しに基づいて、あなたが十分なプロを見つけるのは難しいだろうと言うでしょう。従来のリレーショナルデータベースよりもオブジェクトDBを使用することを正当化するため、従来のリレーショナルモデルに精通しているリソース/開発者/チュートリアルなどが多いという単純な事実と、それを利用して「通常のWeb開発」を実現する方法。
とは言うものの、最新のORMのいくつかでは、基盤となるデータがよく理解されているRDBMS（安定している、サポートされているなど）に格納されているという点で、両方の長所を少し活用できると思いますが、それでも、CRUDアプリケーションの開発により適している可能性のあるオブジェクトモデリング機能の一部を抽象化します。
私は現代のOODBMSの現在の機能に精通していないことを認めますが、ドメインの完全なオブジェクト表現を実現するのに完全に適した分野にいない限り（そして、オブジェクトモデリングの才能を活用する必要があります） ）、それなら私はあなたの永続的なストレージのためにRDBMSに固執するでしょう。
お役に立てば幸いです。
于 2011-04-06T20:21:35.453 に答える
0
これは、長所と短所をほぼ説明しています。
于 2011-03-18T21:54:01.033 に答える