| 過去の桐井戸端ＢＢＳ （桐ver.５） |
| 3614 | 桐５で何件位のデータが管理出来るのでしょうか | 桐野港 | 1999/12/4-23:55 |
|
桐５で販売管理をしておりますが、データの件数が約２万件 ファイルの大きさが、索引を多用してますので約２５Ｍバイトの ＴＢＬがあります。これからも少しずつ増えていきます。 索引なしでは約５Ｍバイト位になります。 ところで、どれくらいの量まで実用上使用出来るのか心配しております。 どなたか、御存知の方、もっと大量のデータを管理しておられる方 参考までに教えて頂けませんでしょうか。 | |||
| 3619 | 桐で扱えるデータ量 | 佐田 守弘 | 1999/12/5-22:58 |
| 記事番号3614へのコメント 桐野港さん 桐が扱えるデータの最大量は、仕様上では、510MBです。レコード数はレコー ド長によって変わりますが、最大で約４千万レコードです。この仕様は桐 ver.4以降変わっていないと思います。 私が実際に扱った例としては、郵便番号データが一番大きい様で、13万8千レ コード、13.3MBのサイズです。 このサイズの表を郵便番号による表引き入力に使っていますが、郵便番号から ほぼ瞬時に都道府県名や町域名が表引きされますから、速度的には全く問題を 感じておりません。 ただし、この郵便番号データは、郵政省が公開している印刷イメージのcsvフ ァイルから変換して作成しているのですが、文字の切り分けなどの文字列処理 にはやはり数分程度の処理時間が掛っています。 以前、桐が本領を発揮するのは、数万件以上のデータになった時だと言う話を 聞いた事があります。おそらく数千件であればExcelで処理した方が便利なの でしょう。 データ量が増えれば、重くなって処理が遅くなることは考えられます。この場 合、処理速度に影響するのは、レコード数が影響するか、ファイルサイズが影 響するかは、処理する内容によって変わると思います。 目的レコードを検索するといった処理では、レコード数が影響するのではない かと思います。しかし、検索速度は正しい索引を作ることによって劇的に速く なりますから、検索速度はあまり気にしなくてよいのではないかと考えます。 一方、データ値を処理する様な内容では、レコード数と共にファイルサイズの 大きさも影響すると思います。この場合、桐の処理速度以上にディスクのアク セス速度も影響するのではないかと思います。 また、売上データの様な場合、年度ごとあるいは期ごとにファイルを分けてお くのも１つの方法でしょう。これはファイルサイズを大きくしないというより も、年度、期ごとに過去のデータは手を付けずに残しておくといった意味があ ると考えます。 佐田守弘(KS-00119) | |||
| 3620 | Re:桐５で何件位のデータが管理出来るのでしょうか | 久保 | 1999/12/5-23:03 |
| 記事番号3614へのコメント こんばんは 私が以前使っていた表ファイルは確か、50項目、3万行だったとおもいます。 大きさの程は忘れましたが、併合などの作業に十分たえていました。 Ver5でした。 | |||
| 3625 | Re:桐５で何件位のデータが管理出来るのでしょうか | MIT | 1999/12/6-00:37 |
| 記事番号3614へのコメント MITと申します。 参考ですが現在も稼動中の桐Ｖ５によるシステムで 件数：約２０万件 容量：約５０ＭＢ（索引無しで約２３ＭＢ） というものがあります。 これを ＣＰＵ：４８６ＤＸ４ メモリー：５ＭＢ と言う今では骨董的な機器でスタンドアロンによる 運用をしていますが、適切な索引による検索などは 全くストレスを感じません。 ただしこのようなファイルサイズの大きい表で画面伝票 などを使うと帳票が開くまでに時間がかかります。 また、索引に自動保守を設定していると編集時に自動保守が 発生した時やはり時間がかかります。 私は巨大ファイルを画面伝票で扱うときに一括処理により 別途作業表などに書き出したデータを編集して、元表に戻す 時にストレスを感じないような処理の流れなど工夫して対処 しています。 もっとも、サイズが大きいデータを失った時のダメージを考える と佐田先生が述べられているように即時性の有無などで表を分割 することは大切な事です。 余談ですが、阪神大震災の経験で私はバックアップデータを必ず 複数ヶ所に持ち、また無用な２４時間稼動は止めるようにしています。 以上ご参考までMIT | |||
| 3642 | 参考資料ありがとうございました | 桐野港 | 1999/12/6-22:59 |
| 記事番号3614へのコメント 佐田先生、久保様、MIT様 みなさん参考になる資料 ありがとうございました。 桐Ｖ５でのデータ件数は、２万件程度では少ない方で、まだまだ十二分に 余裕のあることがわかりました。これからも安心して使用したいと思います。 また桐Ｖ５で組んだ販売管理を桐Ｖ８に移行すべき検討しておりますが、 伝票入力画面で、行訂正 帳票コマンドを多用して各項目の入力データの 制御を一括処理で行いまた方向キーで伝票画面上を自由に移動できる様に しておりました。また商品コードの特定と、過去の取引例を参照入力出来る様に 処理行指定コマンドを多用していました。 ところが、桐Ｖ８ではコマンドの変更から、桐Ｖ５と同じ一括処理では動かない ことがわかりました。イベント処理では、処理行指定コマンドも使えない様です。 伝票入力画面の部分だけは、一括処理の全面的な書き換えが必要となりました。 なかなか良い方法がみつからないで悩んでいます。 そこで佐田先生が取り組んでおられる桐Ｖ８の教則本の内容に、桐Ｖ８の特徴を 生かした販売管理の雛型をぜひ取り入れて頂きたいと思います。 教則本の発刊期待しております。 | |||