3

過去 1 年間、CouchDB、MongoDB、RavenDB などの NoSQL json ベースのデータベース (キー/バリュー ストアではない) の豊富な種類のデータベースを使用して、数多くのプロジェクトを作成してきました。私は自分の採用について仲間のプログラマーとよく話しますが、「もちろん、SQL RDBMS システムにはまだ場所があります。特定のプロジェクト/タスクに最適なものは常にあります」とすぐに追加しますが、少し免責事項として、見られないようにします。クールエイドの酒飲みとして、しかしそのかなり浅い声明。すでに RDBMS に投資しているレガシー プロジェクトや、Oracle を主張する企業命令以外では、SQL データベースを選択する将来のグリーン フィールド プロジェクトを考えるのに苦労しています。豊富な map/reduce、変更フィード、レプリケーション サポート、RESTFUL API を備えた、私が見る限り、その CouchDB はずっと (プラグのように聞こえ始めて申し訳ありません)

(スクリーンキャストを超えて) NoSQL Json M/R データベース (CouchDb など) を「取得」する人たちに聞きたいです。どのようなプロジェクトで MS-SQL、Oracle、Postgresql などを使用すると思いますか..将来的には?

ありがとう

4

2 に答える 2

4

SQL の最大の強みの 1 つは、ほぼすべてのモデル化に標準的な方法があることです。特定のプロジェクトでは、最適なソリューションが提供されない場合がありますが、妥当なソリューションが提供されます。これは、企業環境では、将来のプロジェクトに完全に不適切になるというリスクなしに、単一のシステムを持つことによるメンテナンスの利点を得るために、すべてを Oracle に格納することを決定できることを意味します。

多くの計画を必要とせずにさまざまな要件を処理できるこの機能は、開発の 6 か月後まで設計が承認されないプロジェクトの開始時にも関係します。これは主に企業の開発に適用されます。

一般に、NoSQL を適切に使用するには、SQL 開発よりも優れた開発者が必要です。利用可能な多くの SQL コード サンプルの 1 つは、自分が何をしているのかほとんど知らない人でも、動作するシステムに編集できます。NoSQL は、パフォーマンスの整合性チェックを排除するなどのことを行います。優れた開発者は、無効なレコードを挿入しない十分にテストされたコードを作成したり、特定のアプリにとって無効なレコードがいくつか問題にならない理由を理解したりします。悪い開発者は、エラー メッセージのないものはすべて良いコードだと考えます。成功している Web スタートアップの平均的な開発者は、おそらくそれを処理できます。社内アプリを管理している平均的な開発者は、おそらくそうすることができません。

プラットフォームの選択を完全に制御し、要件と開発者の両方を知っている自分のプロジェクトでは、NoSQL はあなたが提案するのと同じくらい優れた完全なソリューションです。コーディングが容易で、保守が容易で、パフォーマンスが向上し、水平方向のスケーリングという技術的な利点以外には、特に重要なことはありません。

企業環境では、無能な開発者、不明/変化する要件、長いアプリケーション ライフ サイクル、システム数を最小限に抑える必要性など、他の現実が支配的です。NoSQL は、そのような問題セット向けに設計されていません。

于 2011-01-05T22:31:13.050 に答える
2

一方で、データが本質的にリレーショナルである場合は、RDBMSが最適な選択であると簡単に言えます。たとえば、注文管理システムはRDBMSに最適です。データが本質的にリレーショナルではない場合（たとえば、Googleの検索インデックスなど）、NoSQLよりも優れた選択肢です。彼らは両方とも彼らの場所を持っています。

私の最新のアプリケーションは、サブオブジェクトを含むサブオブジェクトを含むオブジェクトを含む大規模な階層/リレーショナルであり、すべて自然キーによって関連付けられています。これはRDBMSに最適であり、NoSQLDBでははるかに扱いにくいものでした。

于 2011-01-05T06:09:53.513 に答える