17/01/29 13:12:51.28 WfZCQfEI.net
一時ファイルに元のファイルの内容と挿入データを書き込む
→元のファイルを削除する
→作成した一時ファイルの名前を元のファイルの名前に書き換える
でできると思うけど自分の好きな方法でうまくいったのならいいんじゃね
994:803
17/01/29 13:29:04.76 6CKnMYhm.net
>>982
>一時ファイルに元のファイルの内容と挿入データを書き込む
確かにこのやり方がスマートでした
元のコード流用しようとしたので今のやり方になってしまいました
あらかじめわかっていたら・・・
995:デフォルトの名無しさん
17/01/29 17:25:54.20 UOF0Asn0.net
うめ
996:810
17/01/29 22:35:39.11 F8/CipCU.net
>>810です。反応が遅れてすいません。現在は、
クラスのインスタンスの複数のプロパティの値を比較して等価かどうか判定しているのですが
データをリストに追加する際、2種類の等価比較法（IEqualityComparer）を用いています
つまり追加対象のデータのうち、
まず弱い比較（少なめのプロパティだけが一致するか比較）で
既存のリストにないデータの「候補」をざっくりピックアップして、
候補たちに少々時間のかかる処理をかけてから（一部プロパティが書き換えられる）、
次に強い比較（多めのプロパティを比較）で候補の中から真に「新しい」ものをリストに追加しています
PosgresやLocalDBといったデータベースでは、こういうことって簡単にできるんでしょうか
ネット検索してみたところ複数のプロパティを比較すること自体は
UNIQUE制約（？）というので出来そうに思ったんですが、
現在やっているような2段構えの比較法は実現可能なんでしょうか？
997:デフォルトの名無しさん
17/01/29 22:51:26.56 M0HgmB1M.net
二段構えにする必要はない
比較に必要な全てのカラムセットにuniqueインデックス張りなさい
998:デフォルトの名無しさん
17/01/29 22:55:35.08 F8/CipCU.net
>>986
それだと誤判定になりませんか？
追加前のデータと実際に追加するデータでは
一部プロパティ（弱比較ではチェックしないが、強比較ではチェックするプロパティ）の値が異なっているのですが…
999:デフォルトの名無しさん
17/01/29 23:02:20.70 faIlAfcC.net
>>987
強比較の値がDB上
1000:に固定できるなら、最初から強比較でやっても十分な速度が出ます 取り出してから変化する性質なら、弱比較でDBから取り出し値を生成してからメモリー上で強比較で良いんじゃないの？
1001:デフォルトの名無しさん
17/01/29 23:27:53.21 F8/CipCU.net
>>988
すいません、「DBから取り出す」という表現が何を指しているのかよくわかりません…
いま思案しているのはデータの集計作業時ではなく登録作業時の話です
各データについて、一部のプロパティの値を確定させるには処理時間がかなり必要になっています
追加登録したいデータたちについて、このプロパティ値をあらかじめすべて確定するのは非常に時間がかかるので
まず弱比較でざっくりと追加可能な候補（プロパティ値を確定しなければならないデータたち）を絞っているのです
今はこんな風にしてます(実際のコードでは日本語変数じゃないです)
候補データリスト = 追加したいデータのリスト.Except(全リスト, new MyClass_WeakComparator()).ToList();
↓
候補データリスト について全プロパティ確定作業; //←重い
↓
全リスト = 全リスト.Union(候補データリスト).ToList();
1002:デフォルトの名無しさん
17/01/29 23:33:19.34 F8/CipCU.net
>989補足
Union()のところで既定の等値比較子として強比較が使われています
1003:デフォルトの名無しさん
17/01/29 23:37:15.13 M0HgmB1M.net
>>989
insert into 処理対象テーブル
select 追加後の値を得る計算式
from 処理対象テーブル
where 追加対象を得る条件式
これでいいんじゃないの?
弱比較とかよくわからん言葉遣いはやめた方がいい混乱するから
1004:デフォルトの名無しさん
17/01/29 23:50:32.58 M0HgmB1M.net
なんか違うなこうか
insert into 全リスト
select 任意の計算式
from 追加データ
where not exists (
select *
from 全リスト
where 簡易な比較条件式)
and 完全な比較条件式
インデックスは簡易な比較に使うカラムだけでいいよ
1005:デフォルトの名無しさん
17/01/30 00:02:56.22 kb+lR8OL.net
>>992
やはり、条件式を2種類地道に書くしかないんですか…長くてハゲそう
>インデックスは簡易な比較に使うカラムだけでいいよ
アドバイスありがとうございます
1006:デフォルトの名無しさん
17/01/30 00:07:16.67 YrqXkGEW.net
>>989
それだと「弱比較」で一致してしまった物は全部捨ててしまっているがいいのか？
>>985の書き方だと、「弱比較」で一致しても「強比較」で一致しない物があり、
それは書き込むと読める。
まあこの辺はそちらがやればいい話だが。
1007:デフォルトの名無しさん
17/01/30 00:14:31.63 GO+RhKVN.net
数千行のSQLとか当たり前だから!!!
そのためのDBMSでしょ!!!
1008:デフォルトの名無しさん
17/01/30 00:23:01.74 RAZ09caE.net
1回のクエリで完結させようとせず
1次候補抽出クエリ → ローカルで1次候補のプロパティ書き換え → 最終候補抽出＆インサートのクエリ
の3段構えにしてもいいんじゃないかと思うけど
1009:デフォルトの名無しさん
17/01/30 00:33:18.83 kb+lR8OL.net
>>994
>「弱比較」で一致してしまった物は全部捨ててしまっているがいいのか？
詳しくは書けませんが、やりたい動作としてはその動作でOKです
985の説明はちょっと正確ではありませんでした
>>995
大規模なデータベースを触ろうとするのは初めてだったので…すいません
>>996
どっちみち長い比較条件を書かないといけないのは避けられそうにないので
その方法でもよさそうですね
1010:デフォルトの名無しさん
17/01/30 01:03:13.10 9w4b/GJp.net
>>995
SQLが数千行もあって当たり前なの？異常じゃないの？SQLだよ？
1011:デフォルトの名無しさん
17/01/30 02:19:40.86 ty17mMxy.net
SQL Serverは問合せ文と制御文を１つのｽﾄｱﾄﾞに混在できるので複雑な工夫が容易で、
腕が良ければ数千行の複雑な処理を書くことによって物凄く高速化できることがある
Oracleは混在できないため複雑な処理を書くには手間がかかり、ﾌﾟﾛｸﾞﾗﾏｰがあまり工夫しなくなり、
そのため腕が上がらず、結果としてSQL Serverより遅いｼｽﾃﾑが多いらしい
現在のSQL ServerにはOracleと同じｽﾅｯﾌﾟｼｮｯﾄ分離（古い人は「行ﾛｯｸ」って言う）があるが、
2000の頃はなかった（今でもﾃﾞﾌｫﾙﾄでｵﾌになってる）ため、高速な更新処理が必要だったことも腕に関係すると思われる
（ｽﾅｯﾌﾟｼｮｯﾄ分離があれば、ﾀﾞﾗﾀﾞﾗ更新しても他ﾕｰｻﾞｰの閲覧に迷惑かけない）
1012:デフォルトの名無しさん
17/01/30 02:31:32.87 RISpHKLn.net
次スレ
C#, C♯, C＃相談室 Part92 [無断転載禁止]©2ch.net
ｽﾚﾘﾝｸ(tech板)
1013:過去ログ ★
[過去ログ]
■ このスレッドは過去ログ倉庫に格納されています