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

12400	データベース桐でどのくらいのデータ量まで管理できるんでしょう？	北 加寿紀	2001/07/21-19:17
みなさん、毎度お世話になります。 かなり、しょーもない質問だとは思うんですけど、ちょっと書き込んでみました。 私は、今、自動車部品の部品性能評価をしており、桐はその製品のデータの集計などに使っております。 ほぼ毎日データ収集があるので、まあ、一日２件程度増えていくことになります。 先輩が桐を導入して以降、仕様の表が２０００件程度、それに付随するデータ表が１２０００件程度、３０００件程度です。 （トータルで３０Ｍバイトぐらいですかね。ちなみにこれらは、社内ネットワークにいます。） 　で、このｂｂｓを見ていて思ったのですが、 「世の桐ユーザーはどのぐらいのデータ量をあつかってんだろう」と。 　また、「どんどんデータ量が大きくなっていくことで、なんか懸念されることがあるんだろうか」。 また最近最近ちょっとずつ、イベント、一括なんかをつつき始めたのですが、 「同じアウトプットを出すのに上手な人と初級者とで、処理内容、スピード、にどのぐらいの違いがあるんだろう」など。 　社内で桐を扱っているのは自分だけですし、一括処理などについて情報交換も手近にできず、 また、社内的にはソフトの統合をする動きがあり（つまり、表計算もＤＢもＭＳの製品に統一したいんでしょうね、 金銭的にも管理的にも楽ですからね。）肩身も狭いです 　だんだんずれて来ましたが、自分勝手なかつ「そんなこと知ってどうすんの」的な質問だと思われるかもしれませんが、 どなたか上３つにどんな内容でもいいので答えていただけると、地方の一桐ユーザーには心強いです。 　みなさんよろしくお願いいたします。
12402	Re:データベースの管理について	toshi-chan	2001/07/21-23:57
記事番号12400へのコメント 北 加寿紀 さん、こんばんは。 ＞世の桐ユーザーはどのぐらいのデータ量をあつかってんだろう ひとそれぞれでしょうねえ。 桐ｖｅｒ８に付属している郵便番号簿には約１２万件のデータがありますね。 私が使っている表でデータ件数がもっとも多いのは１万件ほどです。 多くの表は１０００件にも満たないです。私がデータペースを使う目的は、おおむね (1)　大量のデータを体系的に扱う。 (2)　定型的な作業を一括処理を使って自動化する。 のいずれかです。最近は(2)の目的で桐を使用することが多いですね。 ＞上手な人と初級者とで、処理内容、スピード、にどのぐらいの違いがあるんだろう それも、それぞれでしょうねぇ。 各コマンドの特徴をきちんと理解して最適なコマンドを使えるかどうかにかかっているのでは。 一括処理は書けば書くほど、洗練されたプログラムが書けるようになるみたいです。 おもしろい例を紹介します。 桐ver７で一括処理を動かすと自動的に表ウインドウが画面表示され、 並べ替えや絞り込みなどの実行状況をリアルタイムで目にすることができます。 桐ver８では、ウインドウ作成コマンドを実行したときに表ウインドウが表示されるように仕様変更になっています。 画面表示が結構くせ者で、これによってかなりの時間がかかってしまいます。 画面表示すると２時間かかる一括処理が、画面をオフにすると２０分で終わった、なんてこともあります。 （Excelのマクロを実行するときも画面をオフにしたほうが断然速いみたいです。） 新しいテクニックを覚えたために一括処理の実行に時間がかかるようになったこともあります。 桐ver５で下記のような一括処理を書き、これはver８でも使っています。　 繰り返し　＆処理件数＝１，２０，１ 　　代入　＆項目Ａ＝＃項目属性（＆処理件数＋１２，１） 　　代入　＆項目Ｂ＝＃項目属性（＆処理件数＋１４，１） 　　編集表 "印刷用" 　　併合 "入力",両方,{[年月日]照合，[商品名・規格]照合＆項目Ａ,[数量]加算＆項目 Ｂ} 　　編集表”入力” 繰り返し終了 「＃項目属性」を知らない頃は、繰り返しループは使用せずに併合コマンドを２０行書いていました。 もちろん具体的な項目名を書きました。 この方法だと、一括処理を書き換えるのがとても大変でした。 桐ver５のリファレンスマニュアルを見ていたときに上記のテクニックを知り、書き方を変えたわけです。 しかし、代入コマンドを実行すること、編集表の切り替えを行うことなど、プロセスが長くなってしまい、 一括処理の実行に少し時間がかかるようになりました。 うまくいかないですよね。 ******************************************************************** 桐談義です。 ＞表計算もＤＢもＭＳの製品に統一したいんでしょうね、金銭的にも管理的にも楽ですか らね。肩身も狭いです 私は職場では、桐を使って「あんなこともできる、こんなこともできる」とアピールし、 桐の認知度（？）が上昇しつつあります。 肩身が広いわけではないのですが、狭くもない。 課長はAccess派なんだけど、何故か桐を買ってくれる。みんなでがんばろう。
12405	Re:データベースの管理について	みつお	2001/07/22-10:57
記事番号12400へのコメント 北 加寿紀さん、みつお　と言います >「世の桐ユーザーはどのぐらいのデータ量をあつかってんだろう」と。 >　また、「どんどんデータ量が大きくなっていくことで、なんか懸念されることが >あるんだろうか」。 要はどの位で、パンクするかの懸念だと思います 私の友人で　access　を使ってる友人が３０ＭＢ越えたら、３割くらいのダミーのデーターを追加して、 テストした方が良いですよ、でないと後で泣くことになると・・ 今はオラクルを使ってると言ってました。 私の顧問先では１５万件の顧客データ（項目数54　index2　その他の設定40..60？） 表整理１０％状態で　６７ＭＢで使用してます、３ヶ月に１回くらいの割合で読込 不能エラーが出る（ＢＡＫで対応）表修復でも直りますが、諸設定が飛んでしまいますので、 １年に２万件ほど増えますが１７万まで行き、以後古い方から削除するつもりです。 >「同じアウトプットを出すのに上手な人と初級者とで、処理内容、スピード、にど >のぐらいの違いがあるんだろう」など。 スピードに関しては「索引き並べ替え」を使えば最長0.3秒で検索、絞り込み（同社では主として電話番号）等出来問題ない他のソフトは書きません、 実験して下さい。 >　社内で桐を扱っているのは自分だけですし、一括処理などについて情報交換も手 >近にできず、また、社内的にはソフトの統合をする動きがあり（つまり、表計算も >ＤＢもＭＳの製品に統一したいんでしょうね、金銭的にも管理的にも楽ですから >ね。）肩身も狭いです 指導的立場でないと、難しいでしょうね、但し大きくなれば（データ）泣かされることになるでしょう
12406	Re:データベースの管理について	みつお	2001/07/22-12:02
記事番号12405へのコメント 解りづらいところ書き直します。 >「同じアウトプットを出すのに上手な人と初級者とで、処理内容、スピード、にど >のぐらいの違いがあるんだろう」など。 > スピードに関しては「索引き並べ替え」を使えば最長0.3秒で検索、 絞り込み（同社では主として電話番号）等出来て問題ない、他のソフトのことは書きませんが、実験して下さい。
12416	Re:データベースの管理について	島尾	2001/07/23-10:17
記事番号12400へのコメント 桐って重複禁止の索引を上手く利用するとものすごい速度でデータを扱えますよね。 安定性もかなり高いと思いますけど。
12422	Re:データベースの管理について	MIT	2001/07/23-19:21
記事番号12400へのコメント 北 加寿紀さん >世の桐ユーザーはどのぐらいのデータ量をあつかってんだろう・・ おそらくサイズの大きい表の稼動実績が気になっていらっしゃると思いますので、 私の知る大きなサイズの表をご紹介します。 データ件数：約２３万件 ファイルサイズ：約１２０ＭＢ 桐クラスのＤＢでは表のサイズとして大きいほうだと思いますが この表は現在も年間１０万件程度のペースで増えています。 このサイズでも索引による検索は高速に実行します。 ただし索引を１つ定義するごとにファイルサイズはかなり大きくなりますので 必要最低限の索引で済むような項目の設定などを工夫しています。 この表が５０万件になるまでは「桐の表」として使おうと思っています。 それ以上のサイズになったら信頼性の点で他のＤＢに移行する予定です。 >どんどんデータ量が大きくなっていくことで、なんか懸念されることが・・ データ件数の増加とデータ破損は比例関係にあると思います。 当然ながら不慮の事態に備えてバックアップや停電時の対応は不可欠です。 なお、桐では表をコピーする事によってバックアップをとる事になると思いますので サイズが大きくなるとバックアップに要する時間もかかるようになりますね。 私はバックアップを一括処理で行っていますが、バックアップ対象の表を １．表整理 ２．ファイル複写 の手順にしているのでサイズが大きいと本当に時間がかかります。 >同じアウトプットを出すのに上手な人と初級者とで、処理内容、スピード・・ 桐を使ったデータ処理でスピードに関する要素としては ・索引の有無とその使い方 ・表の構成 などが最も影響すると思います。 表の操作で絞り込みなどを実行する時に絞り込み回数が少なくて同じ結果が得られるならその方が普通は早いですね。 また、表を読み込む時に サイズが小さい表→サイズが大きい表 の方向に読み込む方が早いはずです。 高速化の手法は色々あるようですので、具体的な事例で質問されると おそらく皆様からすばらしいアイデアを提示していただけると思いますよ。 >ＤＢもＭＳの製品に統一したいんでしょうね、金銭的にも管理的にも楽ですから・・ データを直接操作する必要があったらどうでしょうか？ そんな場合はそれを管理しているＤＢの操作を習得する必要があります。 習得に要するコストが発生した時、金銭的に楽になるのはどのＤＢになるのか難しいところですね。 MIT
12431	Re:データベースの管理について	うにん	2001/07/24-16:06
記事番号12422へのコメント >私はバックアップを一括処理で行っていますが、バックアップ対象の表を >１．表整理 >２．ファイル複写 >の手順にしているのでサイズが大きいと本当に時間がかかります。 表の枠組みを１回だけバックアップしておいて、あとはテキスト書き出しにして、 リストアするときに読み込むことにすると速いんではないかな？
12433	Re:データベースの管理について	MIT	2001/07/25-10:56
記事番号12431へのコメント うにんさん >表の枠組みを１回だけバックアップしておいて、あとはテキスト書き出し >にして、リストアするときに読み込むことにすると速いんではないかな？ アドバイスありがとうございます。 表サイズが大きくなってくると、確証がある訳でもありませんが 保険をかけるつもりで毎回「表整理」しています。 バックアップを１日２回（昼休みと終業時）取っているのですが 表整理に時間を費やすため、タイミング的にこうなってしまいました。 うにんさんの手法を使えばバックアップデータの容量節約にもなりそうですね。MIT
12434	Re:データベースの管理について	悲しげ	2001/07/25-13:55
記事番号12433へのコメント どもっ、MITさん >表サイズが大きくなってくると、確証がある訳でもありませんが >保険をかけるつもりで毎回「表整理」しています。 なるほど、私も（半信半疑ながらも？）そのお考えに納得です。 確かに、容量と時間からすると、枠組み＋テキスト（k3）炊き出しが圧倒的に有利です。 が、表が一度壊れてしまったら、前回バックアップの後から入力した分は海の藻屑と化してしまいますから、 それと復旧処理にもそれなりの結構な手間がかかりますから、 その辺りのプラスマイナスからすると、「表を壊れにくくしておく」ことは大いに意義のあることでしょう。 あ、「表を壊れにくくしておく」ことのひとつとしての「表整理」についてです。 私が今扱っている最大のデータ一式は約400Mbです。 が、個々の表はあまり大きくならないように、30Mbくらいを超える前に「分割」するようにしています。 その理由は、壊れ易さ云々と云うよりも、グループ選択関係で扱う場合に、あまりに遅くなるからですが、 壊れ難さのメリットも有るのかもしれないと感じました。
12448	Re:データベースの管理について	北 加寿紀	2001/07/28-01:45
記事番号12434へのコメント toshi-chanさん、みつおさん、島尾さん、MITさん、うにんさん、悲しげさんコメント大変ありがとうございます。 また、自分から質問をしておいて、お礼が遅れたこと大変お詫びします （ほんとすいませんここのところbbsをのぞくのがせいいっぱいだったもので・・・＾＾；） 　みなさんすごういですね。 件数、大きさ共、想像以上です。 （あと、ver８に郵便番号簿（１２万件）があったとは・・・不覚にも、いまのいままで、知りませんでした） 年間の増加ペースが１〜１０万件レベルで増えていくというのも、驚きでした。 また大きくなるほどデータの維持管理に大変気を遣ってらっしゃるとひしひしと感じました。 　私めの感想です（＾＾； 　toshi-chanさん >・・・・一括処理は書けば書くほど、洗練されたプログラムが書けるようになるみたいです。・・・・ 私、正直、一括処理は同じ内容なら。行数が少ないほどいいのかなと思っていました。 私は最近始めたばかりなので、スピードを云々いえるレベルではありませんが、上手に組むには、いろんな方法で試してみることが必要なんですね。 　みつおさん >私の友人で　access　を使ってる友人が３０ＭＢ越えたら、３割くらいのダミーの >データーを追加して、テストした方が良いですよ、 ちなみにこれは長年ＤＢを管理している方には常識なのですか？私は勝手に、 自分の使っているネットワークやＰＣの限界を知るのにいい方法だな、と感心したのですが、まちがってます？ ＤＢソフトによって、データの大きさに対する信頼性は結構違うものなのですか？ 　ＭＩＴさん >私はバックアップを一括処理で行っていますが、・・・ バックアップも一括処理ですか。そんなことにも気づきませんでした・・・がっくり ＭＩＴさん、うこんさん、悲しげさんが「表整理」についてかかれてますが 「表整理」は「表の破壊防止」に有効なんですね、 私何の気なしに、気づいたときに「表整理」を実行してました。（意味もよくわからず） 　みなさん、大変気を遣ってデータの管理をされているんですね。 私はデータがみなさんに比べ小さいのでバックアップをとること自体時間がかかることも無かったのですが、 これから、データベースの対象範囲を広げていこうと思ったら、本気で考えておく必要があるようです。 今回、勉強になりました。 これからも、一つみなさんよろしくおねがいします
12450	Re:データベースの管理について	みつお	2001/07/28-06:42
記事番号12448へのコメント 北 加寿紀さんへ　　みつおです。　 >>私の友人で　access　を使ってる友人が３０ＭＢ越えたら、３割くらいのダミー >>のデーターを追加して、テストした方が良いですよ、 >ちなみにこれは長年ＤＢを管理している方には常識なのですか？ いいえ、そうじゃなくて、どの位の大きさにで実用に耐えうるかのテスト方法です たとえ動いたとしても、検索、絞り込みに５秒も掛かるようじゃ困るし、 ましてやエラーが頻繁に起こってフリーズするってことも有るらしい・・・ これはアプリケーションに対するテストと考えて下さい。 ですから書き込み諸氏のこのくらいまでは桐Ｖ８は大丈夫と思って下さい、 但しバックアップについては、常識です。 >ＤＢソフトによって、データの大きさに対する信頼性は結構違うものなのですか？ 他のソフトのいうのは、はばかられますが４０ＭＢ越えたら、実用にならないもの 多々有るようです。
12455	Re:データベースの管理について	seki	2001/07/28-20:23
記事番号12400へのコメント 北さん、はじめまして。 自動車部品の部品性能評価ですか。私も以前ある製品のパーツリストを桐V5から桐V7まで管理していたことがあります。 60万レコードほどでしたが、#表引きなどは快適に使えました。 自動車部品もそうでしょうが、親部品・子部品と言うツリー構造を持っていましたので、 併合、結合などの処理も多用しましたがさすがに重かったです。 また、適切にフォルダ分けした20万ファイルほどある部品の姿図(画像データ)も 表示、印刷していましたが、スピードには満足していました。

戻る