
![]()
当社は、2000年創業以来、一貫して基幹業務システムを構築してきましたが、画面処理を伴わないプログラム(以下、バッチ処理)の標準化をどうするかの思考過程で生まれたものです。原型は、2005年当時に開発し、実際に利用して、大きな成果を実感しています。以来、当社においてほとんどすべてのバッチプログラミングはしておりません。SQLSに与える実行制御XMLのみの記述で処理を行っております。
SQLSを利用すると大変安価に確実に業務システムを構築できることを実際のシステム構築を通じて実感しています。
必要知識はDB設計技術とSQL文のみです。通常のプログラミングする場合ですと、この他に言語知識、オブジェクト指向知識、ログ出力などの標準化ルールも別途必要になります。
この様にSQLSは、必要最小限の知識でシステム構築に着手できますので、教育を最小限にしてシステム構築業務に参画できることになります。それでなお且つ、生産性が高く、品質のバラツキを少なくできます。業務システム構築の一番重要な知識はDB設計ですが、空いた工数をそちらに振り向けることができます。
当社がSQLSを用いてシステム構築する対象は、これまで、汎用コンピュータ、オフコンで行われてきた領域です。例えば、購買管理、販売管理、在庫管理などの基幹業務です。
そんな活用にあって、処理速度についても問題を感じておりません。SQLSを実行するDB管理システム(以下、DBMS)とハードウエアの進展はすさまじく、10年程度以前の汎用コンピュータと比べても数倍の速度で実行してくれます。またDBMSは、ネットワーク分散も安定しており、複数のコンピュータからの分散処理環境も実現してくれます。
SQLSはDBMSの安定とハード進歩を最大限活用する仕組みなのです。
当社では、SQLSによるバッチ処理のほか、画面プログラムの自動生成、JOBの実行管理システムの整備にも同時に取り組んでいます。SQLSと組み合わせて劇的なコストダウンを実現しています。
一度、SQLSをご評価頂き、その効果を実感してください。
本製品は、特許出願中です!
| NO. | ファイル名 | 備考 | |
|---|---|---|---|
| SQLS-0 | 15P/3256KB | ||
| SQLS-1 | 2P/168KB |
||
| SQLS-2 | 2P/131KB |
■詳しくは、ダウンロードページをご覧ください。尚、本ページ、最下段にモニター募集のお知らせを掲載しています。
A⇒ 当社もオブジェクト指向に積極的に取り組んでおります。特に画面プログラムにおいては部品(クラス)の組み合わせで、プログラミングを効率化しています。 その中で私たちが着目した点は、これらの画面プログラムと画面を伴わないバッチプログラムに分離してシステム構築するということでした。
分離されたバッチプログラムは、SQLの順次実行で構成される場合がほとんどなので、SQLSによるプログラムレスの仕組みを作成したのです。そうする事で、驚くほどシステム生産性が上がりました。A⇒ DB操作をあるクラスに集中させるという考え方は効率的と考えています。当社も画面プログラムではそうしています。でもバッチ処理においては、クラスすら作成する必要が無いと考えています。
その中で考えなければいけない事は、クラスは共通クラスを作成する個人・グループにより標準化され、プログラマーに提供しますが、SQLSの場合は、その利用者(機能を作成する人)自身がSQLの基本知識が必要ということです。
しかし、当社としては、「クラス利用者のSQL知識が不要」という考え方には疑問を持っています。A⇒ 現時点で、DBMS間の利用法差異がどの程度存在するかは、明確に存じていません。
しかし、SELECT、UPDATE、INSERT、DELETEの基本構文が異なっているとは思えません。業務システムで利用する命令はこれらがほとんどですからこの問題が発生していると思っていません。
私たちの経験では、OracleとSQLServerでは、DBMS差異をあまり感じませんでした。もしあるとすれば、処理スピード、サポート体制などでしょうか?A⇒ 順序が必要な処理です。例えば、トランザクションデータとして、1番目のレコードで、あるテーブルのレコードを作成し、2番目のデータでそのレコードを更新する場合などです。この様な例ですと最初に2番目のレコードで更新すると、NOT FOUNDになってエラーとなります。
この様な場合は、DBMSが用意する手続き言語(Oracleの場合はPL/SQL)を利用しています。このスクリプトもSQLSから起動可能です。
これまで、現行システムコンバートの際に何回か遭遇しましたが、新規の場合は設計段階で排除できます。A⇒ 業務ロジックが動作定義XMLの中に記述されていますので、テキストエディターなどで簡単に確認でき、修正できます。
プログラムソースを開発環境に呼び込んで修正、コンパイルする必要がありませんので問題の修復、機能追加・変更に直ぐに対応できます。A⇒ 業務システムの構築においてDB設計が全てになります。当社の場合、ER図を用いてDB設計しています。ここは熟練者が入念に行います。
このDB設計が終了しますと、動作定義XMLを記述するだけ(機能説明書は作成)になります。新人にはSQL教育のみをしています。
プログラミング教育はキャリアパスの中でどこかで行わなければならない必須知識ですが、DBのデータ処理を行うだけであればSQL教育のみでOKです。A⇒ プログラム作成に比べて、その機能の大きさ、複雑さが異なるのでどの位かは一概には言えませんが、DB構成が作成されていて、機能説明が提示されていれば、SQL文を記述するだけなので、通常のプログラム単位を想定すれば半日を越えることは、まずありません。
当然ですが機能設計部分は、両者に差異はありません。A⇒ システム開発会社である当社が4年ほどのシステム構築業務中でバッチプログラムをほとんど作成しなかったという点。
汎用COBOLシステムのコンバート作業(500本-700本規模)でバッチ処理は、全て代替可能であった経験からです。1.社内利用4年間の実績から
当社の開発標準は、汎用コンピュ-タ時代の開発手法(経験)の幾つかを踏襲しています。例えば画面プログラムとバッチプログラムの分離。そしてジョブ管理による実行などです。(最近の開発ですと画面プログラムに多くの機能を実装するケースが多い様に感じております。)
分離したバッチプログラムの部分にSQLSを適用し、業務システムのバッチ処理ではプログラムを製造していません。
(効果)
2.汎用コンピュータCOBOLプログラムの移行
SQLSを500本規模のCOBOLバッチ処理に適用致しましたが、すべて移行可能でした。COBOLロジックをSQLにする事は当初、速度の点で不安を感じておりましたが、サーバのCPU速度の向上などで、逆に数倍の処理時間の短縮が可能でした。10年程度前の汎用機と比べるとシングルCPU-2GHZ程度(30万円前後のサーバー)でも数倍の高速性があります。
この事から、これまでCOBOLで行ってきた、抽出、集計、並び替え、マッチングはすべてSQLSで可能との自信を得ました。
(確認したこと)
3.風神レポートとの接続
業務システムの多くは、画面での情報入力、バッチ処理、帳票出力となります。汎用コンピュータやオフコンの時代では、帳票出力処理は全プログラムの半分を超えていたと認識しております。
現在では、画面検索の強化、データ渡しによるエクセル連携により、その比率は若干は減っていると考えられますが、まだ結果出力としての帳票の役割は大きいと認識しております。SQLSは、DBの内容を自由にCSV出力できますので、風神レポートと連携して簡単、安価に帳票出力が可能になります。
■実際に帳票作成デモができます!デモのご説明ページへ→
(効果)
1.評価版(無料)
機能は製品版と同じですが、SQL数が3つまでの制限があります。その他の制限は製品版と違いはありません。
評価版で十分に機能、有効性をご確認後、ご購入願います。
2.SQLSequencer
以下の内容で、販売しています。
3.製品サポート
4.システム構築コンサルテーション
当社は、2004年当時からSQLSの原型を利用して実際のシステム構築を行って参りました。DBの設計技法、作業用テーブルの工夫、JOB実行方式などです。
また、技術提携しております風神レポートの利用も大変、有意義な利用実績があります。
もちろん、SQLSを用いたシステム構築もお請けできます。
現在、SQLSの製品化に向け、最終的な機能変更、テストを繰り返しております。製品化を確実にする目的で、10社限定で、評価版を無料(製品化後は正式版)で配付させていただきます。以下のページでお問い合わせください。
※評価版はOracle、SQLServer、MySQLに対応可能です。