TDCソフト（TDC SOFT） MRDB NE：日本語リレーショナルデータベース管理システム

MRDBの関連情報ならびに、講習会、説明会のお知らせ等は下記をご覧ください。

MRDB V6の電子マニュアルはこちらからダウンロードしてください。

MRDBは、パソコン上で稼動する国産初のリレーショナルデータベースソフトとして、1984年にバージョン1が誕生以来20年の歴史を経て、DOS版からWindows版までの MRDBシリーズの総出荷実績は、実に15万ライセンスを誇ります。

1．	エンドユーザーでも使える開発ツール事務系アプリケーション作成に必要な機能を10種類に分類。パターンを選択していくだけで、手続き型言語(Basicやマクロ)に依存しないアプリケーション開発が行えます。直感的なオペレーションと日本語による開発のため、初心者の方でも覚えることが容易です。
2．	本格的なOAアプリケーションを開発するツール事務系アプリケーションに求められる様々な制御を、140個を越える関数として用意。関数はすべて日本語で、パラメータを与えるだけですので、オブジェクトに関数を埋め込めば、どなたでも簡単に高度な機能を利用できます。また、データの共有については、ファイル共有型からC/S型まで柔軟な対応が可能となっています。
3．	モード切り替えで言語開発のレベルまで機能拡張　環境設定にて、エキスパートモードを宣言すれば、スクリプトを利用して独自の関数を定義できます。複雑な動作・計算の定型化だけでなく、アプリケーション構造を簡略化し、メンテナンスビリティを高める事も可能です。また、「エキスパート・ディベロップメント・キット」を利用すれば、C言語で作成したユーザープログラムと連携することも可能です。

MRDB独自サーバー機能を装備、C/Sシステムが低コストで構築可能です。

1. C/S方式

(1) 特徴	・	検索条件式がサーバー側で実行され、結果のデータのみがクライアントに渡される。
(2) メリット	・	通信データ量は、必要な分だけのトラフィックとなる
	・	サーバーでクライアントの監視を行える。
(3)デメリット	・	ビュー表データに対しクライアントの内部IOバッファが有効にならない。
	・	ビュー表に対し一部の関数（%Last, %Max, %Min）では高速ロジックが有効にならない。
	・	参照関数は毎回実行される。
	・	ビュー表使用時、サーバモジュール呼出しオーバーヘッドが若干発生する。
	・	相当複雑な検索条件式の記述には長さ制限がある。

2. ファイル共有方式

(1) 特徴	・	サーバー上のファイル（MDB）をローカルDBとほぼ同等に扱う。
(2) メリット	・	内部IOバッファが効く。
		高速化の内部ロジックが働く。（%Last, %Max, %Min, %Count）
	・	参照関数を実行しないことがある。
(3)デメリット	・	データ通信量が多い。

3. 総評

(1)	回線スピードが低い場合は、C／S方式が有効である。
(2)	クライアント処理速度が遅い場合は、ケースバイケースだがC／S方式がやや有利である。
(3)	C／S方式において、大量のデータを一度に読み出すような処理は、サーバー側で検索条件が実行されるメリットよりも、高速化ロジックが働かないデメリットの方が勝ってしまう場合があるため、そのような処理（注1）は、サーバー側で行わせるような工夫（注2）が必要になる。
(4)	排他制御は、C／S方式とファイル共有方式でほぼ同じである。
(5)	通信環境が良い場合は、ファイル共有方式の方が性能的には良い場合がある。（ビュー表に対し%Last, %Max, %Minを使用する場合など）

（注1）	1．	クライアントにて、%LAST(), %MAX(), %MIN(), %COUNT()を使用している処理。
	2．	%REFFER()を複数使用している処理。
	3．	検索結果が大量になる処理や関数。
（注2）	1．	サーバー側で%LAST(), %MAX(), %MIN(), %COUNT()が実行できないか検討する。
	2．	%REFFER()の呼び出しを少なくする。
	3．	検索の結果件数を少なくする工夫をする。

1. サーバー表（ビュー表経由）に対する関数

表を扱う関数

状況

対処案

％最終値　

ファイル共有型に比べ大量データを持つ表に対し使用する場合、遅くなる場合が有ります。

ビュー表の出力式に記述された式はサーバー側で実行されます。そのため、％最終値はビュー表の出力式に記述し、クライアントでは、そのビュー表の項目値を参照関数などで得ることで、高速に最終値を得ることができます。具体的には以下のように設定します。

1.	サーバに最終値を得るためのビュー表で使用する実表を作成します。（項目の型と長さは、最終値を得る表の項目に合わせます。）
2.	その実表に1レコードだけレコードを登録します。（値は実際には使用しませんので、何でも良いです。）
3.	クライアントで、「1.」で作成した実表に対するビュー表を作成し、表項目の出力式に、最終値を得る表の項目に対する％最終値関数を記述します。なお、この％最終値関数で指定する表名、表項目名はサーバの表名、表項目名です。
4.	処理で％最終値関数の変わりに、「3.」で作成したビュー表の％最終値関数を出力式に記述した項目に対する％参照関数を記述します。その参照関数の結果が最終値になります。

％参照

処理の検索条件式に記載した場合、ファイル共有型に比べサーバにオーバーヘッドが掛かるため遅くなります。

1処理の中で複数の％参照関数を使用している場合、％参照関数で参照しているデータを表単位に一箇所の作業領域にまとめて取込み、その後、％参照関数を使用しているオブジェクトに分割して使用する方法があります。

値を検査する関数

状況

対処案

％有
％無

検索条件式や検査式への記述はできません。

検索で変数を使っていない場合、検索条件式を付けたビュー表を作成し、処理の検索条件式は削除します。

グルーピング関数

状況

対処案

％件数
％連番関数

ファイル共有型の処理の中の式に％件数、％連番などのグルーピング関数を使用している場合、対象レコードが大量になると遅くなります。

ビュー表を使った処理では、検索条件を指定して対象レコードを絞り込む処理に変更します。

関数の中のグルーピング関数の使用

状況

対処案

％参照（・・、％件数、・・）

参照する表にビュー表を指定し、条件式の指定がない場合、ファイル共有型に比べNEでは索引を使用しないため遅くなる場合があります。

大量のレコードを持つビュー表を関数の中の参照する表に指定している場合、ビュー表に作業項目を作成して、出力式に％件数を記述します。（％最終値の項をご参照ください。）

2. 関数以外

ビュー表	状況	対処案
ビュー表の結合	ファイル共有型では実表で結合しますが、NEのC／S方式ではビュー表を使う事になります。その場合、処理でビュー表を使用表として表の結合を行った場合、確認表示がONの状態では、「表の結合で、結合条件がないか結合のために索引が使えません。結合に時間が掛かります。また、この場合はアウタージョイン(*=)はできません。通常の結合(=)になります。処理を続行しますか？」メッセージが表示されます。また、遅くなる場合があります。	対処案1）各表に制約条件を記述し、対象となるレコード件数を少なくする各表に制約条件を記述することにより、結合操作の対象となるレコードを少なくします。例えば、3表の結合で @1key=@2key & @1key=@3key & @1key=@@変数のような条件の場合は、 @1key=@2key & @1key=@3key & @1key=@@変数 & @2key=@@変数 & @3key=@@変数のように記述することで、検索結果の件数が少ない場合には、ある程度の性能改善が期待できます。対処案2）ビュー表で表の結合を指定するビュー表で表の結合を行い、処理ではそのビュー表1表だけを指定します。この場合の結合操作はサーバで行われるため、かなりの性能改善が期待できます。（各使用表のサーバが異なる場合には、性能改善は期待できません。）
表のアウタージョイン	状況	対処案
アウタージョイン	NEではビュー表を指定したアウタージョインは使えません。
並べ替え指定	状況	対処案
処理の中で指定	ファイル共有型に比べ遅くなる場合があります。	遅くなった場合、ビュー表の出力式に並べ替えを指定する方法に変更します。処理はそのままとします。
複雑な検索条件	状況	対処案
	処理の検索条件が複雑な場合、遅くなる場合があります。	ビュー表の作成時に検索条件を指定するようにします。

ユーティリティー機能を強化し、より高い開発生産性を実現。
・クロスリファレンス機能の包含
・ツリー表示機能
・ MDB暗号化