10/08/28 16:39:54
1からか？1から説明しないとだめか？
>>723
撤回するのは>720の第3パラグラフのみ（>719による元問題の解釈に同意した点）
>>724
配列であっても、配列の個数と長さの両方が変わり得るのであれば同じ話（動的集合の動的集合）
RDBへの格納を考えることはできるが、そうするとRDBの検索の理屈にはなじまず検索効率が悪い（SELECT n回等を要する）
なお、可変長型というのはあるっていやーあるが、そうした可変長データを利用したところで、
内部の部分検索については線形探索、高速化手段としてはせいぜい前回検索結果をキャッシュしておくぐらいしか
RDBから見て打つ手がないからパフォーマンスの解決にならないことを>717=719には念のため言っておく
>>725
レコードサイズを超える格納は、特定の型を使えば可能だがパフォーマンスへの影響がある
レコードサイズ上限8192バイトというのは、これはSQL Server内部のBuffer Cacheのサイズから来る
パフォーマンス上本質的な上限なわけだが（2008でもこの点は変わらない）
URLﾘﾝｸ(www.atmarkit.co.jp)
>AND条件をいろいろ書いてqueryかけた場合のパフォーマンスは恐ろしく悪いぞ。(>726)
総レコード数Nとして、
インデックスを張らずにn列のANDをとれば、SELECTの時間計算量は 線形探索*n回=O(N*n)
インデックスを張れば、O((N*log(N))*n)ぐらいが期待できる
n列の条件演算でn倍という部分自体にはキャッシングぐらいしか向上の余地がない
オンメモリにすれば高速化し得るというのは、上記インデクシングのメカニズムまで自前で実装すればの話
ところでRDBも検索性能命であるからして検索処理をオンメモリで実行しているのを>717=719はご存じだろうか？
(上記URLから辿れ)
>>727
RDBがやるんだヨ