ADO.NETの質問・雑談スレ2 (421レス)
ADO.NETの質問・雑談スレ2 http://mevius.5ch.net/test/read.cgi/db/1234077152/
上
下
前
次
1-
新
通常表示
512バイト分割
レス栞
1: NAME IS NULL [sage] 2009/02/08(日) 16:12:32 ID:??? ADO.NETに関する質問・雑談・評価 etc 何でもどうぞ。 前スレ ADO.NETの質問・雑談スレ http://pc11.2ch.net/test/read.cgi/db/1104630889/ http://mevius.5ch.net/test/read.cgi/db/1234077152/1
2: NAME IS NULL [age] 2009/02/09(月) 20:25:16 ID:??? 前スレの流れ 1.DataAdapterってReadOnlyにしか使えないね。 ・自動生成のSQLはUpdateのコードは使えない。 ・やはり、Updateは自分で生成した方が良い。 ・サーバカーソルが無いしDataTableのDataRowの状態をみて自動生成のスタイルという結論に落ち着く。 2.DataSetって意味あるの? ・DataAdapterからDataTableに読み込んだ方が軽くて良い。 ・GUIを中心としたスタイルならば、型指定されたDataSetもいいかもしれないが。 3.LINQ使えば無問題 ・ADO.NETを使う必要はなくなるよ。 ・いや、これは大幅な仕様変更が出てきそうだから当分はADO.NETじゃね? 4.DataReaderについて ・GUIよりもコードを書くスタイル、とにかく軽さを優先する、非接続の設計の場合はこれが一番。 ・早くて軽いという設計だが、ADO房は無意味にこれを使いたがるから困りものだ。 http://mevius.5ch.net/test/read.cgi/db/1234077152/2
3: NAME IS NULL [sage] 2009/02/10(火) 10:04:22 ID:??? >>2 まとめ乙。 ところで、4番の非接続は接続の間違いじゃね? http://mevius.5ch.net/test/read.cgi/db/1234077152/3
4: NAME IS NULL [age] 2009/02/10(火) 20:27:31 ID:??? >>3 確かにそうだ。投下した後に気づいたが、無駄にスレを汚すので、 ま、いいやと思ってたw http://mevius.5ch.net/test/read.cgi/db/1234077152/4
5: NAME IS NULL [age] 2009/02/12(木) 07:29:56 ID:??? UPDATE のコードを自分で書くしかないという結論には同意だけど、 では、具体的にどんなコードを書いたら良いの?って感じの情報交換は 出来ないのかなぁ?(ADO.NET とはずれてくる話かもしれないが) 例えば、同時アクセスが少ない場合は WHERE 以下は主キーのみで良いとか、 もうちょっとシビアに考えるならば、タイムスタンプを使ったほうが良いとか、そういう 意見交換なんだけど。 スレの誘導でもかまわないので、どなたか意見お願いします。 http://mevius.5ch.net/test/read.cgi/db/1234077152/5
6: NAME IS NULL [age] 2009/02/12(木) 21:47:30 ID:??? DataAdapterの機能はしょぼいとか使えないとか言われているけれど、 ライブラリの機能として提供できるものはこれくらいで終わりなのかな? 市販のでは、「複数のテーブルを参照する SQL によって取得したデータであっても 自動で更新するコードを生成する」ライブラリはあるようだが。 ttp://www.asterworld.com/ja/srcdoc/Asterworld.Data.AwDbExData.html VB6までの時は、純粋にVBだけでの開発は効率が悪くて、別の会社が出してる モジュールをあわせて購入するのが当たり前になってたけど、.NET の場合も そんな感じに落ち着くのかな。 ttp://www.grapecity.com/japan/support/database/dotnet_productlist.htm http://mevius.5ch.net/test/read.cgi/db/1234077152/6
7: NAME IS NULL [sage] 2009/02/13(金) 01:17:49 ID:??? >>5 SELECTで取得した対象に主キー揃って無いとダメとか制限あったような<自動生成 自分の場合は、WHERE以下は主キー+更新時刻で楽観ロックとすることが多い。 >>6 それなりのことは.NET内で出来てしまうから、 .サードパーティの製品が必要かどうかを考え直す癖がついたな。 Excelの出力とか、客の要求が細かいときのGrid周りとか、 そういうめんどくさいところは予算と期間と相談して決めてる。 http://mevius.5ch.net/test/read.cgi/db/1234077152/7
8: NAME IS NULL [] 2009/02/13(金) 08:11:48 ID:EjaPaESH 更新時刻じゃ秒が重なったら終わりじゃん? せっかくタイムスタンプがあるんだから タイムスタンプ使った方がいいんじゃん? http://mevius.5ch.net/test/read.cgi/db/1234077152/8
9: NAME IS NULL [sage] 2009/02/13(金) 11:04:03 ID:??? タイムスタンプを使ってないということは、Accessのmdbファイルに 限った話なのかな? http://mevius.5ch.net/test/read.cgi/db/1234077152/9
10: NAME IS NULL [sage] 2009/02/13(金) 11:10:20 ID:??? 俺の場合、UPDATEはシビアに同時実行制御をする必要がないため、 (比較的規模の小さな、数人使用のシステムの場合が多い為) WHEREは主キーを指定するのみで、強制上書き方式でやってる。 強制上書きというのは、「読み込み時」と「データ更新直前」の データが同じであるかをチェックせずに、主キーを指定して UPDATEを実行という意味合い。 すでに誰かがレコードを削除していて・・・という場合はエラーが 出るが、そのあたりの処理は書く必要もないかなと思う感じ。 「設計は場合による」といってしまえばそうだが、個人レベルの 開発だとこういうのが大多数じゃないかなと思うけど、どうかな。 http://mevius.5ch.net/test/read.cgi/db/1234077152/10
11: NAME IS NULL [sage] 2009/02/13(金) 13:04:13 ID:??? TIMESTAMPも使うけど、数人〜の小規模で 業務内容的に被らない想定のときは 更新日時の列作って使いまわしてしまう。 同じ業務の人が何人も居て被るかもーとなったらTIMESTAMP、 衝突上等となったら…行ロックするか、一次的な編集禁止フラグでも立てるか。 http://mevius.5ch.net/test/read.cgi/db/1234077152/11
12: NAME IS NULL [] 2009/02/13(金) 20:14:08 ID:EjaPaESH >>10 消えてもいいデータがあるってのならいいけど timestamp列をつくって主キーと一緒にチェックするだけで 楽観ロックできるんだからやったほうがいいと思うけどなぁ。 http://mevius.5ch.net/test/read.cgi/db/1234077152/12
13: NAME IS NULL [age] 2009/02/13(金) 23:59:49 ID:??? >>12 データを更新する際、主キーは同じだけどtimestampが異なってるという時の 処理は具体的にどうするのって思ってしまうんだよね。 ユーザに(「このデータは誰かが更新中です。上書きしますか?」みたいな) ダイアログを表示させても、ユーザは結局はそのダイアログだけでは上書きしても 良いかどうかの判断は出来ないしね。 適当に「はい」を押してしまえってなって、その機能を実装した意味が実質 なかったりするって体験があったんだけど、どうよ? これは、たまたま俺が悪いユーザにあたっただけかな? http://mevius.5ch.net/test/read.cgi/db/1234077152/13
14: NAME IS NULL [age] 2009/02/14(土) 00:08:41 ID:??? どういうアプリであるかによって、処理内容がという場合もあると思うので、 具体例を一応書いておきます。 名簿の管理ソフト すでに登録しているAさんのデータを修正し、「更新」ボタンを押した。 その時、「すでに他の人が・・・」というメッセージが表示された。 その時点では、他の人が修正したデータの内容は確認出来ない。 また、念のためと思って更新しないで、データを確認してみると、 間違ったデータであり、自分は再度同じデータを入力する羽目に なってしまった。ああ、面倒だ・・・みたいな。 http://mevius.5ch.net/test/read.cgi/db/1234077152/14
15: NAME IS NULL [sage] 2009/02/14(土) 00:54:50 ID:??? 基本はエラーメッセージを出して入力し直しだろうな 間違ったデータを入れるとかかなりレアなケースだろうし、 99%くらいは、あ、オレの代わりに誰か入れといてくれたか くらいですむんじゃね? こんなん絶対ゆるさーん、とかいうユーザは しょうがないからフラグでもたててロックかけるしかないんじゃね? http://mevius.5ch.net/test/read.cgi/db/1234077152/15
16: NAME IS NULL [sage] 2009/02/14(土) 19:41:36 ID:??? 基本は読み直して再入力でしょう 楽観的ロックすらしないでおくと 先に編集したのが無効になっちゃうわけだから オフコン使ってた時はそんなの関係ねーでやってたみたいだけどね 富士通cobolだったかな あとはロックとかフラグたてるけどあとから来たほうが所有権 ぶんどれるような仕掛けにするとか http://mevius.5ch.net/test/read.cgi/db/1234077152/16
17: NAME IS NULL [sage] 2009/02/15(日) 12:22:31 ID:??? >>13 既に書かれてるけど、結論はケースバイケース。 ・エラーメッセージを出して更新処理を中断し、再度データ確認後に必要なら再入力。 ・そんなの関係ねぇで、更新する。 俺がいつもやるのは下記の通り。 主キーとタイムスタンプでチェックし、タイムスタンプが異なっていた場合、 ・エラーメッセージを表示 ・更新画面でユーザが入力した値は残しつつ、現在のデータを並列表示させる。 (別画面とか入力項目の上とか画面上または下とか場合によって表示場所は事なるが・・・) ・ユーザは現在の内容を確認し、変更の必要がなければ処理を中止 ・変更が必要な場合は再度入力値を確認、修正の後に更新を行う事ができる。 http://mevius.5ch.net/test/read.cgi/db/1234077152/17
18: NAME IS NULL [age] 2009/02/15(日) 17:16:16 ID:??? ケースごとに分けてWHERE以下などをどう書いていったらよいのかをまとめるといいかもね。 ケースバイケースという結論になるのも分かるけれど、どういう処理をした方が良いかは ADO.NETは提供しない(当然だが)のだから、そのあたりのノウハウをまとめるのは必要だと思う。 0.スタンドアロン ・UPDATE時は主キーのみでおk ・将来の拡張を考えるならば、1を参考にコーディングしておくと良い。 1.小規模、同時アクセスが少ないケース ・UPDATE時のWHERE 以下は主キーとタイムスタンプで確認 ・ダイアログを出して判断を促すなど。 2.同時アクセスが多く、先にデータを表示させた方が更新できるようにするケース (列車の予約で、空席の状況を確認し、予約するなどのケース) 3.同時アクセスが多く、確実に更新処理を行いたいケース (銀行で自分の口座から他銀行の口座へ振込みを行うなど) http://mevius.5ch.net/test/read.cgi/db/1234077152/18
19: NAME IS NULL [age] 2009/02/15(日) 23:36:07 ID:??? 3においてはUPDATEの内容よりも、Transaction を設定するみたいな話だな。 「ケースに分けてWHERE以下」というよりも、「ケースに分けてUPDATEの方法を」だったな。訂正 http://mevius.5ch.net/test/read.cgi/db/1234077152/19
20: NAME IS NULL [sage] 2009/02/20(金) 19:02:54 ID:??? ADO.NETになっても結局SQL文を生成するスタイルはそんなに変わらないの? http://mevius.5ch.net/test/read.cgi/db/1234077152/20
上
下
前
次
1-
新
書
関
写
板
覧
索
設
栞
歴
あと 401 レスあります
スレ情報
赤レス抽出
画像レス抽出
歴の未読スレ
AAサムネイル
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.006s