sql - SQLではなくISAMを選択する

Question

多くの開発者は、アプリケーションの設計に手続き型コードと実質的なデータベースの両方が必要な場合、脅迫されたり、少し圧倒されたりするようです。ほとんどの場合、「データベース」とは、SQLインターフェイスを備えたRDBMSを意味します。

それでも、2つのパラダイム間の「インピーダンスの不一致」に対処するための手法の多くは、テーブル、インデックス、行を指定できる（必須の）ISAM（インデックス付きシーケンシャルアクセス方式）ツールセットにはるかに適しているように思われます。 -naviagationなど-あからさまに-たとえば、ActiveRecordモデルによって規定された動作。

PCの初期には、dBASEとその子孫が主要なdbmsプラットフォームであり、拡張ISAMでした。Foxproは、この系統を今日まで非常にうまく続けています。MySQLとInformixは、少なくとも最初はISAM実装の上に構築された2つのRDBMSであるため、このアプローチは少なくとも同等のパフォーマンスを発揮する必要があります。SQLに不満を持っている多くの開発者は、少なくとも無意識のうちにISAMアプローチの復活を望んでいるように感じます。データベースは、非常に効率的なリンク可能なハイパーアレイのセットとしてより簡単に表示できます。それは本当に良い考えかもしれないと私には思えます。

たとえば、ORMからISAMへの実装を試したことはありますか？どのくらい成功しましたか？そうでない場合は、試してみる価値があると思いますか？このモデル用のツールセットは明示的にありますか？

score 3 · Accepted Answer

多分ピッグラテンはあなたが欲しいものですか？この記事によると http://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=693D79B5EFDC0452E1C9A87D1C495D4C?doi=10.1.1.124.5496&rep=rep1&type=pdf：

「その上、このデータを分析する人々の多くは、宣言型SQLスタイルが不自然であると感じる、定着した手続き型プログラマーです。より手続き型のmap-reduceプログラミングモデルの成功と、それに関連する商品ハードでのスケーラブルな実装- wareは、上記の証拠ですが、map-reduceパラダイムは低レベルで厳格すぎるため、保守や再利用が難しい大量のカスタムユーザーコードにつながります。PigLatinと呼ばれる新しい言語について説明します。 SQLの宣言型スタイルとmap-reduceの低レベルの手続き型スタイルの間のスイートスポットに収まるように設計されています。」

score 2 · Accepted Answer

確かに、ISAMが本格的なSQLDBMSよりも少ないコストとオーバーヘッドでアプリケーションに必要なサービスを提供する時間と場所があります。ISAMメカニズムの欠点の1つは、データを記述するためのシステムカタログが必ずしも存在しないことです。もう1つは、一般に、データを取得するためのユーザーフレンドリーなツールがほとんどないことです。これらは両方とも、RDBMSがかなりの利点を提供する場所です。最高のISAM（または同様の）システムは、トランザクションサポートを提供します-XAトランザクションでさえも。

複雑な結合と計算（たとえば、集計）を実行する必要がある場合、DBMSによって実行される作業には大きなメリットがあります。必要なのがレコードへのアクセスだけである場合、ISAMは有益である可能性があります。

ISAMベースのシステムでは、DBMSよりもセキュリティを強化するのが難しい傾向があります。また、クラッシュした場合に備えて、ファイルの整合性について心配する必要があります。ほとんどのDBMSは、2プロセスアーキテクチャ（DBMSサーバーとは別のプロセスにあるDBMSクライアント）を使用します。これにより、クライアントがクラッシュした場合（またはクライアントPCの電源がオフになった場合）に復元力が提供されます。また、バックアップと復元についても心配する必要があります。有能なDBMSには、データベースの使用中にデータベースの一貫したバックアップを提供するためのシステムがあります。ISAMシステムがそのレベルの整合性を提供するかどうかは明らかではありません。

全体として、適切なISAMメカニズムがあれば、完全なRDBMSの代わりにORMシステムでISAMメカニズムを使用することには、少なくとも時々、おそらくしばしば利点があります。

score 1 · Accepted Answer

私は1990年代にORM-to-isamライブラリを実装しましたが、シェアウェアとしては（非常に）ささやかな成功を収めました。ISAMの長所についてのあなたの意見にほぼ同意します。柔軟性と速度のみを求めている場合は、ORMレイヤーまたは製品を構築するときにISAMを使用する方がよいと思います。

ただし、現在市場に出回っているさまざまなSQL関連製品のメリットを失うリスクがあります。特に、レポートツールは、最も人気のあるSQLパッケージとこれまで以上に緊密に統合されるように進化しました。1990年代のISAM製品ベンダーはCrystalReportsなどの製品と統合するためのODBCドライバーを提供していましたが、それでも、市場はISAMから離れる傾向にあり、そのテクノロジーを使い続けると陳腐化するリスクがあるように見えました。そこで、SQLに切り替えました。

注意点：ISAMサンドボックスで遊んでから10年近く経ちます。そのため、最新のISAMツールとこの問題の解決策について説明することはできません。ただし、ツールのサポートを報告しないと閉じ込められないだろうと確信しない限り、その長所に関係なく、ISAMベースのORMを採用することはありません。そして、それはSQLベースの開発に利用できる他のツールさえもカバーしていません！

score 1 · Accepted Answer

私はdBase、Clipper、FoxProを共有しました。ただし、SQLによって提供されるリレーショナルモデルは、はるかに強力で便利であり、OracleやSQLServerなどの製品は市場で成功するに値すると思います。

複雑なクエリ（主にレポート）とバッチデータの移動を処理するために、ケースの80〜90％のマッピングレイヤーを作成し、カスタムSQLの10〜20％を作成することで、人々がこれほど多くのことを行う理由にはいつも驚いています。休止状態やアクティブレコードなどに対する憎しみのレベルを考えると、DAL / DAOモデルを採用することで、本当に良いことや愚かなことをしているに違いありません。以前のベトナムの議論をご覧ください。

score 1 · Accepted Answer

多値データベースの誰か? (別名 Pick) XML をタグなしで考えてください。それらは RDBMS よりも少なくとも 10 年前から存在しており、どこを見ればよいかを知っていれば、依然として強力です。

score 1 · Accepted Answer

データで何をしたいのか、どのようにそれをしたいのかが正確にわかっている場合は、ISAM を選択してください。正確なニーズに対応するようにインデックスを構築しているので、満足するでしょう。ニーズが変化した場合は、インデックス作成を変更する必要があることを前もって知っておいてください。データアクセスは非常に高速になります。

データの用途がわからない場合、またはデータのニーズが時間の経過とともに大幅に変化することがわかっている場合は、SQL を選択してください。アドホッククエリ、迅速なレポート作成、データマイニングなどの柔軟性が得られます。

どちらのタイプのデータベースも、長年にわたって成熟してきました。どちらも、ライブバックアップ、トランザクション、セキュリティ、メタデータなどを備えた堅牢なサーバーを持つことができます。

score 0 · Accepted Answer

古い質問ですが、興味深い議論です。ISAMの概念は重要です。今日の RDBMS で提供されている追加機能 (バックアップ、一貫性、セキュリティ、メタデータなど) は、大きなメリットをもたらします。

NoSQL の熱狂 (そうですよね…熱狂) は、RDBMS 内で ISAM のようなアクセスをモデル化できないという意味ではありません。できる限り多くのロジックを DB にプッシュするつもりですが、「従来の」データグリッディング/多次元データ補間のような場合があり、独自のロジックを介して必要なすべてのレコードをトラバースします。索引。

sql - SQLではなくISAMを選択する

7 に答える 7

Related

Reference