「桐」を採用するか「Access」か？

過去の桐井戸端ＢＢＳ　（桐談義・その他）

18987	「桐」を採用するか「Access」か？	daipon	2003/02/16-13:49
今まで成績処理を「ACCESS」でおこなってきたものです。今回、桐Ver9が登場したことで、もう一度「ACCESS」と「桐」のどちらを採用するか判断をすることになりました。桐Ver9を購入して色々研究する予定ですが、桐にくわしいこのサイトの方々からアドバイスをいただければ幸いです。私が一番「桐」を採用するのに躊躇することは桐にクエリがない（？）ことなのです。具体的にいいますと、「桐」を使っている知人のテーブルはまるで表計算ソフトの表の感覚で HR NO 氏名国語数学生物物理・・・という項目がフィールドに設定してあって，それに点を入れて・・・という処理をしているのです。「これじゃあ表計算ソフトと同じじゃない？　年間△回ある成績を総合的に処理したり，3年間のデータを分析するときはどうするの？」と質問すると「必要なデータは併合して処理するよ」と答えが返ってくるのです。本当に「桐」とはそんな方法でデータを蓄えていくのでしょうか？　「ACCESS」で処理するときは次のようにやります。（これが当たり前だと思うのですが） HR NO テストid 教科code 点数というフィールドリストに縦に長いデータを入力していきます。クロス集計クエリで必要な部分を表形式で取り出して処理するのが日常の業務なのです。桐ではこのような処理はできないのでしょうか？「Access」を使ってきた私にとってテーブルとはデータを蓄積する部分でありそれをどう入力・加工するかは「クエリ」・「フォーム」だったわけです。「桐」の場合、（私の周囲に限っての話ですが）ほとんどの作業を「テーブル」でおこなっているようです。実際のところはどうなのでしょう？　「桐」の印刷機能の素晴らしさは目を見張るものがありますね。上記のような点がクリアできるなら十分採用の余地があるのですが・・・皆様のアドバイスを期待しています。
18990	Re:「桐」を採用するか「Access」か？	うにん	2003/02/16-14:49
記事番号18987へのコメント >私が一番「桐」を採用するのに躊躇することは桐にクエリがない（？）こと >なのです。結合表がクエリ相当だと思います。 >具体的にいいますと、「桐」を使っている知人のテーブルは >まるで表計算ソフトの表の感覚で > >HR NO 氏名国語数学生物物理・・・ > >という項目がフィールドに設定してあって，それに点を入れて・・・ >という処理をしているのです。入力が楽だからじゃないでしょうか。下の形式の表だと、テストidとか教科codeを毎行入力しないといけないので。 >「ACCESS」で処理するときは次のようにやります。（これが当たり前だと >思うのですが） > >HR NO テストid 教科code 点数 > >というフィールドリストに縦に長いデータを入力していきます。 >クロス集計クエリで必要な部分を表形式で取り出して処理するのが >日常の業務なのです。 >桐ではこのような処理はできないのでしょうか？転置集計（＝クロス集計）があるので簡単にできます。 >「桐」の場合、（私の周囲に限っての話ですが）ほとんどの作業を「テーブ >ル」 >でおこなっているようです。テーブルと会話処理でかなりのことができてしまうので、そうなるんでしょうねえ。
18992	「桐」と「Access」	mudagami	2003/02/16-14:56
記事番号18987へのコメント　仕事の内容が違いますのであまり参考になるかどうか分かりませんが、桐をメインに使っていて、その他をやむおえなくAccessを使っています。　どうしても、桐で実現できない機能は、少し前の書き込みにも質問されていましたが、キー送信(他のアプリケーションにキー操作を送り動かす機能)とユーザー関数の作成だと思います。 (ユーザー関数の作成などはどうしても桐に追加して欲しい機能です) 　ご質問の「クロス集計クエリ」などは、桐では「転置集計」で実現可能かと思います。 Accessの「クロス集計」を見たとき、Accessでも出来るのか!!、桐の機能のまねか!? と逆に疑ったくらいです。　Accessのデータ処理法がデータベースの本道で、桐の処理方法が特殊なのでしょうが、今では桐の操作が身に染みついてしまい Accessの方が特異に見えてしまいます。　Accessの悪口になってしまいますが、一番困るのは、安定性がないこと、バグが多いことです。重要な業務処理にはとても怖くて使えません。単純な処理をさせている分にはあまり問題はありませんが。 (Accessのフアンの方にはごめんなさい!!) 以上参考になりますか…
18995	Re:「桐」と「Access」	daipon	2003/02/16-17:20
記事番号18992へのコメントうにんさん、mudagamiさん、素早いresありがとうございます。なんとなくわかってきました。「桐」の柔軟な操作性のため逆に簡易表計算のような使い方も出てくるということなんですね。（どなたかが「便利ゆえにそれが仇にもなる」と仰っていたのはこんないみだったのかも知れませんね！）クロス集計もできるということで、私が今までやってきた仕事内容も十分にカバーできそうです。かなり「桐」に期待できそうな気持ちになってきました。さっそく製品版を購入して試運転してみようと思います。またわからないことがあったら教えてください。
18997	Re:「桐」を採用するか「Access」か？	KH	2003/02/16-20:43
記事番号18987へのコメント daiponさん、こんばんは。検討の方向性がお決まりのようなので別にどうでも良い事なのですが・・・。ここで、「桐を使わない方が良い」という方も殆んどいないと思いますし、また「桐しか知らない」という方も多いと思います。私も、Accessの所有者ですが「桐しか知らない」人間です。で、お聞きしたいのは、Accsessで作られていて、今、何故「桐」を検討の対象に入れたのか、たとえば、Excelで作られていてデータの蓄積の問題があって、 Accessと桐の検討ならならわかりますが・・・。 Accessでの手直しで済むものをわざわざAccessから桐への移行というのはとても興味があります。もし宜しければ、差し支えない範囲でその理由を教えていただければと思います。つまり、Accessでの作成でネックになっているところがあるのかどうかをお聞きしたかった訳です。済みません、ごちゃごちゃと屁理屈ばかり書いて。
19003	Re:「桐」を採用するか「Access」か？	daipon	2003/02/17-09:54
記事番号18997へのコメント KHさん，こんにちは。現在，Accessを利用していますが、問題点としては１．Accessは１つのテーブル，クエリで許されるフィールド数が250に限定される。　（生徒データの場合、この数はかなり厳しい数字）２．Excelのような豊富な関数がない（たとえば順位付けでも苦労する）３．印刷機能が少し貧弱か？あたりです。しかし利点として１．クエリの多機能性でデータが扱いやすい（テーブルを直接触らせる必要がないためデータ保全の点で有利）２．当然のことながらExcelとの親和性が高い３．VBAがあればなんでもできちゃうなどです。それに「桐」ファンの職員も多く、リクエストがあることなども検討の動機となっています。ところで、前回クロス集計クエリは「桐」にもあると返答を頂いたのですが、「クエリ」（結合表というのでしたね）の機能はかなり貧弱だとの意見も聞いたことがあります。ちょっと心配。それに，なんでもかんでもテーブルでやる知人のやり方には今ひとつ怖さを感じます。「桐」を使うことで，すべての業務がテーブルとにらめっこするような形になり, その結果としてデータが「表計算ソフト」のような構造になっていくのでは導入の意味はありません。 Excelで十分です。私が「桐」に期待するのは「データベース」としての信頼性・操作性です。昔から「桐」の帳票機能には感心しています。これと「データベース」としての機能が両立しているなら，まさに最強ですが・・・もうひとつの不安は「Ver9」は「Ver8」と互換性がないとか・・・そういえばWindows版の「桐」が登場したときも同じようなことが・・・下位互換性が保障されないことは業務には影響しませんか？「桐」を考えるときに不安要素の一つであることは事実です。
19004	下位互換性	maruhashi	2003/02/17-10:34
記事番号19003へのコメント >もうひとつの不安は「Ver9」は「Ver8」と互換性がないとか・・・ >そういえばWindows版の「桐」が登場したときも同じようなことが・・・ >下位互換性が保障されないことは業務には影響しませんか？ >「桐」を考えるときに不安要素の一つであることは事実です。 Accessも、下位互換性はなかったはず。 Access97のデータファイルは、Access95では操作できなかった。これは、ワープロや表計算よりもセキュリティが重視されるデータベースソフトでは、当然のことと思ってましたが。私は化学系で、ChemFinderという化学用のデータベースソフトも扱っていますが、これも下位互換性はありません。
19006	Re:下位互換性	yasuukis	2003/02/17-13:56
記事番号19004へのコメント上記バージョンの方が機能が高いわけですから、厳密には下位互換性はないわけですが、 ACCESS2000は、ACCESS97に変換するツールが内蔵されている、という意味で、配慮がされています。ちょうどEXCEL2000の保存形式にEXCELの古いバージョンがあるような感じです。
19007	Re:「桐」を採用するか「Access」か？	yasuukis	2003/02/17-14:14
記事番号19003へのコメントクロス集計クエリーについては、桐は、クエリー（結合表）ではなく、転置集計というコマンドにより実行します。桐を使用するときにテーブルが目につくことですが、（１）ACCESSでフォームを使用するにしても、　　　通常のユーザーは、テーブルに連結したフォームで　　　入力をしているはずです。従って、データの保全制という意味では、　　　同じではないかと思います。　　　非連結フォームでデータを入力し、それをテーブルに書き込むという　　　処理をイベントなどで組んでいるユーザーは、上級ユーザーのみでしょう。（２）ACCESSは入力制限や選択候補などをフォームで設定することが　　　多いですが、桐ではテーブルで設定します。　　　この方が、よりプライマリなレベルでデータの整合性を確保できます。（３）EXCELと桐の最大の違いは、やはりデータベースですから、　　　項目ごとに数値なのか、文字なのか、日付なのかという属性があり、　　　その属性以外のデータは入れることができません。　　　データを整然と保持するという意味では、桐もやはりデータベースなのです。（４）世の中で一番なじみの深いユーザーインターフェイスは、　　　EXCELでしょう。表形式でデータを入出力することは、データの前後関係をみて、　　　間違いデータの入力を減らすなどの優れた特徴もあります。　　　表形式のインターフェイスで多くの処理がこなせる　　　桐は、ユーザーインターフェイスに優れるという考えを　　　多くの桐ユーザーはしています。（５）データの保全制という意味で、桐が優れているのは、　　　削除したデータであっても、表整理（ACCESSでは最適化）をしない限り、　　　復活することができます。　　　先日も、おじいさんユーザーが全件削除して青くなっていたのですが、　　　問題なく、復活することができました。　　　あとは、完全可変長のデータベースですから、文字項目の時に、　　　桁数を気にすることなく、データベースの定義ができます。　　　（ACCESSでは初期値は50桁ですよね。みんなそのまま設定して　　　　しまうことが多いようですが）　　　小数点以下も含めた１０進演算をサポートしており、　　　演算誤差がほとんどでません。　　　細かいことでは、スペースを表示できるので、ユーティリティー的に　　　使用するときに重宝しています。　　　ACCESSの特徴がクエリーであるように、桐のもっとも特徴的な機能は併合です。　　　バッチ的な処理ですが、いろいろ便利です。
19014	Re:「桐」を採用するか「Access」か？	KH	2003/02/17-21:12
記事番号19003へのコメント daiponさん、こんばんわ。リプライ有難うございます。 >私が「桐」に期待するのは「データベース」としての信頼性・操作性です。 >昔から「桐」の帳票機能には感心しています。これと「データベース」 >としての機能が両立しているなら，まさに最強ですが・・・　アクセスの利点については、１のニュアンスはちょっと桐とは比較し難いような気がしますが、２はＶ９でエクセルを直接操作できるようになったし、３は一括処理とイベントでＶＢＡ程強力ではないかもしれませんが桐内に限れば何でも出来てしまいます。桐はほぼ最強ではないかと思っています。ただ、桐がユニコードに対応していないため非常に困ることがあります。人名などでユニコードを利用した字が出てくるとお手上げです。市販の人名外字で対応していますが、外字だと汎用性が失われるため使用していて大きなネックと感じる部分です。
19028	Re:「桐」を採用するか「Access」か？	daipon	2003/02/19-09:56
記事番号18997へのコメント皆さんの貴重な意見をお伺いしてかなり「桐」が有力な候補になったような気がします。残った問題はExcelとの親和性です。当方の処理としてはExcelで作られたデータを読み込むことも多く，しかもそれをVBAで実現させています。というかVBAでオートメーション化しておかなければ作業に支障がでてくるのです。そこで質問なのですが，桐の一括処理でExcelのファイルを読み取り，桐の既存のテーブルにデータを読み込むことが可能でしょうか？これもできるよ！　ということであればいよいよ「桐」かな？よろしくお願いします！
19032	Re:「桐」を採用するか「Access」か？	KH	2003/02/19-11:56
記事番号19028へのコメント >桐の一括処理でExcelのファイルを読み取り，桐の既存のテーブルに >データを読み込むことが可能でしょうか？ >これもできるよ！　ということであればいよいよ「桐」かな？間違いなく一括処理で出来ます。具体的な内容は今分りかねますが、通常は、いったん作業表のような雛形の表を作り、エクセルから直接読み込みます。その後、その作業表から既存の表に必要なデータのみ併合するということになると思います。
19051	Re:「桐」を採用するか「Access」か？	yasuyukis	2003/02/20-20:57
記事番号19028へのコメント簡単に記述すると、次のようなプログラムを、一括処理、または、イベントで組むようになると思います。エクセル　 "data.xls"，"sheet1"，項目名行 = する，\ 表名 ="data.tbl",上書き =する表　"master.tbl" 読み込み　表，"data.tbl"，編集表 =しない，\ { <現在表項目名> <読み込み項目名>，…}
19052	Re:「桐」を採用するか「Access」か？	yasuyukis	2003/02/20-21:06
記事番号19028へのコメント最初から申し上げれば良かったかもしれませんが、下記のＨＰに「桐９」の９０日間お試し版が機能制限なしであります。これで試されたらいかがでしょう。 http://www.vector.co.jp/soft/maker/k3/se272639.html
19057	Re:「桐」を採用するか「Access」か？	daipon	2003/02/21-12:14
記事番号19052へのコメント yasuyukisさん，丁寧なresありがとうございました。 >下記のＨＰに「桐９」の９０日間お試し版が >機能制限なしであります。 >これで試されたらいかがでしょう。９０日間制限なしで？そ，それはすごいですね。しかしもう製品版を注文してしまいました。今日明日中には入荷すると思います。こんなことを書くとおしかりをいただくかもしれませんが，「どこのショップに行っても桐が置いていない！」「店員に聞いても桐の存在すら知らない店員が多い！」東京のような都会ならどこにでもおいてあるのかな？私は地方に住んでいるので本当に困ります。それにしても，桐を取り巻く環境は厳しいものが在りそうですね。このHPを利用されている人たちの気持ちが少しわかったような・・・こんな素晴らしいソフトが国産で存在することをもっと多くの人に知ってもらいたいですね。
19064	Re:「桐」を採用するか「Access」か？	yasuyukis	2003/02/21-19:49
記事番号19057へのコメントどうもです。東京にも「桐」はどこにもおいていません。もっとも私は、インターネットでソフトは発注していますが。デスクトップデータベース自体が、今や旬のソフトではありませんし、私の知っている限り、過去１年間にバージョンアップしたデスクトップデータベースは、桐、ACCESS、ファイルメーカーの３本くらいではないでしょうか。おそらく一番元気なのは、ファイルメーカーだと思います。 DBPROも最近はほとんど聞かないし、MRDBも細々という感じですし、 PARADOXにいたっては、どこに行ったのやら。
19298	Re:「桐」を採用するか「Access」か？	いなずま	2003/03/11-05:00
記事番号19064へのコメントこのスレッドは、自分の中で久々に心地よい内容だったのでつい書き込みしてしまいました。（やや古を掘り起こしてすみません）桐かACCESSか…。10年来と言えなくもないテーマですよね。当然、僕はここを読みに来ているだけに「桐派」なのですが、僕の場合は「文字列のDB処理が多い」「情報を見ながら“選択”“整列”“再計算”して実情を把握する」といった、プチマーケティング分析的な業務が多いので、どうしても「対話形式」で「視覚的」に判断できる桐に軍配が上がってしまいます。 ※EXCELでもいいのですが、６万行制限がネックになるもので… 既出の「成績処理」は、ある意味では「定常業務」での分析が主でしょうから、確かにACCESSを使うほうが、一般的なような気もします。なぜ「一般的」かというと、「多くの人がすごく基本的な部分の操作を知っている」「Officeに入っているのですでに持っている」「VBAなどできっちり作り上げればパッケージソフト的な使い方ができる」などだと思っています。とくに最後の「パッケージ～」的なものを作る開発者の多くがACCESSを選ぶために、世の中の主流になったような気もします。（別に桐で成績処理をすることを否定しているわけではありません）対して桐は小規模なDBや（大規模でもOKではありますが）、絶えず作っては改良、作っては改良のような個人ベースでの利用に向いていると思います。組織的な利用で考えると「ネットワーク対応の不慣れさ」（だいぶ克服されましたが）「外部データベースへのアクセス」（これもだいぶ克服）など、１情報を複数PCで共有する業務では規模によりますが ACCESSのほうが（＋結局はオラクル？）使い勝手が良くなってしまうのではないでしょうか。要は組織的利用が中心のACCESSと、個人活用が中心の桐、という感じでしょうか。「活用」でなく「利用」と書いたのは、ACCESSを利用している多くの人が「結局はEXCELでも実現できるような簡易で小規模なDB」を ACCESSにやらせているだけで、RDB（この場合は複数ファイルの結合など有機的な連動）として使っていなさそうな気がします。まぁ、今後ますます、開発規模や利用者規模での差が大きくなりそうな桐とACCESSですから、桐がマイナーであるのは市場面からみてもやむをえないとは思います。ただ、僕は桐と心中する覚悟です。数値が主流で統計的な業務が中心であればACCESSですが、文字列をみた判断や、そもそも文字を蓄積する業務であれば桐の関数群はかなり柔軟にいろいろなことが出来ます。そして、文字列主体のDBは出力にも細かい対応が必要ですので、より桐に軍配があがるような気がします。桐の本質は、「対話処理の手軽さ」と「日本語処理・蓄積能力の高さ」だと思います。僕の場合、CTRL+Xに「絞込みの同一値」、CTRL+Dに「補集合」をショートカット登録しています。これと初期設定のCTRL+Z「１作業戻る」を組みあわせると、「抽出」「（視覚的）分析」の繰り返し業務などではかなり重宝します。この国産ソフトが、もっと市民権を得るといいんですけどね。ところで、このスレのオーサーは、その後、桐９を使ってどんなあんばいなのでしょうか。かなり興味があります。

戻る