- 1 名前：仕様書無しさん [2007/02/07(水) 01:32:56 ]
- って思う
- 2 名前：専門卒（英語科） 田崎 [2007/02/07(水) 01:53:41 ]
-
>>1
馬鹿ね。
普通はハードコーディングするでしょｗ？
- 3 名前：仕様書無しさん mailto:sage [2007/02/07(水) 01:54:00 ]
- ２ゲット
- 4 名前：仕様書無しさん mailto:sage [2007/02/07(水) 01:55:11 ]
- あらゆるSQLはテキストにするプロジェクトに関わったことがある。
はっきりって何もいいことがない。
- 5 名前：仕様書無しさん [2007/02/07(水) 01:59:35 ]
- ハードコーディングすると保守性さがんじゃん
何もいいことないとかバカじゃね？
- 6 名前：仕様書無しさん mailto:sage [2007/02/07(水) 02:02:26 ]
- デバッグしづらいだけだろ。
- 7 名前：仕様書無しさん mailto:sage [2007/02/07(水) 02:05:46 ]
- 所詮プログラムと一対一になるものをわける意味がわからん。
- 8 名前：仕様書無しさん mailto:sage [2007/02/07(水) 02:06:33 ]
- 300行位使ってSQL成形するやつ見た事ある
あんなの触る位なら死んだ方がいいね
- 9 名前：仕様書無しさん mailto:sage [2007/02/07(水) 02:09:13 ]
- >>7
君この業界諦めた方がいいよ
- 10 名前：仕様書無しさん mailto:sage [2007/02/07(水) 02:15:39 ]
- >>5
UIしかやったことのない厨房はひっこんでろ。
- 11 名前：仕様書無しさん mailto:sage [2007/02/07(水) 02:16:25 ]
- >>8
３０００行というやつもいたぞ。
- 12 名前：仕様書無しさん mailto:sage [2007/02/07(水) 02:18:48 ]
- むしろ早くLINQみたいなのが出てくれと思ってる
- 13 名前：仕様書無しさん mailto:sage [2007/02/07(水) 02:19:13 ]
- RDBをいじるプロジェクトには3回参加した。
C++の中にSQL文字列が埋まってるのは確かにちと無様だが、
未だにどうやるのがいいのか分からん。
ハードコーディングじゃない、ってのはどうやるんだ？
- 14 名前：仕様書無しさん mailto:sage [2007/02/07(水) 02:25:43 ]
- SQL文を書かなくていい程度ですむプロジェクトにしか関わってないなら幸せだな
>>2,5 に同意
- 15 名前：仕様書無しさん mailto:sage [2007/02/07(水) 02:27:32 ]
- >>13
リソースに突っ込んだり、
暗号化した独自の形式の何かに入れておいてそれを使うとかじゃねーの？
どこで何を使っているか等の管理が面倒になって工数が増すという利点がある。
- 16 名前：仕様書無しさん mailto:sage [2007/02/07(水) 02:30:15 ]
- >>13
俺もわからん。
- 17 名前：仕様書無しさん mailto:sage [2007/02/07(水) 02:31:10 ]
- >>14
ちょｗｗｗどっちだ？
>>15
工数が増すという利点にワロタ
- 18 名前：仕様書無しさん mailto:sage [2007/02/07(水) 02:38:53 ]
- DAOとかO/Rマッパーとかそういうのを意図していると思った > スレタイ
- 19 名前：仕様書無しさん mailto:sage [2007/02/07(水) 03:33:25 ]
- >>18
そういう話題の方が意義があるよな。
SQLをプログラムから別にするだけで保守性が増すなんて猿以下のアイデアとしか思えん。
土台のモデルが腐っていればスパゲティ度がむしろ増加する。
- 20 名前：仕様書無しさん [2007/02/07(水) 08:38:43 ]
- 直書きするか否かというのはプログラマの裁量でなく、プロジェクト上の実装方針に依るのでマを責めてはいけない。
実装方針決定者はＳＱＬの書き方に多様なアプローチがあることを知るべき。
直書きだと、どの箇所に何があるかとか管理できないし、一箇所のＳＱＬを変えるだけでビルドやらされたりと、確かに碌なことにならない。
- 21 名前：仕様書無しさん mailto:sage [2007/02/07(水) 08:40:52 ]
- また変な宗教はやらせないでくれよ
- 22 名前：1 [2007/02/07(水) 08:41:11 ]
- >>18
そういうこと
- 23 名前：仕様書無しさん mailto:sage [2007/02/07(水) 08:56:53 ]
- 引き継いで弄ってたソースがSQLべた書きだったんだが、
タダのべた書きではなく、プレースホルダすら使ってねぇ
べた書きだった。文字列連結しまくり。
まぁ、いろんな意味で
この会社辞めようと思ったソースコード＃15
pc10.2ch.net/test/read.cgi/prog/1167117526/
向けだったな。実際会社辞めることにした原因の一つだし。
- 24 名前：仕様書無しさん [2007/02/07(水) 09:31:13 ]
- センスがある奴と無い奴では目の付け所が違うんだよね。
>1さんなんか、もうセンスなさげな匂いがぷんぷんする。
- 25 名前：仕様書無しさん [2007/02/07(水) 10:34:34 ]
- >>24
お前がセンス、ム板だったら、お前が言ってることはただしいが、
ここはマ板なので、むしろセンスないほうがセンスがいい。
- 26 名前：仕様書無しさん mailto:sage [2007/02/07(水) 10:55:26 ]
- SQLを分離して、本体はビジネスロジックに集中ですね
- 27 名前：仕様書無しさん [2007/02/07(水) 12:04:57 ]
- でたービジネスロジック厨ｗ
- 28 名前：1 mailto:sage [2007/02/07(水) 12:05:32 ]
- >>23
クラックされた某サイトが正にそれで、
プレースホルダを使ってない上に値をエスケープしてないがためにSQLインジェクションできまくりな
悲惨なソースコードだった
- 29 名前：14 mailto:sage [2007/02/07(水) 13:05:22 ]
- >>17
ごめん >>2,10 に同意だった...orz
- 30 名前：仕様書無しさん mailto:sage [2007/02/07(水) 18:35:20 ]
- SQLをごちゃごちゃする部分は極力ストアドにして、
プログラム側ではもっぱらそれを呼び出すことに専念
する方向でコーディングした俺は正解なんだろうか。
- 31 名前：仕様書無しさん mailto:sage [2007/02/07(水) 18:45:00 ]
- ストアドはいくない
- 32 名前：仕様書無しさん [2007/02/07(水) 20:16:42 ]
- ストアドか
それも選択の１つだけど
開発が面倒じゃない？
管理も
- 33 名前：仕様書無しさん mailto:sage [2007/02/07(水) 20:26:06 ]
- 一回組んだらそうそう変えないようなのは楽だしパフォーマンスもあがるし、
ＳＱＬも分離できてウマー。
開発は確かに面倒。管理もだな。
動的に検索条件(Where句)が変わるようなのは、特に。
- 34 名前：仕様書無しさん mailto:sage [2007/02/07(水) 20:27:07 ]
- ハードコーディング無しで、DB使うアプリ書ける？そんなの無理でそ。
パラメータ受け取ってSQL文を生成するライブラリを書いてお茶を濁す
のが精一杯。
パフォーマンスの問題で、どうしてもDBMS固有の方言使っちゃうから、
DBMSの切り替えが発生した場合は、ライブラリの書き替えは避けられない。
- 35 名前：仕様書無しさん mailto:sage [2007/02/07(水) 20:29:54 ]
- ストアドって長くすると、デバッグが大変のような。
- 36 名前：仕様書無しさん mailto:sage [2007/02/07(水) 20:31:17 ]
- >>34
リソースとか別ファイルにしておくってことだろ? ハードコーディングしないって。
- 37 名前：仕様書無しさん mailto:sage [2007/02/07(水) 20:35:57 ]
- >>34
そうそう。それでEJBは失敗した。
- 38 名前：仕様書無しさん mailto:sage [2007/02/07(水) 20:49:18 ]
- >>36
そういうことなんだが、組みにくいわ、別ファイルの管理は面倒だわ、
ファイルIO発生しまくりだわ、欠点も多いのだよ。
>>35
かなりな。
- 39 名前：仕様書無しさん mailto:sage [2007/02/07(水) 20:53:59 ]
- 結局、SQLを変えたらコードも変えてコンパイルしなきゃなんない。
だったら、コードに直接埋め込まれていたほうが保守性がいい。
- 40 名前：仕様書無しさん [2007/02/07(水) 21:03:09 ]
- >>39
同感。
１は、取ってきたデータどうするの？ って素朴な疑問。
ひょっとして、配列？ それとも可変な何かすごい仕組み？
わたしゃ、大抵、テーブルと対になるデータ用のクラス用意するよ。
この状況でSQLを外に出すとなると、条件を変えるくらいしかやりようがない。
条件をちろっと変えたければ明示的にオプションにするし。
まあ、外に出してもいいけど、どっちでも良いと思うよ。
そんなこと本質じゃないし。
文字列連結とかは禁止したいけど。フォーマットで当てはめするなら
ハードコーディングでも外から読み込んでもどっちも変わらない。
１は「データベース設計ツール使え」と言ってるのかもしれないけど、
だとしたらそもそもハードコーディングとか言い出さないだろうしなあ。
- 41 名前：仕様書無しさん [2007/02/07(水) 21:05:39 ]
- iBatisつかってるやつはいないの？
- 42 名前：仕様書無しさん [2007/02/07(水) 21:07:15 ]
- SQLの内容次第じゃないか？
コンパイルに時間がかかるSQLならPL/SQLにしとくべき。
いわゆる初回はやたら時間かかるけど二回目以降は早いSQL。
- 43 名前：40 [2007/02/07(水) 21:21:30 ]
-
おっと。
1は18に対して「そう」って言ってるの今気づいた。
そういうの使える環境ばかりじゃないんだがなあ。
恵まれてるのか、経験が少ないのか、勉強しているだけなのか・・・。
ストアドはデバッグし辛いので、パフォーマンスが要求されるところだけにしているオレ。
- 44 名前：69式フリーPG ◆hND3Lufios mailto:sage [2007/02/07(水) 21:31:10 ]
- ストアドは１トランザクション中に複数のSQLを投げる必要がある場合なんか効果的だよね。
- 45 名前：仕様書無しさん mailto:sage [2007/02/07(水) 22:11:37 ]
- ストアドは再現性の無いバグ(本人が気付けないだけ？)に悩まされそうで怖い。
ソースに埋め込んだ方が、トランザクションの一貫性の検証がしやすいし、
トレースも楽でいいよ。
再コンパイルを避けるためだけにSQL文を外に追いやるってのはどうなの？って感じ。
- 46 名前：仕様書無しさん mailto:sage [2007/02/07(水) 22:19:10 ]
- Delete文を動的SQLで生成するルーチン作ったらwhere句の手前にいつも’\0’が入ってたwwwww
ちょwwwwCOMMIT発行すんのまwwwwwwwｑｗせｄｒｆｔｇｙふじこ
- 47 名前：仕様書無しさん mailto:sage [2007/02/07(水) 22:23:07 ]
- >>46
お前、出禁な。
- 48 名前：仕様書無しさん mailto:sage [2007/02/07(水) 22:28:02 ]
- >>46
俺はUPDATEで同じことやらかしたけど、
消えたわけじゃないから罪は軽いよね(´・ω・`)
- 49 名前：仕様書無しさん mailto:sage [2007/02/07(水) 22:30:33 ]
- >>48
出禁40日。>>46は無期限！
- 50 名前：仕様書無しさん mailto:sage [2007/02/07(水) 22:53:28 ]
- データ取るためのSQLと受け取り側のアプリは密な結合だもんなあ。
分割しても結局どちらも修正入ることが殆どだし。
- 51 名前：仕様書無しさん mailto:sage [2007/02/07(水) 22:53:37 ]
- SELECT文はXMLからロード＆更新系は動的生成
これで完璧に動いてますが
- 52 名前：仕様書無しさん mailto:sage [2007/02/07(水) 22:58:12 ]
- おじいちゃん、またそんなｵﾅﾆｰｺｰﾄﾞ書いて。。
- 53 名前：仕様書無しさん mailto:sage [2007/02/07(水) 22:58:34 ]
- >>40
そこでDataSetですよ
- 54 名前：仕様書無しさん mailto:sage [2007/02/07(水) 23:00:06 ]
- またXMLかよ
いい加減にしる！
- 55 名前：仕様書無しさん mailto:sage [2007/02/07(水) 23:03:51 ]
- >>40
> データ用のクラス用意
やるやるｗｗｗ
少なくとも、SQLを書いていいところ(DBアクセス・業務プロセス系)と
書いちゃいかんところ(UIなど)を分けておくと、少し幸せになれる。
- 56 名前：仕様書無しさん mailto:sage [2007/02/07(水) 23:04:41 ]
- >>46-49
ワロタｗｗｗｗｗ
- 57 名前：69式フリーPG ◆hND3Lufios mailto:sage [2007/02/07(水) 23:13:44 ]
- ストアドのいいところはシステムを止めずにロジック変更が出来ることもあるな。
- 58 名前：仕様書無しさん mailto:sage [2007/02/07(水) 23:18:29 ]
- >>57
気づかなかった
- 59 名前：仕様書無しさん mailto:sage [2007/02/07(水) 23:25:56 ]
- だからといって、1行インサートするだけのｵﾅﾆｰストプロ書くのは止めてください。先輩。
- 60 名前：仕様書無しさん mailto:sage [2007/02/07(水) 23:32:36 ]
- >>37
おまえ、Seasarの人間？EJB批判すんのもいいけど、考え無し過ぎる独自仕様もどうかと思うぜ。
- 61 名前：仕様書無しさん mailto:sage [2007/02/08(木) 00:10:38 ]
- これからの時代ORMでしょ。SQLを生で使うのダサいよ。
Java厨ならHibernateを使え。キャッシュをうまく使えばSQLの直書きより性能いいゾ。
- 62 名前：仕様書無しさん mailto:sage [2007/02/08(木) 00:13:18 ]
- 常識的に考えて、このスレはJava屋限定にすべきだろ。
>>40とか、何しに入ってきてるんだよ。。
- 63 名前：仕様書無しさん [2007/02/08(木) 00:14:47 ]
- Java厨ってさ、SQL書くのが下手な奴多くね？実行計画の見方も知らない見たいだし。
- 64 名前：仕様書無しさん mailto:sage [2007/02/08(木) 00:22:19 ]
- ＤＢといえばOracleオンリーな、柔軟性の無い奴もよくいるな。
- 65 名前：仕様書無しさん mailto:sage [2007/02/08(木) 00:35:46 ]
- SQLの書き方次第でパフォーマンスに大きな違いがでる間は、ハードコーディング
せざるをえない。
- 66 名前：仕様書無しさん [2007/02/08(木) 00:42:42 ]
- toruqueを使えばSQLなんて書かなくていいよ。あほじゃん？
- 67 名前：仕様書無しさん mailto:sage [2007/02/08(木) 00:43:10 ]
- そんな微妙なチューニングが必要になる場合って、大抵テーブル設計が
糞だけどな。
- 68 名前：仕様書無しさん mailto:sage [2007/02/08(木) 02:14:30 ]
- ORマッピングなんて作り手の自慰行為じゃねーか
EJBと同じ匂いがするぜ
- 69 名前：仕様書無しさん mailto:sage [2007/02/08(木) 07:10:53 ]
- >>66
パフォーマンス無視だけどなｗ
- 70 名前：仕様書無しさん mailto:sage [2007/02/08(木) 07:54:17 ]
- >>61
ハイバネはまだまだバギーすぎて、本腰入れて使うのは厳しくない？
DBとの相性もあるかもしれないけど。
- 71 名前：仕様書無しさん [2007/02/08(木) 08:31:29 ]
- この手の話は
酒のつまみにはなるけど
飯の種にはならんな
- 72 名前：仕様書無しさん mailto:sage [2007/02/08(木) 08:32:04 ]
- EJBで性能でなくて生SQLに全部書き換えしたプロジェクト知ってる。
- 73 名前：仕様書無しさん mailto:sage [2007/02/08(木) 08:41:05 ]
- そいへばテーブルのvarchar項目にSQL断片を入れておいて
SELECTで組み上げてからそれをまた実行する変な仕事を
こないだしたな。そのクエリ結果の中にまたSQL文が入ってる(w)
- 74 名前：仕様書無しさん mailto:sage [2007/02/08(木) 08:46:19 ]
- >>73
ｗｗｗｗｗ
- 75 名前：仕様書無しさん mailto:sage [2007/02/08(木) 09:36:08 ]
- >>70
たぶんOracleのJDBCドライバが腐ってるせいだと思う。
Hibernateは悪くない。
- 76 名前：仕様書無しさん mailto:sage [2007/02/08(木) 09:38:36 ]
- ADO.NETが一番よくできてる
- 77 名前：仕様書無しさん mailto:sage [2007/02/08(木) 10:18:44 ]
- ADO.NET使える環境なら、それ使うにあたって議論は無いはず。
C/C++環境ならORM自作しなきゃいけないが、そんなことは誰もやらないはず。
- 78 名前：仕様書無しさん [2007/02/08(木) 11:44:37 ]
- PL/SQLを書く香具師の方が死んで欲しい。
- 79 名前：仕様書無しさん [2007/02/08(木) 12:13:54 ]
- 一番氏んで欲しいのは、AccessがないとDB触れない奴
- 80 名前：仕様書無しさん [2007/02/08(木) 12:19:43 ]
- UNIXでPro*Cとかだと、ストアドの方が文法的にも簡単で楽チン。
- 81 名前：仕様書無しさん [2007/02/08(木) 12:21:11 ]
- Pro*Cのソースは見れたもんじゃない
- 82 名前：仕様書無しさん [2007/02/08(木) 12:31:21 ]
- ORマッピングってやったことないんだけど、どーなのよ。
使いにくいんか?
- 83 名前：仕様書無しさん mailto:sage [2007/02/08(木) 13:29:21 ]
- >>82
かなり便利だが性能は出しにくいし たまに融通が利かない
- 84 名前：仕様書無しさん [2007/02/08(木) 14:11:36 ]
- >>83
iBatisだったら全然そんなことないぜ。
hibernateは理念にこだわり過ぎて美しいけど遅い。
SQL文レベルのチューニングだったら全然やりやすいし。
- 85 名前：仕様書無しさん [2007/02/08(木) 14:39:46 ]
- ORマッピングツール使えば
DBの表にあわせてクラスを生成しなくていいの？
- 86 名前：仕様書無しさん mailto:sage [2007/02/08(木) 15:21:25 ]
- ORマッピングの最高峰はWebObjects
- 87 名前：仕様書無しさん [2007/02/08(木) 15:25:52 ]
- >>86
アップル信者死ね。
- 88 名前：仕様書無しさん mailto:sage [2007/02/08(木) 15:34:34 ]
- >>87
アホ
俺は生粋のMS信者
- 89 名前：仕様書無しさん [2007/02/08(木) 17:44:23 ]
- ハードコーディングってなに？
- 90 名前：仕様書無しさん mailto:sage [2007/02/08(木) 19:52:29 ]
- >>89
表面を金属とかで堅く覆うことだろ．
- 91 名前：仕様書無しさん mailto:sage [2007/02/08(木) 19:54:58 ]
- >>89
一生懸命プログラミングすること
- 92 名前：仕様書無しさん mailto:sage [2007/02/08(木) 21:15:37 ]
- ととっとしネ
- 93 名前：仕様書無しさん mailto:sage [2007/02/08(木) 21:48:10 ]
- >>86,88
EOF,っても通じないしなぁ。
Cayenneとかはどーなんでしょ
- 94 名前：仕様書無しさん mailto:sage [2007/02/08(木) 22:37:25 ]
- >73
メタメタですね
- 95 名前：仕様書無しさん [2007/02/09(金) 00:48:56 ]
- >>93
>Cayenne
たぶんさ、Cayenneみたいなつくりだと、springとか使っても
service層とdao層きちんと分けないでつくっちゃうやつがプロジェクトに
出そうだから、辞めた方がいいんでは。
- 96 名前：仕様書無しさん mailto:sage [2007/02/09(金) 02:36:48 ]
- >>79
補助ツールとしては便利だけどね。
アレなしだと触れない奴はちょっとだな。
>>80-81
禿同
>>83
ちょkwsk
俺もORマッピング使ったことない。
- 97 名前：仕様書無しさん [2007/02/09(金) 08:47:24 ]
- ORマッピングフレームワークを使わない理由
・興味があって調べたらxmlを書きまくらないとﾀﾞﾒなのが分かる
・どういう設定をすればいいのかぱっと分からない
・それで便利になるの？という疑心暗鬼
・スピードは？ 融通性は？
・うーん。。。
・(ﾟ⊿ﾟ)ｲﾗﾈ
- 98 名前：仕様書無しさん mailto:sage [2007/02/09(金) 13:54:43 ]
- >>97
マジレスすると
オレの場合iBatisと自作のO/Rマッピングツールを使ったことがあるけど
>・興味があって調べたらxmlを書きまくらないとﾀﾞﾒなのが分かる
velocityとかのテンプレートエンジン使って自動生成しる。
複雑なSelect文なんかはO/Rマッピングツールは苦手だから
そこらへんはビュー作って対応すると幸せ。
>・どういう設定をすればいいのかぱっと分からない
慣れろ
>・それで便利になるの？という疑心暗鬼
例えばDBのカラム名がクラスのメンバ名になるから配列の3番目がUserNameとか面倒な事を考えなくてもいい。
あとDBのカラムが減ったり名称が変わったときにコンパイルが通らなくなるから
実行時のエラーが減ってバグが減少する。
>・スピードは？ 融通性は？
単純な更新系ではそんなに変わらない気がする。
うちではバッチ系とかスピード求める部分にはストアドを採用した。
- 99 名前：仕様書無しさん [2007/02/09(金) 14:52:55 ]
- ＞あとDBのカラムが減ったり名称が変わったときにコンパイルが通らなくなるから
＞実行時のエラーが減ってバグが減少する。
え？
じゃあDBの構成を変えたら、ロジックに関係なくてもソース直さなきゃいかんの?
例えば客先要望で「UPDDATEというのをUPDATE_DATEに変えてもらえますか?」とか言われたら
更新日付なんてINSERT文の中にSYSDATE入れてただけでも直さなきゃいかんの？
- 100 名前：仕様書無しさん mailto:sage [2007/02/09(金) 15:13:28 ]
- クライアント数が多いシステムだときついね。
- 101 名前：仕様書無しさん [2007/02/09(金) 15:15:02 ]
- >>99
INSERT文が
INSERT INTO HOGE VALUES(...
だったらいいけど
INSERT INTO HOGE(UPDDATE) VALUES(...
ならダメじゃないか？
|
 |
