過去の桐井戸端BBS (桐ver.8) |
3465 | 結合表による在庫更新の考え方 | 真太郎 | 1999/11/24-22:38 |
たびたびですいません。 話が漠然として理解してもらえるか不安ですが、 併合を使った処理では在庫更新等の処理は簡単に処理できるのに、 結合表だけを使って在庫更新等の処理をさせようとすると参照整合性とか リレーションとかで実現できません。 わざわざ、併合で処理できることをわざわざと思うでしょうが アクセスのクエリーでできてることなら桐の結合表でもできる と思って おります。 漠然ではありますが、結合表だけで在庫更新処理をされた方がいたら 教えてください。 お願いします。 | |||
3466 | Re:結合表による在庫更新の考え方 | 佐田 守弘 | 1999/11/25-00:05 |
記事番号3465へのコメント 真太郎さん ご質問のお話、良く分かります。というか、ちょうど今、桐ガイドブックでこ の話を書いていた所です。 さて、 >アクセスのクエリーでできてることなら桐の結合表でもできる と思いたくなるのですが、桐の結合表ではできない様です。 桐の結合表は(内部的には)クエリーであることは確かなのですが、クエリーそ のものというか、SQLの全てをサポートしているのではないと考えます。桐の 結合表はAccessでいえば、選択クエリーの機能に特化しています。 本来のRDBであれば、全てのDB操作は、クエリーを通じて行うのですが、桐の 場合、会話処理という独特のインタフェースを持っており、分かりやすく簡単 に処理できることを、あえてクエリーを使うことはないのではないか、といっ た考えが根底にある様です。 すなわち、Accessで言う追加クエリー削除クエリーといった機能は、桐の結合 表にはなく、追加は読み込みや併合で、また削除は絞り込みと行削除などで行 ない、クエリーを使っては操作しません。また表引きといったリレーション機 能も、桐独特の機能です。 これらの機能があるために、桐の結合表は表をつなぎ合わせる機能と、その中 から選択する機能だけに特化しているのでしょう。 桐の結合表は、内部的にSQLを生成している様に思うのですが、Accessの様に 、SQLのコードをユーザーには見せてくれません。ですから、ユーザーが直接 SQLを記述する事もできません。 その様な訳で、桐で在庫の更新をする時には、結合表ではなくて併合で行うの が正解だと考えます。 佐田守弘(KS-00119) PS: 結合表の中には何が書かれているのかと思って、ちょっと調べてみました。 Accessのクエリーこと、QBGグリッド画面の実体はSQL言語(のはず)と思うので すが、結合表の実体は表定義の様な内容の様です。 | |||
3474 | Re:結合表による在庫更新の考え方 | 真太郎 | 1999/11/25-08:49 |
記事番号3466へのコメント 自分で書いておきながら、理解してくださったことに感謝いたします。 なぜ、クエリーを持ち出したかといいますと実は大学に勤務しており ACOSを扱っております。 今後レベルアップでPC化が進む予定ですが、現在はACOSのデータへがコボル言語にて アクセスしてデータ処理をしておりますがデータウエアハウスなるものを導入して、PCに データを格納した後はそれぞれのアプリで処理する方向になってきています。 上層部の方で、RDBはアクセスという考え方があり、そこで桐を主張しておりますが なかなか、NECその他のソフト会社との関連もあり桐が今のとこマイナであるため アクセスと比較されてしまいます。 時代の流れでしょうね それでは、ちょっと話が脱線してしまいましたが、今後ともよろしくお願いします。 |