relational-database - マルチバリューデータベースの長所と短所

Question

マルチバリューデータベース（UniVerse）を使用してかなりの量の作業を行う必要がある新しい仕事を始めたところです。私が持っているデータベースの経験はリレーショナルデータベース（SqlServer）でほとんどなく、MVDの長所と短所がリレーショナルデータベースと比較されていることについての偏りのない情報を探しています。

オフィスの誰もがリレーショナルデータベースのバックグラウンドを持っている（そしてUniVerseを嫌っている）か、何年もここにいてそれを愛しています。

Answer 1

まず、免責事項です。私は UniData (UniVerse の姉妹 DB) を使用しており、時折ブログを書いているので、完全に公平であるとは言えません。しかし、私は試してみます。

ここでは、いくつかの考慮事項を示します。

• SQL DB と複数値 DB の大きな違いは、MVDB が 1NF に準拠していないことです。これには長所と短所があります。悪用される可能性がありますが (一般的に悪用されています)、非常に機能的な場合もあります。最大の利点は、特定のクエリをはるかに高速化できる結合テーブルが常に必要ではないことを意味することです。

• 通常の SQL DB と比較すると、まったく新しい方法でメタデータを保存します。各ファイル/テーブルには具体的なスキーマがありません。代わりに、データの解釈方法を示すレコードで構成される 1 つ以上の「辞書」ファイルがあります。これにより、データの複数の解釈 (生/大文字/小文字、組み合わせたフィールドなど) を格納できるだけでなく、列挙型と結合と同等の処理を実行することもできます。正しく行えば非常に強力です。

• 残念ながら、このコンセプトには多くの可能性がありますが、DBMS のツールセットには欠けています。開発は推進されていますが、その上に構築された既存および老朽化したソフトウェア システムの「光を維持する」という考え方によって推進されているように見える非常に少数のビジネス ケースです。統合用のツール (.NET コネクタ、SQL クエリ用の ODBC インターフェイスなど) はありますが、問題があります。たとえば、UniObjects .NET インターフェイスには、セキュリティの粒度がありません (基本的に、すべてかゼロか)。

• これは単なる DBMS ではなく、本質的にアプリケーション プラットフォーム全体です。UniBasic は .NET ベースの言語ほど強力ではありませんが、T-SQL を確実に凌駕し、ビジネス ルールをすばやく作成できます。

Answer 2

Dave が示唆したように、MV データベースは、取得しようとしているレコードのキーがわかっている場合に最適に機能するように設計されています。セットベースのデータベースシステムである SQL とは対照的に、レコードベースのデータベースシステムと呼ぶ人もいます。

それは、何をしようとしているのか、データをどのように構造化する必要があるのか​​、利用可能な他のツールによって異なります。私はほとんどの時間を MV (主に Revelation 製品) で作業しており、10,000,000 以上のレコード セットを定期的に処理しており、速度は問題ありません。

MV データベースの強度は、データが流動的な場合です。ほとんどのクライアントは、法律、医療、金融商品などのアプリケーションに使用しています。関係が複雑で、時間の経過とともに急速かつ大幅に変化する可能性があるアプリケーション。

MV と no SQL は実際には同じものではありませんが、同じ概念の多くを共有する no SQL の動きに目を通すことをお勧めします。

MV の主な欠点は、ツールよりもその構造にあります。一般に、開発者ベースが小さいため、利用できるツールキットとヘルプが小さいことがわかります。また、ほとんどのオファリングで提供される組み込みの基本言語には、慣れ親しんだオブジェクト スタイルのコーディングが欠けていることに気付くかもしれません。JavaScript でさえ、言語としてより多くの機能を備えているように見える場合があります。

そうは言っても、MV データベースは主に巨大な文字列であるため、言語の文字列処理は優れています。HTML および XML 文字列を直接操作するのに最適です。

私が持っている大きな質問だと思いますが、具体的な質問はありますか? Windows から Linux や Mac に移行したり、Debian から Red Hat に移行したりするようなものだと言って戦争を始めるつもりはありませんが、構造とシステムが異なるため、概念、強み、制限、および目的が異なります。 . SQL のような MV データベースを処理しようとすると (可能です)、それが最適ではないことがわかります。不十分に設計された MV データベースは、欲求不満の練習になる可能性があります。適切に設計された MV データベースは、美しいものになる可能性があります。

Answer 3

MV データベースは、比較的低電力のサーバーから素晴らしいパフォーマンスを引き出すことで知られています。

それらはリンク ハッシュ ファイリング システムを使用して、ほとんどのファイル アクセス操作を数学的操作に減らし、レコード キーがわかっている場合は 1 つのディスクを読み取ります。適切に構成されたシステムでは、レコード キーがわかっている限り、1,000,000,000 レコードのファイル ファイルからの読み取りは、1,000 レコードのファイルからの読み取りよりも長くかかりません。

レコード キーは一意である必要があり、アルゴリズムまたはプログラムによって決定できるようにレコード キーを設定できるアプリケーションでは、データベース アクセスに伴うオーバーヘッドを最小限に抑えることができます。しかしもちろん、これには通常、おそらく「リレーショナル」とは見なされない方法でデータベースにアクセスすることが含まれます。

Answer 4

それ自体には長所と短所はありません。値を格納するために異なる方法を使用しているだけです。UniVerse は区切り文字を使用して値を区切ります (IIRC では char(254) と char(253) を使用してフィールド内の複数の値を分割し、char(255) を使用してデータ ファイル内の実際のレコードを分離します。間違っている可能性があります。でも、最後に使ってから10年以上経ちます。）このデータ保存方法を好む人もいれば、最近のモデルよりもヴィンテージカーを好む人もいれば、現代の自動車の代わりに馬車を好む人もいます。（もちろん、これは私の意見です）。

フィールド内に複数の値を格納するということは、SQLServer が使用する余分なテーブルがないことを意味し、効果的に非正規化のレベルを持っています。これらの複数の値を使用することは、UniVerse とネイティブに連携するテクノロジ (以前は CueBIC と呼ばれるウィンドウ システムを使用していました) を使用する場合はすべて簡単で適切ですが、C++ や VB などの別の言語からデータベースに接続すると PITA になります。レコードを読み取って値を自分で分離する必要があります。つまり、これらの複数の値を検索することも困難でした。

しかし、もう一度言いますが、私が最後に使用して以来、物事が進んでいる可能性があります.NetプラットフォームからUniVerseと簡単にインターフェースできるように、誰かが素敵なドライバーを書いたのかもしれません. あなたのために彼らが持っていることを願っています。

Answer 5

ファイル内の多数の項目 (レコード) へのスケーリングはうまく機能します。レコード内の多数の値またはサブ値にスケーリングすると、パフォーマンスの問題が発生します。アプリケーションの設計は、数千のしきい値を下回る制限値およびサブ値リストに敏感である必要があります。

弦の扱いが秀逸。整数処理と同様です。MV Basic 言語は緩く型付けされているため、コンパイラにあまり多くの強制を期待しないでください。とはいえ、MV Basic のソース項目は他のデータと同様であり、コンパイラは DB 環境のもう 1 つの動詞であるため、コード ジェネレータとプリコンパイラの記述は簡単です。アプリケーションの下にツール層を構築するのに適した環境です。