桐質問掲示板 [One Topic All View / Re[4]: 索引定義と並べ替え条件登録 / Page: 0]

(現在過去ログ60 を表示中)

[ 最新記事及び返信フォームをトピックトップへ ]

■9303 / inTopicNo.1)

　索引定義と並べ替え条件登録

□投稿者/ たゆー -(2015/09/01(Tue) 14:10:43)

・並べ替え条件登録・・・その名の通り「並べ替え条件登録」
・では索引登録は・・・・索引を登録する・・・のでしょうが

索引定義のヘルプの索引定義には、
■記述例として
・[氏名のよみ] 順の索引を定義します。・・・・「仮にA」
　索引定義　索引名 = "よみ順"，{ [氏名のよみ]辞書順 }
・索引を定義すると同時に、並べ替え条件も登録します。・・「仮にB」
　索引定義　索引名 = "よみ順"，条件登録 = "よみ

そこで疑問ですが、「索引定義」はいったいなにをしてるのでしょう
「仮にB」とすれば、並べ替え条件登録で済むし
「仮にA」で登録しフォームの表の開始順で「開始条件種別1」と「条件名1」を
設定しても実行されてないようですがこの２つの違いはなんでしょうね
みなさんはどのように使い分けをされてますか？

引用返信 [メール受信/OFF] 削除キー/

■9304 / inTopicNo.2)

　Re[1]: 索引定義と並べ替え条件登録

▲▼■

□投稿者/ ONnoji -(2015/09/01(Tue) 14:24:56)

> そこで疑問ですが、「索引定義」はいったいなにをしてるのでしょう
> 「仮にB」とすれば、並べ替え条件登録で済むし
> 「仮にA」で登録しフォームの表の開始順で「開始条件種別1」と「条件名1」を

ＤＯＳ桐の時と同じで、索引をうまく使うと［併合］や［検索］が速くなることがありますよ。

とはいっても、Windowsでは表のデータがオンメモリに近い状態になるでしょうから、

ＤＯＳ桐の時のように劇的に実感できるか微妙ですが。

引用返信 [メール受信/OFF] 削除キー/

■9305 / inTopicNo.3)

　Re[2]: 索引定義と並べ替え条件登録

▲▼■

□投稿者/ ONnoji -(2015/09/01(Tue) 14:32:58)

2015/09/01(Tue) 15:04:21 編集(投稿者)

> ＤＯＳ桐の時と同じで、索引をうまく使うと［併合］や［検索］が速くなることがありますよ。
> とはいっても、Windowsでは表のデータがオンメモリに近い状態になるでしょうから、
> ＤＯＳ桐の時のように劇的に実感できるか微妙ですが。

そうそう、表定義の［表引き］で、［表引き対象の表に重複禁止の索引があった場合云々］なんていうのもありましたね。

これも、ＤＯＳ桐と同じですね。

350×498 => 176×250

1441087500.jpg/46KB

引用返信 [メール受信/OFF] 削除キー/

■9306 / inTopicNo.4)

　Re[3]: 索引定義と並べ替え条件登録

▲▼■

□投稿者/ たゆー -(2015/09/01(Tue) 16:55:26)

画像添付ありがとうございました。この件は過去にも試したことがありました
> 表引き時に使用する索引を桐に任せる場合はON、任せない場合はOFFにします。
> この属性は、[使用索引]が指定されていないときに有効です。
複数登録した場合どの索引を利用するのでしょうね

ところで、桐ヘルプを「索引」で検索すると
・索引条件
・索引条件数
・索引条件名
・索引状態
記載してあるが、「条件数・件名」を調べる方法は記載してあるが
具体的な利用方は見つけられませんでした

コマンド　◯◯◯◯,利用検索名="コード順",[あああ],[いいい],[ううう]
きっと、このような使い方があると思うのですが・・・残念

引用返信 [メール受信/OFF] 削除キー/

■9307 / inTopicNo.5)

　Re[4]: 索引定義と並べ替え条件登録

▲▼■

□投稿者/ ONnoji -(2015/09/01(Tue) 17:08:05)

> 複数登録した場合どの索引を利用するのでしょうね

タラレバですが、

おそらく第一番めの整列項目を調べて適合するものを使うんでしょうね。

同じような索引がある場合、登録順に索引を調べるのか、登録逆順に索引を調べるのかわかりませんが･･･

もしも、使える索引がなければ、索引を利用しないと思いますよ。

引用返信 [メール受信/OFF] 削除キー/

■9308 / inTopicNo.6)

　Re[1]: 索引定義と並べ替え条件登録

▲▼■

□投稿者/ 通りすがり -(2015/09/01(Tue) 18:46:04)

> そこで疑問ですが、「索引定義」はいったいなにをしてるのでしょう

表の中に、索引を作ってる
たぶん、実数型の隠し項目

引用返信 [メール受信/OFF] 削除キー/

■9309 / inTopicNo.7)

　Re[1]: 索引定義と並べ替え条件登録

▲▼■

□投稿者/ hidetake -(2015/09/01(Tue) 20:28:00)

索引は、データを登録したときに、表の中に索引を作る。
並べ替えは、並べ替えを実行する際に、データを見ながら
並べ替えを実行する。

だから、専有で開いていれば、索引を利用した方が圧倒的
に速い。
並べ替えに、索引を指定すれば、索引を使用した並べ替え
がを使用するので速い。但し、専有で開くときのみ。

共有では、索引は使用されないので、並べ替えを行うとき
は、索引があり専有で開くときよりも、圧倒的に遅い。

検索の際も、索引があれば(検索項目で先頭一致の場合
のみ)、索引を利用し検索できるので速い。無ければ、
その都度、データを見ながら検索するので遅い。

で、
共有がメインで使用する場合は、索引を作ると、表の
データは巨大化し、でも共有では索引は使われない
(使うことができない)ので、かえって、索引を作らない
方がデータがコンパクトになり、データを読み込む
作業が減るので、かえってよいのかな？なんて、最近は
思う次第。

それと、桐は、表の定義のところで、「索引」と
「主キー」が設定できるのですが、索引項目が１項目の
場合、主キーとダブってしまえば、同じ索引で主キー
とかぶってしまい、無駄な索引データができて、表に
無駄なダブった領域を作ってしまうのかな？なんて
思う次第。

# 主キー&索引の項目が、カウンタ型の場合だけは
# 索引というかインデクスは共用され１つになる
# かも知れないけど、そうでない場合は、それぞれ
# 索引が作られるのだったかな。

引用返信 [メール受信/OFF] 削除キー/

■9310 / inTopicNo.8)

　Re[2]: 索引定義と並べ替え条件登録

▲▼■

□投稿者/ たゆー -(2015/09/01(Tue) 21:50:36)

> 表の中に、索引を作ってる
> たぶん、実数型の隠し項目
無関係かもしれないけど、前から気になってた
「表整理　余白割合 = 0｜10｜20｜30｜40｜50」
どこで、どのような処理をしているのかはわかりませんが
こんなところにも関係あったのかもと思いました

引用返信 [メール受信/OFF] 削除キー/

■9311 / inTopicNo.9)

　Re[2]: 索引定義と並べ替え条件登録

▲▼■

□投稿者/ たゆー -(2015/09/01(Tue) 21:51:14)

>索引は、データを登録したときに、表の中に索引を作る。
>並べ替えは、並べ替えを実行する際に、データを見ながら
>並べ替えを実行する。
これは驚きです。知りませんでした。

>だから、専有で開いていれば、索引を利用した方が圧倒的
>に速い。
>並べ替えに、索引を指定すれば、索引を使用した並べ替え
>がを使用するので速い。但し、専有で開くときのみ。
また、「専有・共有」での処理差異も、たまにしか利用しないので
気づきませんでした

実は、索引と「主キー」との関係(利用方法)も、全部は把握していません
まだまだ、いろいろ試行錯誤が必要ですね。

ただ、
>とかぶってしまい、無駄な索引データができて、表に
>無駄なダブった領域を作ってしまうのかな？なんて
これだけは避けたいと思います

引用返信 [メール受信/OFF] 削除キー/

■9312 / inTopicNo.10)

　Re[2]: 索引定義と並べ替え条件登録

▲▼■

□投稿者/ まさやん -(2015/09/02(Wed) 08:23:26)

■No9309に返信(hidetakeさんの記事)
> 索引は、データを登録したときに、表の中に索引を作る。
> 並べ替えは、並べ替えを実行する際に、データを見ながら
> 並べ替えを実行する。
>
> だから、専有で開いていれば、索引を利用した方が圧倒的
> に速い。
> 並べ替えに、索引を指定すれば、索引を使用した並べ替え
> がを使用するので速い。但し、専有で開くときのみ。
>

因みに　

ウィキペデイア　で索引(データベース)みてみたら

全体をメモリ上に保持しきれないほど大きな表であっても、その索引であればメモリに保持できる可能性がある。　　　とありました。

並べ替えとの違いも　この辺のが関係しているのでしょうね。
私も参考になりました。

引用返信 [メール受信/OFF] 削除キー/

■9313 / inTopicNo.11)

　Re[3]: 索引定義と並べ替え条件登録

▲▼■

□投稿者/ hidetake -(2015/09/02(Wed) 11:21:02)

2015/09/02(Wed) 11:32:10 編集(投稿者)

> 全体をメモリ上に保持しきれないほど大きな表であっても、その索引であればメモリに保持できる可能性がある。　　　とありました。


長整数の 0 から 99,999,999 までの、最大 8桁の
整数の入った項目と、その値のチェックデジットを
計算した結果が入った 1桁の整数の入った2つの
項目を持つ、計算式も何もない整数値２つだけを
持つテーブルで  ※即ち 100,000,000件のテーブル

索引も主キーも設定もなく表整理で 0% を指定した
                  表のサイズが 2,153,248KB
(CSVファイルだと 1,161,025KB のデータ)

それに、索引を作り表整理 0% で 4,308,128KB

それにさらに主キーを設定すると 6,702,752KB

数値項目の索引でも、結構なサイズとなります。

で、このぐらいのサイズの表になると、並べ替えで
索引有りだと一瞬ですが、索引が無いと何(十)分も
待たされます。
もちろん、索引を利用できるのは専有で絞り込み
など無い状態のみです。

そして、このサイズの表を扱うとき、メインメモリ
8GB あっても、桐は通常状態で 100MB で並べ替え
を行っている最中で、多くて 200 ～ 300MB しか
使ってくれないようです。

それと、桐10で不思議な現象に出会いました。
並べ替えをやっている最中にメモリを 300MB 使って
30% まで進んだところで、急にメモリ使用量が
がくんと減り、また並べ替えを 0% から再実行する
場面がありました。初めての減少ですが何度か
確認しました。


あと、検索でも索引状態であれば、例えば 9999999
を検索する場合でも一瞬ですが、索引が無い状態
だと、このぐらいのサイズになると相当待たされ
ます。

引用返信 [メール受信/OFF] 削除キー/

■9314 / inTopicNo.12)

　Re[4]: 索引定義と並べ替え条件登録

▲▼■

□投稿者/ hidetake -(2015/09/02(Wed) 12:48:16)

あと、主キーに関しては、あまり詳しく解説したところが
無いと思いますので詳しいことはわかりませんが、主には
参照整合性で使うと思います。

参照整合性は、昔試したことがありますが、何か使い
づらかったのでそのまま使っていません。

それから、主キーとキーワードで言えば、SQL とか、
外部DB に関わってきそうに思いますが、主キーがあれば
桐は、外部DB にテーブルを書き出す際に、外部DB側に
プライマリキー(主キー)も併せて書き出す場合があります。
この辺も桐は曖昧で、咲き出す際の桐の表の状態により
変化します。

まぁ～、そんなこんななのですが、通常はあまり気にしな
いし使わないでよいと思います。
参照整合性を積極的に使う場合は別ですが…

それと、主キーを設定すると、表自分自身だけでなく、
桐は同じフォルダ内にある REF_DEF10.TBX / REF_DEF9.TBL
に情報を設定しますので、表の移動やリネームの際には
十分な注意が必要です。

引用返信 [メール受信/OFF] 削除キー/

トピック内ページ移動 / << 0 >>

このトピックに書きこむ

過去ログには書き込み不可

HOME HELP 新規作成新着記事トピック表示ファイル一覧検索過去ログ

- Child Tree -
- Antispam Version -