07/02/14 19:35:20
>>246
つーかiBatisは無視ですか、そうですか。
248:69式フリーPG ◆hND3Lufios
07/02/14 20:36:01
福岡の那の津埠頭にはSOLってラブホがありますが、あれがSQLに見えたときは
休んだほうがいいとオモタ。
249:仕様書無しさん
07/02/14 21:37:17
タケノコのように生えてる銀色の塔を思い出した。
250:仕様書無しさん
07/02/14 23:00:32
どーでもいいが、
strSql = strSql + "～～～"
strSql = strSql + "～～～"
strSql = strSql + "～～～"
以下略 な書き方を解消する方法を開発してくれ。
だるいから。
251:仕様書無しさん
07/02/14 23:04:56
>>250
HibernateTemplate ht = new HibernateTemplate(sessionFactory);
ht.get(Hoge.class, id);
252:仕様書無しさん
07/02/14 23:07:48
>>251
ぐぐったが、、、
情報すくねー（泣
けどさんく～
253:仕様書無しさん
07/02/14 23:20:03
>>250
string sql = String.Format("SELECT {0} FROM {1} WHERE {2}"...);
とか言ったりして……ハハ
254:仕様書無しさん
07/02/15 00:18:33
>>253
さすがにそう書くくらいならPreparedStatementニスル。
255:仕様書無しさん
07/02/15 00:33:24
>>254
そう書かなくてもしろよ！
SQLインジェクションどうすんだよ！
256:仕様書無しさん
07/02/15 00:48:17
>>253
俺ガイルｗｗｗ
257:仕様書無しさん
07/02/15 01:18:58
>>246
URLﾘﾝｸ(www.hibernate.org)
216じゃないけど、これじゃだめかな？
258:仕様書無しさん
07/02/15 08:48:14
ハイバ使っても
String hqlDelete = "delete Customer c where c.name = :oldName";
みたいなこと書くんだ
へー
259:仕様書無しさん
07/02/15 21:24:40
>>253
XMLで作れるんじゃね？
<?xml ?>
<select>
<table><t/able>
<colmuns><<olmuns>
<where>
<item></item>
<type></type>
<value></value>
</where>
</select>
sql.select.setColmuns("*");
sql.select.setTable("テーブル");
sql.select.setWhere.setiIem("firstname")
sql.select.setWhere.setType("=")
sql.select.setWhere.setValue("hamada")
260:仕様書無しさん
07/02/15 21:30:13
>>259
冗長なだけのような･･･
261:仕様書無しさん
07/02/15 21:43:12
冗長大好き<java房
262:仕様書無しさん
07/02/15 23:01:35
>>261
Java周辺の話って庭の草取りに燃料気化爆弾使うようなのばかりだな。
263:仕様書無しさん
07/02/15 23:06:48
一応Javaの方でも反省はあるみたいだけどね。POJOとか。
あとC++みたいに言語自体がでかいのと比べると
ドングリの背比べのような気もする。
Rubyとか流行らないかなぁ
264:仕様書無しさん
07/02/16 00:51:24
C++って言語でかいか？
265:仕様書無しさん
07/02/16 01:13:37
言語仕様が複雑って意味ででかいと言ってるならでかいだろう
266:仕様書無しさん
07/02/16 22:20:05
すぐに言語比較に持っていくんだから・・・
267:仕様書無しさん
07/02/17 02:15:14
SQLとSQLとSQLの比較よろ。
268:仕様書無しさん
07/02/17 18:32:09
ADO.NET使いはこのスレにいるかい
269:仕様書無しさん
07/02/17 20:02:37
おジャバ様のすくつにそんな人いません＞＜
270:仕様書無しさん
07/02/17 20:17:59
>>268
ノ
後輩に何度ヤメレと言っても、>>250のような書き方を改めてくれない。
上司じゃないから強制は出来んしなぁ・・・会社辞めるときﾇｯｺﾛｽ
271:仕様書無しさん
07/02/17 21:58:39
>>270
おまいさんはどういうふうに書いて（処理して）るんだい？
272:仕様書無しさん
07/02/17 23:29:32
>>271
確かに知りたいよなぁ．．．。素のCでSQLのオンコーディングする時、
うちは
strcpy(acSql,
" SELECT"
" col_a"
",col_b"
" FROM"
" sample_table"
" WHERE"
・・・
);
てな感じで埋め込んでるが、もっとマシな手段ないかなぁ。
273:仕様書無しさん
07/02/17 23:35:41
>>272
どんな環境なのか知らんけど、これだとSQLインジェクションし放題じゃない？
274:仕様書無しさん
07/02/17 23:39:07
>>272
少なくともsprintf的な書き方をした方が・・・。
そうすれば、sql文を別ファイルなり、データベースなり、リソースなり、どこにでも置ける。
strcpyとかstrcatでくっつける、ってのはキツイと思うよ。
275:仕様書無しさん
07/02/18 00:07:09
ストアドオンリーってのが一番いいのかな
276:仕様書無しさん
07/02/18 00:12:01
動的に条件が変わる場合のストアドはどう実装すれば……
条件毎にストアドつくる？
277:仕様書無しさん
07/02/18 00:14:41
>>275
以前はそう思ってたが、今はDBに実装載せるのはどうかと思う
278:仕様書無しさん
07/02/18 00:16:44
そういえばVBのプログラムで
1.Accessのmdbファイルを一個用意
2.mdbファイルにリンクテーブル作りまくり
3.クエリも作りまくり（パラメータクエリ・更新クエリetc）
4.VBからmdbのクエリ呼ぶ
っていうのを見たことがあったなあ。
クエリでOracleとSQLServerとMySQLを連結したりとか。
279:仕様書無しさん
07/02/18 00:18:45
>>276
WHERE句とかの話なら、パラメータや引数であかんの？
280:仕様書無しさん
07/02/18 00:19:47
>>278
一時的なデータ編集用ならありかもしれないけど、
恒常的に使うシステムとしては脆弱すぎ。
281:仕様書無しさん
07/02/18 00:20:46
>>277
その心は？
いろんな事情があるかもしれないけど、参考にお聞かせ願いたい。
個人的にはどこに実装してもかまわんと思うけどね。
DBなんてそうそう換えるもんじゃないから、ストアドにぶちこんであとｼﾗﾈでいいんじゃないかなー、なんて。
282:仕様書無しさん
07/02/18 00:23:10
SQLの書かれてるファイルなりリソースと
それを実行するソースが分かれてるのも
良くないと思う。
283:仕様書無しさん
07/02/18 00:25:53
>>280
激しく同意なんだけど病院で使われているという恐ろしい事実
284:仕様書無しさん
07/02/18 00:29:58
>>282
そうか？
個人的には関数の本体コードとそれを呼び出すコードが別ファイルにあるようなモンだと思うんだけど('A`)
285:284
07/02/18 00:34:18
そうでもないような気がして来た
286:仕様書無しさん
07/02/18 10:11:25
動的にwhere句に現れるフィールドを変更したいって事？
287:仕様書無しさん
07/02/18 10:34:02
ストアドはデバッグしづらいから
速度がでないなどの問題がない限り使わないで欲しい。
288:仕様書無しさん
07/02/18 10:51:10
>>287
禿同
使うにしても３０行ぐらいまででお願い。
289:仕様書無しさん
07/02/18 11:16:56
パラメータ使うに決まってるだろうがハゲ学生が
290:仕様書無しさん
07/02/18 12:16:47
一つのシステムで完結するなら良いけど，
Webシステムでオンラインユーザからの更新と，
クラサバのVB製システムから更新が同時に入ったりする
古くて大規模なシステムだと，
結局ロジック部分をストアドプロシージャでまとめるしか無かったりする．
まぁストアドが全般的にデバッグとかしにくいってのは禿同
291:仕様書無しさん
07/02/18 17:58:56
あー
クライアントの種類が１つじゃない場合には有利か
まぁストアドが全般的にデﾉ
292:仕様書無しさん
07/02/18 21:30:02
>>271
SQLはXMLの中に書いて自動生成させてるだよ。（環境がVB.NET＋ADO.NETなもので
準備済みSQL使えというてるのに、
わざわざ>>250のような書き方でSQLインジェクションの穴作ってくれるの…('A`)
293:仕様書無しさん
07/02/18 22:13:48
普通に結合度の高さを判断して高いと思われるほうにくっつけるだよ
294:仕様書無しさん
07/02/18 22:44:46
あー、用意されてんならそれ使うべきだね
295:仕様書無しさん
07/02/18 23:31:46
外部結合とかサブクエリのSQL自動生成出来るの？
296:仕様書無しさん
07/02/19 00:54:28
SQL自体を変えること自体があんまりないような気がするんだが……
ハードコーディングしてもしなくても大差ないんじゃね？
297:仕様書無しさん
07/02/19 01:10:25
>>295
できるけど、できたらそれ使うか？
そういう問題じゃない気が。。
298:仕様書無しさん
07/02/19 01:36:52
複雑なSQLが必要な場面って
大抵システムのボトルネックになるから人力で調整が必須なものなんだよね。
299:仕様書無しさん
07/02/19 07:01:13
SQLで苦労するって
テーブル構成が糞なんじゃないかと
300:仕様書無しさん
07/02/19 18:03:43
データ取得 → Viewつくって一発
データ更新 → ストアドつくって一発
ベタでいいじゃん
301:仕様書無しさん
07/02/19 22:31:22
>>300
原則これだよね。
302:仕様書無しさん
07/02/19 22:52:49
だから、Viewは、遅いと（ｒｙ
ループですな
303:仕様書無しさん
07/02/19 23:13:44
viewならびゅーっといきそうなもんだが
304:仕様書無しさん
07/02/19 23:17:09
viewより手組の方が早いと考えるのは素人
305:仕様書無しさん
07/02/19 23:18:18
>>300
View作って取得すると実際はどのテーブルにどのデータが入ってるのか
ってのが分かりにくいからあんまり好きじゃないんだよなー。
中途半端に計算された値とかも入ってると保守のとき泣ける。
まぁ、結局テーブル設計がクソって所に帰着する事が多いが。
306:仕様書無しさん
07/02/19 23:48:37
viewはorder byできないじゃない。
307:仕様書無しさん
07/02/19 23:50:00
>>306
ｳｿﾂｹ
308:仕様書無しさん
07/02/19 23:54:57
>>300
どういう論理展開なんだ？
309:仕様書無しさん
07/02/20 00:12:27
>>306
SQL自体を勉強しなおしてから出直せ。
310:仕様書無しさん
07/02/20 08:04:32
>>306
神降臨
311:仕様書無しさん
07/02/20 11:37:59
>>298
既存のパッケージ品をカスタマイズして使わされる時も複雑になるね。
汎用機時代のファイル構造をそのままRDBに入れ直（ry
>>302
ビュー遅いか？
元のテーブル構造が悪いと思うが……。
あるいはちゃんと結合できてないとか。
>>305
俺もあまり好きじゃないけど、設計書みればわかるから問題になったことはないなあ。
元テーブルの構造を隠蔽して単純化できるからその点は好き。
>>306
使ってるDB教えてくれ。
>>308
俺も思った。
ビューとストアドを使うのはいいが、ベタ書きする理由にはならんよな。
さてメシ食ってこよう
312:仕様書無しさん
07/02/20 12:41:23
自己主張が強いな。
313:仕様書無しさん
07/02/20 13:48:07
iBatisみたいにSQL外に出てると、後のSQLレベルの
チューニングがDBエンジニアだけでできて楽ちん。
314:仕様書無しさん
07/02/20 15:30:41
それはiBatis使わないとできないのか？
315:仕様書無しさん
07/02/20 16:19:48
>>311
>>308はベタ書きじゃなくて、ベタな（一般的な）手法という意味じゃなかろうか。
316:仕様書無しさん
07/02/20 16:44:22
>>313
DBエンジニアがいればいいけどな。。。
317:仕様書無しさん
07/02/20 18:32:42
社内ルールでストアドはおろかビューも使えません
理由は「俺が知らないから（by上司）」
ORマッピングツールなんて夢のまた夢さ
318:仕様書無しさん
07/02/20 20:31:32
それは正しい
319:仕様書無しさん
07/02/20 22:04:29
>>317
ストアドはまだ許す。代替手段があるし、知らん言語は知らんだろうと。
だが、Ｖｉｅｗ程度で投げるな。orz...
320:仕様書無しさん
07/02/20 22:21:35
viewってテーブル構成が糞だと
updateできなかったりなんだりでもうﾜｹﾜｶﾒじゃん
だから使わないほうがいいのさそう言う会社では
321:仕様書無しさん
07/02/20 22:31:17
ハードコーディングならハードコーディングで統一してほしかったな、ウチのプロジェクト……
いろんな手法が混ざってんのは最悪だよ。
ハードコーディング派の中でも>>250みたいな書き方する奴とプレースホルダ使う奴と……
スマン愚痴になってしまった
322:仕様書無しさん
07/02/20 22:36:54
>>321
俺のかかわったプロジェクトにいたっては、
そのほかに、長文Viewを書く奴と、ストアドでカーソル駆動する奴と、
何を狂ったか、RecordSetを一旦テキストファイルに落として操作する奴が
いたわけだ。
323:仕様書無しさん
07/02/20 23:19:53
＞RecordSetを一旦テキストファイルに落として操作する奴
それはさすがにネタだろ？
324:仕様書無しさん
07/02/20 23:35:02
>>323
ワークテーブルならぬワークファイル、しかも固定長だよ。
奴がコボラだったから、テキストファイルを操作するほうが具合よかったそうだ。
325:仕様書無しさん
07/02/21 05:47:32
どうりでウチのシステムのcronにrm -rf /var/hogehogeとか入ってるわけだ
326:仕様書無しさん
07/02/21 07:33:17
>>324
おつかれ
327:仕様書無しさん
07/02/21 11:54:04
>>317
うちも全く同じだったので､上司と血を見るほどの大げんかをしてしまった。
こちらが完全に理論武装してパフォーマンス比較までレビューしたせいか、涙を浮かべて逆ギレされた。
しまいには「その比較実験は完全に捏造だ！」とまで言われ､そのせいで処分まで受けてしまった｡
328:仕様書無しさん
07/02/21 12:10:58
>>327は実にバカだな。
329:仕様書無しさん
07/02/21 12:25:41
>>327
馬鹿かぁーーー！！
お前かーーーー！！
あのあと大変だったんだぞーーーー！！！
そういうときはだな、先輩と上司と一緒に
内々で三人で先にレビューしてだな、上司に
提案させるんだよ！！！！
もう、未だにお前の件で俺が色々やってんだぞーーー！！
まぁ、次ぎ合った時に風俗おごってくれ。
330:仕様書無しさん
07/02/21 12:28:58
>>327
バカな奴だ。329が正解だよ。
331:仕様書無しさん
07/02/21 12:49:12
>こちらが完全に理論武装してパフォーマンス比較までレビューしたせいか、
何が嬉しくてここに書き込るのか知らんが、上司の顔を潰すことを目的にプレゼンしたんだろ。
逆切れしてるのは>>327じゃないの？
ここまで空気を読めないヤツよりは、>>322の一番最後のコボラの方がマシな気がする。
332:仕様書無しさん
07/02/21 14:11:44
ケンカはダメ！みんな仲良くしよ♪
333:仕様書無しさん
07/02/21 15:05:58
アホ上司は、アホだが上司だからな
理論武装と同じ程度の会社組織を壊す覚悟が必要だったな
334:仕様書無しさん
07/02/21 15:09:40
こういうやつは客に対しても同じことしそうだ。
購入した備品にけちつけてみたり。
335:仕様書無しさん
07/02/21 15:53:57
327の能力は評価するが
一緒には仕事したくないタイプ
336:仕様書無しさん
07/02/21 16:28:25
>327の人気に嫉妬
337:仕様書無しさん
07/02/21 17:04:57
ひあああああっ……！あああン！もうっ、もうダメぇ……！イっちゃう……！イっちゃ
う、イっちゃう、イっちゃう、イっちゃあひいいいいいいいいッ！イくうっ！そんなにされ
たらすぐイっちゃうよぉーっ！ああああああ！イク、イク、イク、イク、イク、イクッ！あ
っ、熱いい～ッ！ああああああ！イクうッ！イクイクイクイクっ！イクうううううううううう
う～！あああああああぁ……！あうっ……ああああ……イクう……あひいいいいいい
いぃ……！はへええええ！イグっ！イグうっ！イグイグイグイグ！イグーッ！あへ！
はへえっ！ひゃひいいいい！に、妊娠しちゃうっ！妊娠しちゃうううゥ～！気持ちイイ
ぃ～！妊娠キモチイイよぉ～！ああああああああ！妊娠しながらイグう！イグっ！イ
グうっ！イグうぅーっ！
338:仕様書無しさん
07/02/21 17:09:39
こんなところにまで任豚の魔の手が・・・！！
>>327はスレタイはとっとと氏ね
339:仕様書無しさん
07/02/21 17:23:23
これが世に言う「コミュニケーション能力の欠如」というやつかね。
340:仕様書無しさん
07/02/21 17:34:07
とっとさんって誰？
341:仕様書無しさん
07/02/21 18:37:41
まあそれまでにもいろいろあったんだろうよ
そこまで327を叩くなって
もっとまったりいこうぜ
342:仕様書無しさん
07/02/21 21:44:44
>>341
ま
こ
と
343:仕様書無しさん
07/02/22 01:26:31
いま動いているシステムにバグが大量発生していてソースを色々見てるんだけど、
ガチガチにハードコーディングされてる上にDB構造の更新と整合性がとれていない・・・orz
すでに動いているからあんまり変えたくないんだけど、
やっぱりハードコーディングのままいく・・・のが無難かな？
え？上司や先輩に相談？
SQLとVBわかる人いないんですが・・・
344:仕様書無しさん
07/02/22 12:15:22
>>343
SQLやVBのコードを相談するんじゃなくて、
「ハードコーディングされてて更新と整合性がとれてないんですけど、これに合わせたほうがいいですか?
ちゃんと作り直すとバグは減ると思いますけど○○日くらいかかって、工数は××くらいになりますけど、
これってお客さんから保守で取れますか?」
とかを相談すればいい。
345:仕様書無しさん
07/02/22 13:00:26
>>344
おれは客の時は
そんなん、最初の時に全部しっかり言質とって設計確認してあるし
しかも、やってますっていってソースレビューさせてくんなかったよな！
って毎回言ってやってる。
だいたい半額以下に値切ります。保守費用俺が取ったりw
346:仕様書無しさん
07/02/22 16:08:39
>>345
納品物にソースが入っていればそういうことは言えなくなるし
実際に工数がかかるわけだから、イヤなら他に言ってください、で交渉決裂ってだけだね。
347:仕様書無しさん
07/02/22 16:23:51
>>346
まぁ、うち社長が経済ヤクザだからなw
348:仕様書無しさん
07/02/22 16:27:19
>>347
俗に言う「不良顧客」ってやつだな。
金払いが悪いなら用はないな。
349:仕様書無しさん
07/02/22 16:53:43
>>343
漏れの経験上、余程単純なシステムでない限り、
下手に修正を入れると、ドつぼにはまると思ひまふ。
触らぬ神にたたり無しです。
350:仕様書無しさん
07/02/22 17:03:45
技術者としては綺麗さっぱり修正したいが、ワーカーとしてはそんな金にならねえ癖に大変な事はやってる暇ねえと言う現実だ
351:仕様書無しさん
07/02/22 18:03:31
そういう意味ではハードコードは色々便利だなw
352:仕様書無しさん
07/02/22 18:08:02
>>351
どういう意味だw
353:仕様書無しさん
07/02/22 18:56:12
言ってみたかったw
354:仕様書無しさん
07/02/23 01:23:29
ハードコーディングをSQLServerで
パラメータ部分を ' を '' に変換してたら
SQLインジェクションなんて全然関係ない
ハードコーディング万歳
355:仕様書無しさん
07/02/23 07:31:33
エスキューエルハードコーディング
相手は死ぬ
356:仕様書無しさん
07/02/23 07:34:02
ハードコーディング自体を嫌うのは、
コンパイラーが死ぬほど、遅かった時代の爺だけだと思われ。
357:仕様書無しさん
07/02/23 07:40:07
インデックス張るの忘れてたw
特に何も言われないので、バージョンアップのたびに小出しにしてやろう。
358:仕様書無しさん
07/02/23 08:18:36
SQL外出しのなにが嬉しいのかさっぱりわかんね。
中出しで十分。
359:仕様書無しさん
07/02/23 08:56:58
ビジュアル的には外出しの方が萌えね？
360:仕様書無しさん
07/02/23 11:14:40
中出しの方が自然だろ
361:仕様書無しさん
07/02/23 14:23:41
>>5
外に出しても大差ないだろ
362:仕様書無しさん
07/02/23 14:51:17
ちゃんとつけないとな。
363:仕様書無しさん
07/02/23 15:03:05
いい流れですね
364:仕様書無しさん
07/02/23 17:26:49
市販のプロテクトを信用してると
穴が開いてることがあるぞ。
365:仕様書無しさん
07/02/23 17:53:44
お前ら、中出しだの外出しだの穴だのいい加減にしろよ
366:仕様書無しさん
07/02/23 18:18:35
要するに、>>365はお口に出して欲しい。ということだな？
367:仕様書無しさん
07/02/23 19:27:58
>>343
これ見て思い出したんだが、昔、とんでもないシステムの改修させられたな。
当時アクセス２０００がすでに主流の時代にアクセス２．０だかなんだかで作られた
システム（そのこと自体は別にいいんだが）で、
なんか日付がずれるっつーからソースを見てみたら、
全ての月が３１日である、という前提でソースが書かれていた。
そりゃお前、１月や３月はいいが、２月や４月になるとズレるわな。
その他いろいろなバグ、バグ、バグ・・・
こんなもんどう考えても修正不可ってんで、結局その改修はウヤムヤになった。
368:仕様書無しさん
07/02/23 21:42:24
>>367
似たようなので、「全ての年は月曜から始まる」って前提のソースがあったw
369:仕様書無しさん
07/02/23 22:57:33
なんつーか、単なるアホなんじゃなかろうか
370:葉猫 ◆Jz.SaKuRaM
07/02/23 23:51:53
SQLだと曜日や日にちの計算が楽でいいけど、ここはあえてZellarの公式で曜日を求めてみるテスト
371:仕様書無しさん
07/02/24 00:04:02
何のDBか忘れちゃったけどさ、
CとかC＋＋のソースに直にSQL書いて
独自のプリプロセッサで変換するやつがあったな。
struct hoge h;
SQLBEGIN
h = SELECT COL1,COL2,COL3 FROM Table1
SQLEND
見たいな。
展開すると普通にAPI+SQL文字列なソースになるだけだけどな。
なんか糞懐かしくって泣けて来たよ。
372:仕様書無しさん
07/02/24 00:11:12
Pro*Cには似てないな
373:仕様書無しさん
07/02/24 10:31:51
何が嫌ってPro*C嫌いだなぁ。
374:仕様書無しさん
07/02/24 10:37:32
Javaがある今、Pro*Cの存在意義ってないな
375:仕様書無しさん
07/02/24 14:50:23
>>367
それ、SQL関係なくねw？
376:仕様書無しさん
07/02/24 16:18:53
Javaさえあれば何もいらない人は思考が停止してるよね
377:仕様書無しさん
07/02/24 16:23:21
Pro*C/C++ は C に埋め込むにはいいんだが
C++ に埋め込むととたんにがっかりするからな。
>>376
Java厨の知能レベルじゃそんなもんだろう。
ところで Pro*COBOL の存在意義（ｒｙ
378:仕様書無しさん
07/02/24 20:11:46
プロジェクトでﾊｲﾊﾞﾈ使おうということになったらしいが、使える人がいないらしい
379:仕様書無しさん
07/02/24 20:17:17
ハイバネなんて使っていいことないよ
380:仕様書無しさん
07/02/24 20:21:02
上の方で大絶賛してる奴がいるぞ
381:仕様書無しさん
07/02/24 20:26:21
メリット・デメリット・向き・不向きをわかって
総合的判断で取り入れるのならいいけどね。＞ハイバネ
無条件で大絶賛とか、使える人もいないのにとりあえず使ってみようでは
いいことがあるわけない。
382:仕様書無しさん
07/02/24 20:36:25
lazyロードとかトランザクションとか
気を使うとこが、かえって増えるから
個人的にはハイバネは、嫌いだな。
PJ内に詳しい人がいれば別なのかもしれんが。
383:仕様書無しさん
07/02/24 21:46:12
>>382
>PJ内に詳しい人がいれば別なのかもしれんが。
黒船願望ｷﾀ━━(ﾟ∀ﾟ)━━ !!!!!
384:仕様書無しさん
07/02/24 21:54:05
C/C++ならだまってOCI
385:仕様書無しさん
07/02/26 21:35:42
データ検索機能を実装するときみんなどうしてるのかな。
データの持ち方にもよるんだろうけど、俺は（というかプロジェクトでは）
SQLを動的に生成して投げてしまう。
386:仕様書無しさん
07/02/26 21:50:24
それ以外に方法が？
387:仕様書無しさん
07/02/26 22:25:15
入力された検索条件をテーブルにいったん落として、
それをSelectで拾ってさらにSelect。全検索のログも残って便利。
388:仕様書無しさん
07/02/26 22:41:56
言語、データ量、やりたい処理にもよるんでないの。
複雑なら、ストアドでカーソルとってループしたり。
389:仕様書無しさん
07/02/26 22:53:27
先生！
動的な生成はハードコーディングに入りますか？
390:仕様書無しさん
07/02/26 23:25:43
動的ってダイナミック？
オンザフライ？
391:仕様書無しさん
07/02/26 23:32:54
動物的
392:仕様書無しさん
07/02/26 23:58:26
RDB使う以上Javaよりも低レイヤの言語使ってもあんま意味無いよね。
いくら頑張ってもけっきょくDBのボトルネックが問題になるし。
393:仕様書無しさん
07/02/27 01:16:12
RDB使う以上どんな言語使ってもDBのボトルネックが問題になるし。
あれ？
394:仕様書無しさん
07/02/27 20:53:19
Java使う以上JavaVMがボトルネックになるよね＾＾
395:仕様書無しさん
07/02/27 22:41:30
それいじょうにRDBのボトルネックがでかいって言ってるんじゃねぇの？
396:仕様書無しさん
07/02/27 22:54:00
いくらがんばってもRDBがボトルネックになるんだったらJava使っても使わなくても変わんないんじゃ・・・
397:仕様書無しさん
07/02/27 23:28:17
Java言いたいだけかと
398:仕様書無しさん
07/02/28 00:20:03
つまり、RubyとかPHPとかJavaとか、実行速度が遅い言語でもいいって事じゃね？
Cとか実装に時間がかかる＆ナーバスな言語にこだわる必要は無いって事を言いたいんだと思われ。
399:仕様書無しさん
07/02/28 00:26:48
どうでもいいけどサーバサイドのJavaは全く遅くないどころか、
スケーラビリティとか考えたら現時点では最速だろ。
400:仕様書無しさん
07/02/28 00:36:24
スケーラビティ考えてSQLハードコード
401:仕様書無しさん
07/02/28 01:24:06
JVM立ち上がってれば速いよな
402:仕様書無しさん
07/02/28 01:58:41
>>399
スケールできるだけで最速ではないと思う。
スケールの容易さではLAMPにも迫られてるような気もするし。
403:仕様書無しさん
07/02/28 02:52:19
このスレは、スケールよりも保守性の方の話題なわけだが
404:仕様書無しさん
07/02/28 06:41:21
PHPって結構早いような希ガス
405:仕様書無しさん
07/02/28 08:45:08
>>404
保守性が落ちていくのがな．
マイナーバージョンアップで言語仕様が大幅に変わるのは病めていただきたい．
406:仕様書無しさん
07/02/28 09:54:22
本当に良いモノってのは、変える必要は無いんだよ。
407:仕様書無しさん
07/02/28 10:03:58
Java厨に言えよ
408:仕様書無しさん
07/02/28 19:59:55
確かに単体ではJavaのほうが速い。
しかし、今のところ重厚長大なJavaで作りこんで単体で高速なものを目指すより、
PHPやPerlでさっくり作って、パフォーマンスはロードバランサで稼ぐほうが、
コストも安いし保守も楽。
409:仕様書無しさん
07/02/28 20:00:38
パフォーマンスもあがる。Javaに勝ち目は無いよ。
410:仕様書無しさん
07/02/28 20:05:35
保守楽か？
411:仕様書無しさん
07/02/28 20:47:16
>>408
変態ｗﾊｹｰﾝ
412:仕様書無しさん
07/02/28 21:52:03
PHPは、知らんがPerlの保守は、地獄の悪寒がするよ。
413:仕様書無しさん
07/02/28 21:59:15
言語の違いによる保守性の話はスレちがいだということを理解できない輩がいますね
414:仕様書無しさん
07/02/28 22:01:10
この場合の保守性というのは、少ないJava鯖より大量のPHP/Perl鯖のほうが
再起動などメンテナンスしやすいという意味では
415:仕様書無しさん
07/02/28 22:02:14
PHPはパッケージを使うとORマッパーぽいことも出来るみたいだけどなー。
416:仕様書無しさん
07/02/28 22:33:02
PHPがサックリあたりまでは解るが保守楽かぁ？
仕事だとIBMのIDE(WDSc:Eclipesの商用Ver))使ってるけど、
PHPよりもJavaの方があきらかにサックリ作れるぞ。
それに要件が決まっているなら作りこむ量は一緒だろ。
417:仕様書無しさん
07/02/28 22:36:50
Javaじゃ大量の鯖を導入できないじゃん。WebLogic高くて。
418:仕様書無しさん
07/02/28 22:40:29
Javaとかどうでもいいんだよ
ハードコーディングすること自体はどうなのよ
419:仕様書無しさん
07/02/28 22:43:58
んだ。誰かJava vs LAMPのスレ立ててそっちでやれや
420:仕様書無しさん
07/02/28 22:44:11
ハードコーディングするかしないかは大した問題ではない。
421:仕様書無しさん
07/02/28 22:45:54
>>420
これは上司の一言スレのネタですね
422:仕様書無しさん
07/02/28 23:18:52
ハードコーティングが悪か？って言われてもケースバイケースだろ。
たとえば、ホストがOracleでクライアントがAccessの時に
AccessからSQL投げるのと、Oracleでストアドとどっちかマシか？って話なのか？
423:仕様書無しさん
07/02/28 23:23:34
>>422
それじゃマシも何も、用途が違うじゃねえか
424:仕様書無しさん
07/02/28 23:45:13
Javascriptの保守の方が大変じゃね？
425:仕様書無しさん
07/02/28 23:46:14
ストアドのほうが開発者側の意識として緊張感が違うと思うｗ
感覚的なものだけど
426:仕様書無しさん
07/03/01 00:02:11
400以上のレスをロールバックw
427:仕様書無しさん
07/03/01 00:04:03
>>423
いや、この場合だと用途は同じでOracleにあるデータを
集計してAccessに取り込むって目的だが、
AccessからVBA(ADO)でSQL投げて結果を受け取るか、
ADOでストアド呼ぶか？の違いがあるだけだが。
漏れが提案する以前は、Oracleから全明細読み込んで
Accessで集計していた。
SQLを一切使わないOracleで不思議と感動した。ｗ
428:仕様書無しさん
07/03/01 00:16:17
ケースバイケースは魔法の言葉
429:仕様書無しさん
07/03/01 01:17:01
>>427
そーゆーショボイ用途で使われてるDB鯖に限ってスッペクを奢ってたりするから不思議。
430:仕様書無しさん
07/03/01 02:10:00
わかった！！
１は最近、『ハードコーディング』って言葉を覚えたんだな ｗ
431:仕様書無しさん
07/03/01 06:47:49
>>429
正直Oracleはいらん罠。
まあ、元ネタはCOBOLer上がりのヤツが提案したので、
各所でグダグダな設計だった。
データの更新はSQLを一切使わずにCOBOLとロードモジュール？（謎モジュール）
だけで実現していたので、ある意味ここの>>1が喜びそうなシステムではあるな。
漏れは最悪だと思ったが。w
432:仕様書無しさん
07/03/01 09:42:01
>>429
毎回全件取得だと高速なディスクと大量のメモリがないと
まともに使えるようなレスポンスが得られないからなｗｗｗ
433:仕様書無しさん
07/03/01 10:10:21
ストアド知らんだけだろ
434:仕様書無しさん
07/03/01 10:59:17
俺のチンコがソフトコーティングされてます
435:仕様書無しさん
07/03/01 12:32:20
>>434 仕事はいいから包茎手術に逝け。な？
436:仕様書無しさん
07/03/01 13:47:17
しかし、ストアドを乱用する奴もいるよね。
437:仕様書無しさん
07/03/01 15:54:39
>>436
マスタで一覧取得とか1件更新すらも、とにかくDBアクセスストアドっていう
ストアダーに出会ったことがある。
俺の中では、集計とか重い処理なんかの時にストアド使っていくもんだと思ってたんだが･･
他の皆の意見はどうなのよ？
438:仕様書無しさん
07/03/01 16:09:24
重い処理をDBにやらせるのはどうかと思う。
439:仕様書無しさん
07/03/01 16:10:31
>>437
・WebとWin32クライアントが混在や並行稼働している（別々の言語からアクセスする可能性がある）
・ストアドのドキュメントがきっちり分類されて管理されている
ならば可能な限りストアドにしてしまった方がいい場合がある。と思う。
440:仕様書無しさん
07/03/01 19:59:59
ストアドもいろいろな効用があるからなぁ。
あからさまに長い時間がかかる処理はストアドだろうし、
かなり複雑な処理もストアドだろうなぁ。
ただ、DB2とかだとテーブルの統計情報を元にアクセスプランを
組み立てるタイプのだとある程度実務をこなしてから
ストアドにしないと、最適化に無駄が出る気がするので、
最初にいきなりストアド作ってほったらかしはアレかもしれん。
いまどきは人間の最適化よりもRDBMSのオプティマイザーの方が賢いし。
COBOLerがCOBOLでコーティングしたり妙なストアド組むよりも
素直なSQLを投げた方がRDBの性能引き出せる場合もある。
441:仕様書無しさん
07/03/01 20:06:09
>>427
いいなぁ。VPNで運用する要望が出たらリプレースで丸儲けだぜｗ
442:仕様書無しさん
07/03/01 20:22:48
無意味に妙に一貫性のある開発スタイルを採用しているものの方が、
機能追加や保守の際にはまることが多い。
トリッキーなコードをさらにトリッキーにすることで維持するくらいなら
掟を破っても良いんじゃないかと思うオレは若すぎますか？
443:仕様書無しさん
07/03/01 21:44:15
>>442
具体的になんなんだ？
Javaとかでｲﾝﾀｰﾌｪｲｽや継承しまくったクラス設計をﾄﾘｯｷｰに感じてを保守しにくい、とか
VBで１メソッドを何十行もダラダラと長く記述するのを保守しやすい、とか
言うなら、藻前は若いんじゃなくて爺だと思うけど。
444:仕様書無しさん
07/03/01 21:50:14
SQL文をハードコーディングするやつはとっとと引越しー
445:仕様書無しさん
07/03/02 00:37:30
>>437
ストアダーになってみたことはある。
Update系は意外と楽できる。
446:仕様書無しさん
07/03/02 02:27:54
俺の経験だと、コードに対する名前を他のテーブルから引っ張ってくるような部分も
結構、ストアドにすると良い感じだったな。Joinより見やすいし
外部結合時が必要な時も、パフォーマンスが出たように記憶している。
447:仕様書無しさん
07/03/02 15:39:11
隊長！Hibernateとかいろいろ使った結果、1周してJDBCに帰ってまいりました。
448:仕様書無しさん
07/03/02 15:54:15
JSP+Servlet+JDBC最強だよな
449:仕様書無しさん
07/03/02 16:09:56
>>448
あまりに強すぎて、討ち死に続出。
450:仕様書無しさん
07/03/02 17:16:12
JSPよりServletの方がいいだろ
451:仕様書無しさん
07/03/02 20:23:14
詳細テーブルと親テーブルのレコードが1:nの奴にupdateするときとか便利だよね＜ストアド
452:仕様書無しさん
07/03/03 00:05:23
>>448-450
これだからJava厨はきらいなんだ。。。
453:仕様書無しさん
07/03/03 00:11:30
>>452
ごめんな。。
454:仕様書無しさん
07/03/03 00:14:58
>>453
あ、いや、こっちこそ。。
455:仕様書無しさん
07/03/04 00:33:01
ストアドは賛否両論あるとして、
トリガって実務で使ってるか？
俺が趣味でやってる会員制サイト（エロではない）（SQLServer2005）作るときに、
「そういや実務でトリガって使ったこと無いな」と思って、試しに
トリガ使ってみたら便利だった。
退会処理はマスターの該当ID消すだけで、他のテーブルに持ってる
そいつのレコードが全消しとか。
456:仕様書無しさん
07/03/04 00:41:50
>>455
つ 参照整合性
457:仕様書無しさん
07/03/04 02:12:14
>>455
使う。便利だ。似たような用途だ。
例えば、新規取引先を登録したときなど。
問題は、あんまり知っている奴が多くないので、メンテで苦労することか。
458:仕様書無しさん
07/03/04 08:24:09
>>455
別アプリと連携させるときに使うよ。
マスタ情報が更新されたら渡す、みたいな。
削除は削除フラグ立てることが多いな。
場合によるけど。
459:仕様書無しさん
07/03/04 10:39:24
>>455
俺の経験ではトリガ使わずに、アプリ側で制御するね。
理由は不明。なんでだろうね。
460:仕様書無しさん
07/03/04 10:57:00
>>459
トリガは便利だが、使い方を間違えると収拾付かなくなるし、
ケースバイ・ケースだろうな。
基本の味付けはアプリでして、調味料的にトリガにすると丁度よい。
しかし、アプリで行うとハードコーディングという問題が発生し、スレタイへ戻る。
461:仕様書無しさん
07/03/04 12:33:12
トリガからストアドを呼び出してスパゲッティ
462:仕様書無しさん
07/03/04 18:17:00
極力ルールはアプリ側に置きたいので使わない
463:仕様書無しさん
07/03/04 19:44:14
ロジックの分離イクナイ
464:仕様書無しさん
07/03/04 20:32:17
トリガは便利だけど、知っている奴が少ないのが難点だな。
(DB2/400は)テーブルをコピーしてもトリガはコピーされないって点を
忘れると悲劇が待ってるし、仕方ないと思うが更新処理のパフォーマンスが
落ちる場合もあるので、使う時は気をつけている。
ロジックの分離と言うかさりげなくアクセスログを取っているって
使い方が多いな。
「このフィールドを更新したの誰だよ？」って感じで。
465:仕様書無しさん
07/03/04 21:41:42
SQLのハードコード云々よりも
・ストアド禁止
・ビュー禁止
・トリガー禁止
のルールを徹底させようとするPM/SEのほうが先に氏んでくれと思う。
466:仕様書無しさん
07/03/04 21:49:15
ビューとトリガーは禁止でいいよ
467:仕様書無しさん
07/03/04 22:01:33
ビューは、遅くて使い物にならん。
468:仕様書無しさん
07/03/04 22:01:38
＞「このフィールドを更新したの誰だよ？」って感じで。
あるあるｗ
馬鹿ユーザが「いじってない！」とか抜かしたときに
本当かどうか調べられるし
469:仕様書無しさん
07/03/04 22:14:55
テンポラリテーブルはありでつか？
470:仕様書無しさん
07/03/04 23:39:56
通常SQL部分はクラスでラップするから、ハードコーディングでいいんでは？
場合によってストアドも使うし、トリガは注意して使えば問題ないし、
ビューもテーブル設計の変更ができない時に仕方なく使う分にはいいんじゃない？
471:仕様書無しさん
07/03/05 00:23:02
>>465
ルールを徹底させるだけマシだとおもう。
好きに使っていいよってプロジェクトの悲惨さに比べたら・・・
472:仕様書無しさん
07/03/05 00:30:12
そうだな。駄目なら駄目としてくれたほうがすっきりする。
473:仕様書無しさん
07/03/05 00:56:19
トリガーは微妙なんだが、ストアドやビューを好きに使われると
ナニか困るのか？
逆説っぽくてアレなんだが、困るストアドを作るやつは
ストアド禁止にしても困るコーティングすると思う。
ビューも同様な。
474:仕様書無しさん
07/03/05 08:17:50
>>467
それはアンタのSQLが悪いだけｗｗｗ
>>473
同意
475:仕様書無しさん
07/03/05 08:27:20
駄目な奴は何をやっても駄目．
最低限，SQLをプログラムの各所に散らばらすのは止めて欲しい．
前に見た奴だと，ボタン押下イベントの中でSQL投げてたのを見たことある．
476:仕様書無しさん
07/03/05 08:42:19
え？普通じゃね？
477:仕様書無しさん
07/03/05 09:02:29
ボタンを押下した後にＤＢ検索にいくなら、
嫌でもSQL投げないと、何も始まらないよな。
478:仕様書無しさん
07/03/05 09:03:02
>>473
人単体で見れば確かにそのとおり。
ただ、全体で見たときに非常に美しくなくなるんだよね。
極端な話、マスタ登録はストアド側でマスタ更新はプログラム側ってこともありうるのよ。
同じレイヤーのロジックをストアドで組んだりプログラムで組んだりっていうのは
アーキテクチャとして正しい姿なのか？っていうのは疑問。
>>476
え？
イベントハンドラとロジックはわけようぜ兄弟
479:仕様書無しさん
07/03/05 09:18:23
VBの簡単な画面でそれやられると萎える
480:仕様書無しさん
07/03/05 09:18:52
たかがVBだからな
481:仕様書無しさん
07/03/05 10:47:56
>>475>>479-480
VB入門書にそういう記述をしている本がけっこうあるからなのさ。
482:仕様書無しさん
07/03/05 11:05:18
VB厨がプログラムを分割しようとすると妙に不自然な形になるからなぁ。
長大なイベントハンドラを許容しておいたほうが無難かもしれん。
483:仕様書無しさん
07/03/05 11:48:56
>>466
うそを言うな、ウソを。
484:仕様書無しさん
07/03/05 12:27:10
>>482
モジュールに関数書いて、呼び出すようにしても、クラス化しろよ低脳とか言われちゃうしな
485:仕様書無しさん
07/03/05 12:31:12
>>474
ビューにインデックスを張れない以上、
ビューの遅さは、どうしようもないと思うけど。
486:仕様書無しさん
07/03/05 12:36:52
ビューと通常のSELECTだとビューが遅いというのは、どこで遅くなっているんだろうか
487:仕様書無しさん
07/03/05 12:38:06
>>484
Foo formに1:1で対応するFoo logicクラスを作ってそこに全ての処理を延々書き連ねたコードなら見た。
イベントハンドラでは、そのlogicクラスのインスタンスを生成して、イベントハンドラに対応する長大なひとつのメソッドを呼ぶ。
アホかと。
488:仕様書無しさん
07/03/05 12:51:19
>>486
出来上がったビューにインデックスが張れないから遅いんだよ。
489:仕様書無しさん
07/03/05 12:55:59
>>488
別のビュー作ればいいじゃん
490:仕様書無しさん
07/03/05 13:11:22
>>489
え？
491:仕様書無しさん
07/03/05 13:12:29
>>488
じゃないけど
ちょっとそれ教えて欲しいと思った
今までDataSetで取り込んだりした後自分でPk設定してたりしてるんで
元々ViewにKeyを埋め込めるのならそうしたい
492:仕様書無しさん
07/03/05 13:14:29
ビューが実態のあるオブジェクトなDBもあるのか？
普通はテーブルを参照するオブジェクトだと思うが。
参照の仕方をユーザー毎に区切ったりする場合に使うのでは。
493:仕様書無しさん
07/03/05 13:21:18
ビューの元になるテーブルに適切なインデックスが張られていれば
ビューもそんなに問題にならないと思うけど
もしかしてjoinの代わりにビュー使ってるの？
494:仕様書無しさん
07/03/05 13:33:06
ビューにインデックス貼るって、用途無視してビュー作ってるだけじゃんw
ビューって言いたいだけだろ
495:仕様書無しさん
07/03/05 13:54:05
早い遅いはDB板で。
O/Rマッパーマンセーとかそういうレス希望
496:仕様書無しさん
07/03/05 15:17:42
>>488
実行計画とって、きちんとINDEXが使われるようなVIEWにしろｗｗｗ
つか、元表にちゃんとINDEX作れｗｗｗ
>>492
Oracleなんかじゃマテリアライズドビューなんていう
実データを持つVIEWのようなものは存在する。
>>493
正解。
497:仕様書無しさん
07/03/05 19:41:07
>>478
＞極端な話、マスタ登録はストアド側でマスタ更新はプログラム側ってこともありうるのよ。
＞同じレイヤーのロジックをストアドで組んだりプログラムで組んだりっていうのは
＞アーキテクチャとして正しい姿なのか？っていうのは疑問。
そういう美しさを追求したいのなら、システムを設計する際に
アクセス権を含めてかなりカッキリと設計しておけ、って気がするが。
マスタ更新系に関してはストアドを作成し、そのオブジェクトに管理者のOWNER
権限がないとINSERTできない。とかな。
逆に参照はすべてDBAが用意したビューのみしか利用できないとかか。
素人プログラマにビュー作られてパフォーマンスが出ないとか言うなら
餅は餅屋な感じでプロのDBAのテーブル設計してもらって最適な
KEY,INDEX,VIEW,制約をやってもらう。
498:仕様書無しさん
07/03/05 21:28:16
>>496
当然元表のＩＮＤＥＸは、使われているが
話にならんぐらい遅いよ。
499:仕様書無しさん
07/03/05 21:31:19
こういう
URLﾘﾝｸ(www.geocities.jp)
ページもあるから、Ｖｉｅｗは、遅いって言うのも一般的な話だと思う。
500:仕様書無しさん
07/03/05 21:48:46
>>498
VIEWでなく、普通にSELECTした方が速いのかい？
501:仕様書無しさん
07/03/05 21:52:21
>>500
絞込み順番で速度が変わるのでViewだと遅くなることが多い。
502:仕様書無しさん
07/03/05 22:07:54
DB2でJDBC経由で使う分にはVIEWとSELECTとの違いは体感しないけどなー。
マイクロソフトのOSからODBC経由でSQL投げると不思議と遅くなる事が
あるけど、なんなんだろうな。
SQLServer買えｔって嫌がらせなんだろうか？って思う事がある。
まあ漏れはSELECTかMQTのどっちかの人だけど。
503:仕様書無しさん
07/03/05 22:08:52
>>500
インデックスが張ってあるカラムで検索するなら、
圧倒的に実表を使ったほうが早い。
504:仕様書無しさん
07/03/05 22:12:28
ところで具体的にVIEW使うと遅くなるRDBってナニ？
>>502と同様にDB2だと、ﾃｰﾌﾞﾙでも、ビューでもﾏﾃﾘｱﾗｲｽﾞでも
どれも同じ速度で結果が返ってくるけど。
505:仕様書無しさん
07/03/05 22:15:44
>>504
Ｏｒａｃｌｅだよ。
>DB2だと、ﾃｰﾌﾞﾙでも、ビューでもﾏﾃﾘｱﾗｲｽﾞでも
>どれも同じ速度で結果が返ってくるけど。
ソース希望。
506:仕様書無しさん
07/03/05 22:22:20
>>505
ソースもなにもやって見れば解る。
適当なテーブルにビューを作成して、ついでにマテリアライズしておくと、
実テーブルとビューでマテリアライズな結果を帰ってくるような設定にしていおけば、
DB2のオプティマイザがマテリアライズの結果を返すので、
どのオブジェクトを参照しても9msくらいの早さで結果が返ってくる。
さすがは商用DBといったトコか。
Oracleに向かってこういう事いうと反論が山ほど返ってくるだろうけど、
Oracleは使う側がOracleを熟知していないとパフォーマンスでないよな。
507:仕様書無しさん
07/03/05 22:24:27
ハードコードしてそうな人が多そうだから、そっちに話を戻そうか
508:仕様書無しさん
07/03/05 22:49:33
ま、ストアド作ってもそいつを呼び出すもんはどうするのかってこともあるしね。
509:仕様書無しさん
07/03/05 22:55:53
Oracleのせいにしたいやつがいるな。
510:仕様書無しさん
07/03/05 23:03:33
別にハードコートが悪とも思えんけどなぁ。
たとえば以下みたいなSQLを直書きする方が
select DATE(a.yyyy || '-' || a.mm || '-' || a.dd ) from hoge as a, piyo as b
where ここらが動的生成
group by .....
having 動的生成
だとロジックを集中して短く作りこめるし。
そりゃ、select * from hogeみたいなハードコートは市ねとか思うけど。
511:仕様書無しさん
07/03/05 23:05:39
ビューで集約操作をすれば遅くなる、って言ってるだけじゃん
ビューは遅い、なんて言い切るなよボケ
512:仕様書無しさん
07/03/05 23:08:04
>>510
動的生成するにはハードコードだわな。
513:仕様書無しさん
07/03/05 23:08:22
|| '-' ||
新しい顔文字かと思った
514:仕様書無しさん
07/03/05 23:19:02
|| '-' ||
（。Ｙ。）
515:仕様書無しさん
07/03/05 23:20:58
>>514
女神様じゃ～
516:仕様書無しさん
07/03/05 23:34:48
|| '-' ||
（。Ｙ。）ノ
肉
517:仕様書無しさん
07/03/06 07:57:35
>>506
それ偶然だから。
518:仕様書無しさん
07/03/06 09:05:33
ハードコーディングの定義って何？
where句の条件が動的に変化して
それ以外のselect句が固定であったとき、
where句以外をソースに書いておくのがハードコーディング？
519:仕様書無しさん
07/03/06 09:53:21
>>518
ソースコードの中にSQLを直書きすること。
520:仕様書無しさん
07/03/06 12:31:53
それの何が問題なの？
521:仕様書無しさん
07/03/06 12:58:47
常に同一のSQLなら生SQLでいいけど、そうでもないのに
プレースホルダも使わずに
"select * from hoge where " + condition + ";"
なんて書いてるこわーいコードが世の中には溢れかえっている。
522:仕様書無しさん
07/03/06 12:59:04
変更の度にコンパイル
523:仕様書無しさん
07/03/06 13:42:09
>>521
ハードコーディング以前の問題。
>>522
今時、コンパイルに何時間もかかるわけじゃなし。
問題無いと思うが。
524:仕様書無しさん
07/03/06 17:39:02
数値のリテラルよりマシ。
525:仕様書無しさん
07/03/06 21:31:10
>>521見て思ったんだが、上の方で出てるHibernateとかはこの問題は発生しないの？
使ったことないんでよくわからん
526:仕様書無しさん
07/03/06 21:35:37
>>525
Hibernate関係ねー。よっぽど使い方まちがえたらSQLインジェクション発生する。
527:仕様書無しさん
07/03/06 22:39:42
>>526
やっぱりそうだよね。ありがとう。
528:仕様書無しさん
07/03/22 21:09:04
保守
529:仕様書無しさん
07/03/30 21:52:17
保守
530:仕様書無しさん
07/03/31 00:10:44
>>524
同じ意味のconstが複数あった時にゃ、リテラルの方がマシと思った
531:仕様書無しさん
07/04/02 22:12:30
プリペアドステートメントってどうよ
532:仕様書無しさん
07/04/03 12:45:58
O/Rマッパーでも使えというのか？
SQLを書いた方が早い場合もあるんじゃないか？
533:仕様書無しさん
07/04/03 13:07:08
オラクルはわからんけどSAP R/3は内部でSQLをハードコーディング
してるのをよく見かけるぞ。
534:仕様書無しさん
07/04/03 16:07:16
SAPだったら別に良いんじゃないかという希ガス
535:仕様書無しさん
07/06/11 20:42:07
>>1
SQLインジェクションとかそういうことを危惧しての発言なのか、それとも単にリテラル文字列が気に入らないだけ？
後者ならお前はただのアホとしか言いようが無いぞ。
536:仕様書無しさん
07/06/11 20:43:22
あーハードコーディングとか言ってるから後者だな。
１は馬鹿丸出し。
537:69式フリーPG ◆hND3Lufios
07/06/11 20:50:53
プレースホルダを埋めた形でハードコーディングしてますが。
設定ファイルとかに外出ししてもさ、コンパイルせずに済むのってORDER BYとか
だけじゃん？
538:仕様書無しさん
07/06/11 21:01:46
Java界では保守性があがると言うもっぱらの噂ですよ。馬鹿っぽい気もするけどさ。
539:仕様書無しさん
07/06/11 21:07:25
コードとSQL文の距離が離れることで、可読性が落ち保守性が落ちる。
540:仕様書無しさん
07/06/11 22:19:02
S2Dao最強でOK
541:仕様書無しさん
07/06/17 16:09:59
ハードコーディングしたほうがSQLインジェクションには強い
542:仕様書無しさん
07/06/17 17:38:27
じゃあS2Dao Tigerでいいや
543:仕様書無しさん
07/06/20 22:09:17
>>541
検索条件を変えられないなら、ハードコーディングしようがしまいが
SQLインジェクションには無敵
544:仕様書無しさん
07/06/20 23:43:29
それは、ともかくSQLExceptionの変数をsexにしてるソースがあってさ
なんか、楽しいから、やめてほしいなぁと思うわけよ。
545:仕様書無しさん
07/06/20 23:49:22
ﾜﾗﾀ
546:仕様書無しさん
07/06/22 22:57:10
SQLインジェクション云々いってるやつって何なの？
それに対策立てた上での議論だろ？
547:仕様書無しさん
07/06/22 23:09:47
VBのソースって半分以上がSQLだよね
548:仕様書無しさん
07/06/22 23:23:11
ＸＰ的にはハードコーディングだな
困ってから作り直せばいいだろ。どうせ困る前に納期だ。
549:仕様書無しさん
07/06/22 23:25:11
ハードコーディングじゃない方法ってどんなの？
550:仕様書無しさん
07/06/23 00:03:22
XPなら重複コード禁止だろ
重複コード無しでSQLハードコーディングは無理だな。不可能。
551:仕様書無しさん
07/06/23 00:07:08
"SELECT *" を使いまくればSQLなんて楽勝!
552:仕様書無しさん
07/06/23 00:14:16
コボラ乙
553:仕様書無しさん
07/06/23 00:17:48
>>５５０
何処が重複になるのか詳しく説明プリーズ
554:仕様書無しさん
07/06/23 00:41:05
柔軟性がどうこう言うﾔﾂに限って再利用可能なものをつくらないよなｗ
555:仕様書無しさん
07/06/24 12:54:09
SQLはハードコーディングでいい。
外出しにしても再利用などできない。
いやならO/Rマッピング使う。
556:仕様書無しさん
07/06/24 13:29:24
O/Rマッピングで美しく解決できるのなんて
チューニングの不要なやり逃げ案件だけ
557:仕様書無しさん
07/06/24 14:36:13
Webアプリの糞つまんねーCRUD部分にだけ適用するのが正解。
558:仕様書無しさん
07/10/04 20:25:35
hhddf
jfghhgh
tyyrtr
werwerwer
utuytu
559:仕様書無しさん
07/11/15 01:49:11
SQL が変わる時ってロジックも変わってることが多いんで、
SQL だけ外に出しても意味なくない?
SQL を自動生成してるんなら別だけど。
560:仕様書無しさん
07/11/16 00:49:22
>>559
それどころか予期せぬ障害を引き起こしたりもする．
ウチのアホSEがSQLを変更するのは設定ファイル変更で，
プログラムの変更は入りませんから，再テストの必要は無いですね，
って言って見事にバグらせたことがある．
っつーか事前検証くらいしろよっていう話なんだけどさ．
561:仕様書無しさん
07/11/16 23:19:41
htmlをロジックと分離するのは、それがデザインであるという以外に
定数として埋め込む手間とかいろいろあるんだよな。
SQLだと後者のメリットしかないんだけど、俺は外出しがいい。
>>559
Where句だけ変わる事って結構あると思うけど。
特に集計するときとか。
自動生成はまた別の問題を抱えていて、条件によって構文すら異なる。
レアケースでだけ構文エラーを起こしたり、解釈が変わってしまうのがいやになったよ。
まるで、Cのマクロで意図しない式に展開されてるときと同じ感覚。
>>560
それはリファクタリングがなってないだけだよな。
変更前後のSQLを差し引きしたら、どこが違うかなんて一発でわかるのに。
562:仕様書無しさん
07/12/07 22:17:12
>>561
何が言いたいのか全くわからん
563:仕様書無しさん
07/12/18 22:31:47
半端な気持ちで外出しするとメンテではまる。
どのプログラムから
どのタイミングでどのテーブルのどのフィールドを
どのSQLを使って参照・更新するのかが、チームで共有されていて
ちゃんと管理されていて、調べやすければメリットがあるけど、
ずさんな場合は依存関係を調べるのに結局ソースにあたるハメに陥り
その上、間接的に読まれるせいでソースをGREPしづらいし、数倍面倒になる。
564:仕様書無しさん
07/12/19 01:49:10
せっかく分けたのにちょっとした修正時に結局両方直さなければならないのは悲しい事だ
565:仕様書無しさん
07/12/19 06:52:44
563とか564のスレを読む限り、外出しの推進派と反対派では外出しの方法が違うのでは？と勘ぐってしまう。
564の意見とか的外れもいいとこ。
566:仕様書無しさん
07/12/19 07:11:14
重複、ここでやれ。
ｽﾚﾘﾝｸ(prog板)l50
567:仕様書無しさん
07/12/19 09:46:47
>>565
そう勘ぐったのなら、具体的にどう違うと思ったのか指摘すればいいのに。
568:仕様書無しさん
07/12/19 19:46:57
スレとレスも間違えてるしな
569:葉猫 ◆Jz.SaKuRaM
07/12/20 21:54:00
1000行ﾚﾍﾞﾙのストアドをソースに埋め込む気にはならんな ('A`)ﾏﾝﾄﾞｸｾｰ
570:仕様書無しさん
07/12/20 22:31:40
何言ってんだオメー
さっさと氏ねよ
571:仕様書無しさん
07/12/22 03:15:40
結局、ソースファイルと外出しsqlの両方とも修正しなくといけなくなるだけ。
572:仕様書無しさん
07/12/22 03:17:33
マ板のスキル低下は著しいなｗｗｗｗｗｗｗ
573:仕様書無しさん
07/12/22 13:17:03
java向けのスレなのにC++とかのプログラマが来て些細なテクニック論に
なってるなこのスレ
574:仕様書無しさん
07/12/22 13:43:16
そんな前提>1に書いてないので認めないｸﾏｰ
575:仕様書無しさん
07/12/22 16:00:08
>>283
ちょwwそれうちの病院www
クエリはないけど、リンクテーブルだらけのmdbファイルあったわ。
でも処理はVBじゃないっぽい。
独自にデータ集計したりするときに俺もそこからインポートしてるけど。
576:仕様書無しさん
07/12/22 19:05:06
>>573
＋＋マが全部こんなのだって訳じゃないんだぞといっておく
577:仕様書無しさん
07/12/22 19:49:43
スレの最初のほうを読んで、それ以降はチラ見してただけだから、Javaスレになってたなんて気ずかなかったよ。
578:仕様書無しさん
07/12/22 20:07:09
づ
579:仕様書無しさん
07/12/22 22:09:20
SELECT文とかを変数につっこんでExecuteとかマジやめて欲しいんだけど。
特にWebアプリの場合ね。
ストアドを作ってそれを呼ぶだけにするのば一般的だと思ってたんだけど
そうでもないの？
そういえばカカクコムとか昔攻撃されてたね。
580:仕様書無しさん
07/12/22 22:15:40
>>579
DB側に処理をおくのは・・・って考え方もあるよ
インジェクション対応して無いなんてのはどうやっても問題外
581:仕様書無しさん
07/12/22 23:07:37
hibernateってヒントつけられないから馬鹿だよね。
使い物にならん。
582:仕様書無しさん
07/12/22 23:11:39
> するのば
↑
あまり一般的じゃないと思う
583:仕様書無しさん
07/12/23 00:21:49
Webの開発だったら普通はストアドプロシージャを実行するよ。
LINQなんて論外。
584:仕様書無しさん
07/12/23 00:26:17
>>583
ストアドはないだろ・・・
585:仕様書無しさん
07/12/23 00:35:25
>>584
PROCEDUREというやつの事です。
Accessだとクエリだっけ？
586:仕様書無しさん
07/12/23 00:37:30
SQLをハードコーディングする人って多いのね。
587:仕様書無しさん
07/12/23 00:49:31
インジェクション対策ならプリペアードクエリでいいだろ
588:仕様書無しさん
07/12/23 00:55:00
DBへの処理はDB側で行うのかプログラムに書いちゃうかはプロジェクトによって分かれるね。
今のプロジェクトはDBへの処理は必ずストアドを使うように言われてる。
そもそもプログラムを実行するユーザーにはストアドのGRANT権限しか付与してくんない。
まあどっちでも良いや。
589:仕様書無しさん
07/12/23 00:58:24
DB側に処理もって行ったら不可分散しにくいじゃん
590:葉猫 ◆Jz.SaKuRaM
07/12/23 09:48:57
一時テーブルを使えないとスピードが遅くなるからDB側でちょ (｀･ω･´) ｼｬｷｰﾝ
591:仕様書無しさん
07/12/23 11:10:09
お前マジキメェ
さっさと失せろ
592:仕様書無しさん
07/12/23 17:58:23
どう書くのが推奨なの？
SQL生成用の関数作ってパラメータ放り込むぐらいしか考えつかん
593:仕様書無しさん
07/12/23 18:07:02
ORマッパ
594:仕様書無しさん
07/12/23 22:04:21
今時一次テーブルとかスキル無いコテってなんなの？
595:仕様書無しさん
07/12/23 22:49:36
以前も自らのアホっぷりを晒したレスを論破されて逃走
挙句の果てに火病って糞スレ立てるほどのアホの子ですから
596:仕様書無しさん
07/12/25 00:23:35
なんでも*つければ
良いってもんじゃねーぞ。
597:仕様書無しさん
07/12/25 02:00:35
SQLは全部外だししてたなぁ
↓こんな風にして値を置換してたわ
<sql>
<command>
SELECT * FROM TBL WHERE id = <val1> AND name = <val2>
</command>
<parameters>
<parameter name="val1" value="ID" comment="ID用" />
<parameter name="val2" value="NAME" comment="名前" />
</parameters>
</sql>
parameterタグのnameはcommandタグのSQL先で、valueはプログラムにある変数コードだったな。
SQLはハードコーディングはコンパイルして再起動してその画面行くのが面倒だし普通にやらんかったわ
598:仕様書無しさん
07/12/25 02:20:05
GRANT権限ってなんだ
599:仕様書無しさん
07/12/25 06:22:04
>>598
GRANT文を実行できる権限じゃね？
600:仕様書無しさん
07/12/25 11:01:49
>>597
名前で検索って、それじゃIDの意味ねーよｗ
↑どうでもいいことを言ってみる。
601:仕様書無しさん
07/12/25 23:06:57
>>597
WHEREを画面の入力によって組み立てたりすると
途端に破綻するんだろ？
602:仕様書無しさん
07/12/26 00:48:48
>>599
中間管理職か...
603:仕様書無しさん
07/12/26 00:58:39
>>601
<sql>
<command>
SELECT * FROM TBL WHERE (id = <val1> or <val1> = '') AND (name = <val2> or <val2> = '')
</command>
<parameters>
<parameter name="val1" value="ID" comment="ID用" />
<parameter name="val2" value="NAME" comment="名前" />
</parameters>
</sql>
みたいな涙ぐましい工夫するんじゃないかな
三値論理的には空欄の場合はnullにして
SELECT * FROM TBL WHERE (id = <val1> AND name = <val2>) IS NOT FALSE
のほーがスマートかも知れんがOracleが対応してなかった希瓦斯
604:仕様書無しさん
07/12/26 07:04:29
インジェクションされまくるじゃないか、とかは別にして、
結局ハードコーディングした方がいいじゃん、つ流れになりそうな話だなぁ
605:仕様書無しさん
07/12/26 07:21:19
バカどもがどうしようと構わんが、マ板の質落ちたねぇ・・・
606:仕様書無しさん
07/12/26 21:49:21
>>605
どうしたら上質だんだよ。
607:仕様書無しさん
07/12/26 23:16:54
んだんだ
608:仕様書無しさん
07/12/26 23:35:51
>>606
やっぱブラック、いろんな意味で。
609:仕様書無しさん
07/12/27 00:15:23
>>603
SQL実行する前に値チェックをプログラムでやればいいだろ
610:仕様書無しさん
07/12/27 18:18:24
INSERTする前には必ずSELECTして重複チェックしてください。
611:仕様書無しさん
07/12/27 18:22:31
>>610
それはあまりに間抜けな仕様。
論理的な重複排除はPKかUNIQUE INDEXの一意制約違反で
INSERT時のSQL実行エラーを戻してもらえればいい。
あとはアプリケーションでエラー処理をきちんと実装する。
612:仕様書無しさん
07/12/27 19:18:27
>>610
SELECTとINSERTの間に他のセッションからINSERTされちゃうことってないの?
613:仕様書無しさん
07/12/27 19:40:31
>>611
俺らがSELECTされない間に、あいつはINSERTされてるんだよ、畜生。
614:仕様書無しさん
07/12/27 21:00:42
>>613
俺なんかSELECTされる事が無いまま、そっけなくDELETEされるんだぜ。
615:仕様書無しさん
07/12/28 00:36:29
>>614
お前は一度でもINSERTしたのか！
616:仕様書無しさん
07/12/28 10:25:30
ハードコーディングってなんぞ？
JDBCは組込みSQLはハードコーディングに入ってんのか？
617:仕様書無しさん
07/12/28 12:01:41
SQLを外に出してる奴は、他の言語内言語である正規表現とかも外に出してるのか？
618:仕様書無しさん
07/12/28 12:03:43
spring framework位使いこなしなよ。おじいさん＾＾
619:仕様書無しさん
07/12/28 12:07:49
中出しはらめぇ
620:仕様書無しさん
07/12/29 06:26:03
springとＳＱＬのハードコーディングは、何の関係も無いと思うが・・・
621:仕様書無しさん
07/12/29 17:04:29
ハードコーディング自体は悪くないが、
複数のメソッドで部分部分ＳＱＬ文字列組み立てるのは勘弁してくれ。
622:仕様書無しさん
07/12/30 12:55:40
昔バカスイーツＳＥ女がいて
ソースが汚いとすぐハードコーディングハードコーディング言ってうるさかった
623:仕様書無しさん
07/12/30 13:39:39
>>617
SQLと正規表現だと別もんだと思うんだが・・・
正規表現エンジン変えられるようにしてたりしたら外に出すなぁ
624:仕様書無しさん
07/12/30 20:34:26
ハードコーディング肯定してる奴らってIDE使ってないんじゃないかって気はする
625:仕様書無しさん
07/12/30 21:55:06
何言ってんだ？
626:仕様書無しさん
07/12/31 06:18:06
>>610くらいからの流れにｸｿﾜﾛﾀ
627:仕様書無しさん
07/12/31 11:01:55
>>623
RDBMS変わりうること前提にした外出しなの?
変わることなんかそうそう無いと思うんだが
628:仕様書無しさん
07/12/31 12:25:29
ハードコーディング＝静的ＳＱＬ
それ以外＝動的ＳＱＬ
ってこと？
なら静的に書いたほうがオーバーヘッドがない分性能はいいよ
629:仕様書無しさん
07/12/31 12:26:48
>>628
静的・動的ってどういう意味で使ってる?
俺はORMを使うかどうかという意味だと思っていたのだが。
630:仕様書無しさん
07/12/31 12:31:14
どういう意味？？？
静的＝コンパイラにＳＱＬのロジックを展開させてＬＭでは最終的なＤＢアクセスのロジックは固定
動的＝ＳＱＬが内部的に変わるのでＳＱＬ翻訳後にＤＢアクセスするのでの余計なオーバーヘッドがかかる
こんな感じ？
631:仕様書無しさん
07/12/31 12:36:48
あ
ここマ板か
失礼、ＤＢ板と勘違いした
632:仕様書無しさん
07/12/31 13:20:31
O/Rマッパは汎用的なのは良いが
オプティマイザの実行計画が
実は大変なことになってることが多いのが悲しいな。
633:仕様書無しさん
07/12/31 13:33:38
>>627
正規表現の場合の話がしたいの？SQLの場合の話がしたいの？
SQLと正規表現は別もんって書いてあるよね？
634:仕様書無しさん
07/12/31 13:35:45
>>632
裏で色々あったんだろうがDBMagazineのTopLinkは奇麗だったな・・・
635:仕様書無しさん
08/01/01 20:57:02
>>630
SQLの場合はこんな感じかな。DB2限定だが。
静的：実行計画を事前に取得しておく。
動的：実行時に実行計画を取得する。
ORACLEって静的バインド出来ないよね？
636:仕様書無しさん
08/01/04 16:45:58
1 が言いたいのはたぶん、
同一のテーブルを参照するSQLを
いたるところに書くことに辟易
してるってことを言いたいんだと思う
637:仕様書無しさん
08/01/04 21:56:46
それは、ハードコーディングだろうが、
外部ファイルに書こうが一緒だ。
638:仕様書無しさん
08/01/04 22:25:27
レスも空気も読まずにageレスか・・・さすが冬
639:仕様書無しさん
08/01/05 01:24:58
１が言いたいことはたぶん
プログラム内でSQL文を組み立てて発行することを言ってるんだと思う。
前にVBプログラマが作ったソースを見たら
sql = "SELECT * FROM テーブル"
conn.exec(sql)
みたいなコーディングだったんだけど、こういうのがハードコーディング？
DBにプロシージャとかを作成してアプリ側はそれを呼ぶだけにして欲しいってことじゃないの？
自分は小さい規模（ユーザー数１０００人前後）のシステムしか作ったことがないので
普通にDBにプロシージャを作って、C#でDBに接続してプロシージャを実行とかやってる。
上のレスを見たら分散処理のためにハードコーディングするとかあったけど
よく意味がわからなかった(^^;
ヤフーとか２ｃｈのようにもの凄い大量のアクセスがあるシステムでは
分散処理とか考えてコーディングしないとヤバイのかな？
もっと勉強しなきゃだな。
うちはWebサーバ1台とDBサーバ1台だけでやってて特に問題無い程度のアクセス数だけど
複数台のサーバで処理を分散とかの勉強もしなきゃなぁ。
640:仕様書無しさん
08/01/05 02:01:43
>>639
半年ROMれ
641:仕様書無しさん
08/01/05 02:25:38
>639
あー半年と言わず三年ROMれ
642:仕様書無しさん
08/01/06 10:32:28
ここの住人って常駐派遣が多そうだな。
643:仕様書無しさん
08/01/06 11:04:37
客先常駐の請負仕事なだけで派遣じゃないよｗ
644:仕様書無しさん
08/01/06 18:46:56
偽装派遣のにおいがするんだが・・・
645:仕様書無しさん
08/01/06 18:49:37
てゆうかマジで客先常駐なんてありえないよね。
ぶっちゃけ惨めじゃん。
自分の会社じゃないところに行ってさ。
うちにもちっさい会社のエンジニアが沢山常駐してるけどかわいそうだよ。
会社によるだろうけど派遣社員にはネットやメールを使わせないとか
そういうルールもあるし。
646:仕様書無しさん
08/01/06 23:11:03
常駐させてるのも、そういうルールを作ったのも
お前の会社なんだろ。
647:仕様書無しさん
08/01/07 22:04:27
思い付きだけで書かれたものを残されるとツライと思う。
でも、OJTだけで教育しようとしてるウチじゃあ無くならないんだろうな。
648:仕様書無しさん
08/01/08 10:58:26
>>647
詳細設計完了後に思いつきで
仕様変更を連絡して来なきゃ、
そのケースはかなり減ると思うｗｗｗ
649:仕様書無しさん
08/01/08 22:05:35
先輩方！お手本ソースを教えて教えて！
650:仕様書無しさん
08/01/13 22:06:25
M + ijime = Mijime = みじめ = 惨め
いじめられても笑顔で居られる客先常駐って惨めだよね
651:仕様書無しさん
08/02/06 01:24:00
まだあったのなー。
最近、自宅で趣味でJavaのWEBシステム構築やってんだけど、
ハードコーディングが楽だわ。
SQLインジェクションはバインド変数で解決、
不要なカラムは取得せずSQLもすっきり、I/Oもすっきり。
なんで>>1はハードコーディング嫌ってんの？作業振りしやすいから？
プログラマにDB周りをある程度把握させとかないと問題あったとき、危険だと思うけど。
どっちにしろO/Rマッピングは1から10まで全部一人でやっちゃうプログラマにはあんま美味しくないよ
652:仕様書無しさん
08/02/06 14:56:30
>>651
あとO/Rマッパはチューニングしにくい罠
653:仕様書無しさん
08/02/24 17:40:04
ハードコーディングってそもそも何？
654:仕様書無しさん
08/02/24 18:11:09
俺はiBATISくらいの薄い方が好きだ
655:仕様書無しさん
08/02/24 19:15:37
SpringJDBCがよい
656:仕様書無しさん
08/02/24 19:23:02
URLﾘﾝｸ(bbs.cgiboy.com)
荒らしならここをつぶすのがいい
へいさにおいこめくずども
657:仕様書無しさん
08/03/02 22:49:26
SQLをDBに持つとか別テキストに持つだとか構造をXMLにしてもっておくだとか
いろいろなプロジェクトがあったが、結局はSQLを直すときはソースも直す場合が多いよね。
そうなると分けるとよけい保守性が悪くなるよね。
658:仕様書無しさん
08/03/03 00:31:54
修正の規模による
659:仕様書無しさん
08/03/03 22:31:21
項目Ａ(3ﾊﾞｲﾄ)、項目Ｂ(6ﾊﾞｲﾄ)
(更新前)
AAA,BBBCCC
AAA,BBXCCC
AAA,BBPCCC
(更新後) ← このようにしたいです。
AAA,BBZCCC
AAA,BBZCCC
AAA,BBZCCC
目的は、項目Ｂの頭３バイトだけを”ＢＢ＊”で条件に指定して、
項目Ｂの頭３バイトを全て”ＢＢＺ”に更新したい場合どうすればよいのでしょうか？
項目Ｂの後３バイトの”ＣＣＣ”はそのまま残さなくてはいけないため、
どのようなＳＱＬ文にすれば良いのかわかりません。
どうしても後３バイトを生かしたままの更新なので。。。。困ってしまします。
お知恵をお貸しください。
660:仕様書無しさん
08/03/03 22:41:36
>>659
concat(concat(substr(B,1,2),'z'),substr(B,4,3))でupdateしたらどうか？
661:仕様書無しさん
08/03/03 22:50:13
>>660
本当にありがとうございます！！
さっそく明日実行してみます。！！
「現場で使えるＳＱＬ」って本読んでもうまくＳＱＬ文思いつかなくて。。。
本当にありがとうございます！！
662:仕様書無しさん
08/03/03 23:05:55
設計が悪いようにしか思えん。
663:仕様書無しさん
08/03/04 00:38:36
これ酷いな
664:仕様書無しさん
08/03/04 13:13:52
ハードコーディング最強
665:仕様書無しさん
08/03/04 17:31:29
S2DAOでいいや
666:仕様書無しさん
08/03/04 22:17:23
>>659 コボラーのにおいがする
667:仕様書無しさん
08/03/05 00:34:15
ストアドは使わないの？
コンパイル時間がかからないから初回がやたら遅いSQLにいいじゃん。
668:仕様書無しさん
08/03/05 01:17:28
DBにSQL文いれときゃいいじゃん
669:仕様書無しさん
08/03/06 09:35:17
>>668
それを取得するSQLはどうするんだ？
670:仕様書無しさん
08/03/07 00:50:45
Dim SQL As String
SQL=DLookup("SQL","M_SQL管理テーブル","id=xxx")
671:仕様書無しさん
08/03/07 02:30:25
Accessはポイだポイ。
672:仕様書無しさん
08/03/11 06:32:38
>>670
Aceess かどうかはともかく、SQL 文を id(多分 数値型のつもりでしょ) で管理するってのは、
関数やら手続きを連番で管理するのと同じにおいがする。
id='xxxマスタ取得' とか id='xxx一覧取得' とかなら、数値管理よりはましかな。
673:仕様書無しさん
08/03/14 01:36:48
>>672
これやった事ある。
SQLを修正するときは探すのも面倒なので新規にテーブルに
放り込んでたｗ
ソース側はid変えるだけ。
思ったよりも混乱は生じなかったよ。
DBに2回アクセスするのが欠点だけどｗ
674:仕様書無しさん
08/03/14 02:29:54
SQLを別の場所に置いたとして、SQL修正後のテストのために
どのプログラムから、そのSQLが使われてるかとか常に管理してんの？
それとも複数のプログラムからはSQLを共有しない？
675:仕様書無しさん
08/03/14 02:44:42
>>674
>それとも複数のプログラムからはSQLを共有しない？
その通りまったく同じSQLがたくさんはいっている。
ソース内で同じIDのSQLを呼び出さないルール
ソース側との整合性だけとれてればいいので管理しない。
テスト時に帰ってきたSQLが正しいかだけチェックしてる。
ぶっちゃけると中国人プログラマが勝手にこのルールに
してしまったので皆つきあわされたｗｗ
676:仕様書無しさん
08/03/14 07:59:11
SQLを動的に作る自作API使ってる。1500行。
メリットはどんなSQL DBにも対応可能。
汎用性／柔軟性が高い。開発効率が良い。
デメリットはストアドとかが使えない。
677:仕様書無しさん
08/03/14 20:24:52
それならS2JDBCでも使えよ。
まぁ、Javaじゃないかもしれんが
678:仕様書無しさん
08/03/14 22:28:20
SQLを外出しにして管理しても再利用できる汎用的なSQLは
せいぜい全体の２・３割程度で、ほとんどは１箇所でしか使われない。
単純で汎用的なSQLについてはOR-MAPした方が便利だが、
帳票出力、データ集計、条件が複雑に変化するな検索など
ビジネスロジックそのものと言えるSQLはオンコーディングか、
ストアドにしてしまった方がシンプルかと…
679:仕様書無しさん
08/03/14 23:27:03
おれもストアドだな
680:仕様書無しさん
08/03/15 00:17:05
ストアド使い出すと、増えすぎて見通しが悪くなるから好かん
681:仕様書無しさん
08/03/15 00:40:08
ストアドはうざいから俺も好かん
682:仕様書無しさん
08/03/15 01:03:25
異様に処理時間のかかるアホみたいなのを平気で組むヤツが居るんよな
683:仕様書無しさん
08/03/15 01:08:04
Oracleマニアみたいな人が作って残していった
バッチ処理で1万行のプロシージャと闘ったときは死ぬかと思った。
単純になるなら歓迎だけど、意地でもストアドみたいなポリシーはやめて欲しい。
684:仕様書無しさん
08/03/15 12:26:23
>>683
それはストアドにしたから複雑になったんじゃなくて、
SQL一発でできることを無駄にカーソルで処理するから複雑になってるのでは？
685:仕様書無しさん
08/03/15 12:42:31
>>683
１プロシージャに１万行なんて、そいつがキチガイなだけだろ
686:仕様書無しさん
08/03/15 21:56:57
「カーソル」が使われているストアドは、COBOLからの書き換え以外認めない。
687:仕様書無しさん
08/03/16 23:46:20
>686
それはまた極端なｗ
688:仕様書無しさん
08/03/22 08:18:00
人間中庸が肝心だ。
689:仕様書無しさん
08/03/22 22:36:55
PHPでSQLをハードコーディングしてあってびびった。
SQLは切り出せよ。
SQLインジェションされてサニタイズ漏れたら終わりだろがと。
言ったが今でも放置されたまま。
690:仕様書無しさん
08/03/22 22:54:54
>>689
ハードコードしてあっても
プレースホルダ使うだけでだいぶ変わるがな。
つか「インジェション」ってｗｗｗ
691:仕様書無しさん
08/03/23 01:07:26
SQLをハードコーディングすることとSQLインジェクションの問題は直行しているから、>>689の指摘は的外れだったんじゃないかなぁ？
692:仕様書無しさん
08/03/23 10:07:08
>>691
直行？直交にしてもわからんしな。関係ないってコトじゃないのか。
693:葉猫 ◆Jz.SaKuRaM
08/03/23 13:15:03
ストアドにちておけば内部で文字列化ちてselectとかexecuteみたいなｱﾎなことちないかぎり
問題ないちな (･∀･)
694:仕様書無しさん
08/03/23 13:57:07
ストアド簡単なのに作ろうとしない馬鹿が多すぎてこまる。
提案してもメンテできない・わからないで握りつぶされる。
結果ハードコーティングでバグおこしてデスマ。
あほSEは早く欝になって首つってくれ！！！！！
695:仕様書無しさん
08/03/23 14:08:35
>>694
> 提案してもメンテできない・わからないで握りつぶされる。
ありがちだが、その連中の言い分も分からなくはない。
696:仕様書無しさん
08/03/23 14:45:01
>>694
ストアドは扱いが難しい。
テーブル設計が完了した段階でデータベースの構造をフリーズして
後はデータの出し入れだけにしたいという方針が普通の感覚だと思うんだが、
プログラムと同じ感覚でストアドを作ると、この方針と衝突する。
データの意味づけが拡張されてストアドの修正が必要になっても、まかりならんって
ことになったりする。
そういう時はしかたないので、プログラム側でストアドに相当するSQLを新しく
発行するようにして、ストアドは呼ばなくなる。
設計段階でストアドの要件もしっかり決めておけってのが正論なんだろうが。
間に合わせ的に使ってしまったりするな。
697:仕様書無しさん
08/03/23 15:00:25
俺がストアド嫌いな理由は、デバッガが使いにくいから。と
単純なSELECTやINSERTだったら、
ORマッピングツールのほうが良くて
混在すると鬱陶しいから、極力ORマッピングツールを使う。
提案してもメンテできない・わからないっていう、
SEはしんだほうがいいなと俺も思う。
698:愛ちゃん
08/03/23 17:20:48
ORマッピングとかORマッパってどういうものなんでしょうか？
699:仕様書無しさん
08/03/23 17:31:52
SQL書かなくてもＲＤＢが使える魔法の箱さ！
700:仕様書無しさん
08/03/23 17:41:55
ストアドは自動テストに組み込み難いんだよな
デバッグも面倒だし
701:仕様書無しさん
08/03/23 17:43:21
制約が多すぎで使えねー、
検索系で組み込んだら遅くて使えねー、
マスタメンテ以外につかえねーの三拍子
意地でも使ってやるって人の背中にはデスマオーラが漂ってる
702:仕様書無しさん
08/03/23 18:16:54
派生開発案件で元が腐ってたとかならともかく、
ストアドなど書かずに済むようにDB設計するのが基本だと思う。
あと、「性能」を理由にすぐにストアドを使いたがるプログラマって
単に手続き的にしか物事を考えられない（まともなSQLの書き方を知らない）
人が多いような。
703:仕様書無しさん
08/03/23 19:42:09
バージョン管理とかはメンドクサくないの？
704:仕様書無しさん
08/03/23 21:54:50
ストアドはバージョン管理めんどくさい。
ストアドは、データベースやSQL Serverの外から呼び出すプログラミング環境が
貧しかった時代の亡霊だと思う。昔はストアドで何でもかんでもやってた。
705:仕様書無しさん
08/03/23 23:37:49
ORマッパについて解説しているサイトをご存じないですか？
706:仕様書無しさん
08/03/24 00:38:02
今までの意見をまとめると、RDBSは糞ってことで良いか？
707:仕様書無しさん
08/03/24 00:52:36
ハードコーディングってなんだろう
708:仕様書無しさん
08/03/24 01:25:17
>707
>91
709:仕様書無しさん
08/03/26 22:46:34
ストアドの方がパフォーマンスが良いとかはもう昔の話？
あと権限についてですが、ハードコーディングだと実行権限付与がめんどくないですか？そんなことないかな。
自分の会社はWebの開発が多いのですが、例えばIISを使っている場合だと
IISの匿名ユーザーにストアドの実行権限を付与してるだけです。
テーブルの書き込み権限とかは一切与えてなく、ストアドの実行権限のみです。
その方が安全とか先輩が言ってました。
710:仕様書無しさん
08/03/26 22:50:37
そりゃそうだ
最近SQLを満足にかけない奴がORまっぱとかほざいてるだけのような気がする
休日は自宅にヒキコモリ。
仕事じゃひとつの言語にヒキコモリ。
ヒキコモリ人生万歳ですか？
711:仕様書無しさん
08/03/26 22:55:45
>709
別に昔の話ではない。今も通じる。
権限は……面倒くせえからDBAでアクセスしちまえｳﾊﾊﾊってのばかり見かけるが
712:仕様書無しさん
08/03/26 22:56:22
>710
前半と後半の乖離ぐあいにﾜﾗﾀ
713:仕様書無しさん
08/03/26 23:30:39
>>709
ストアドの方がパフォーマンスがよいって言うのは今でも正しいけど、
テーブル設計とSQLの筋さえよければ今は十分なパフォーマンスが稼げる。
だからクエリをDB側ではなくアプリ側に持っていく事によって得られる
開発パフォーマンスの向上が今は重視されている感じだな。
714:仕様書無しさん
08/03/26 23:32:59
実行プランを認識してない馬鹿が組むSQLは見てらんない
死ねばいいのに
715:仕様書無しさん
08/03/26 23:41:11
>>704
OSI7層モデルから勉強しなおせ。
716:仕様書無しさん
08/03/27 22:28:29
>>715
OSI7層って実行速度より美しい理論モデル作りたがりの産物じゃん
当時の実装は各境界の通信でオーバーヘッド出まくりで
遅くて使い物にならないものが多かった
マシンの性能が上がった今なら実装のしようもあるだろうが
IPにとって代わられちゃったし
717:仕様書無しさん
08/03/28 01:56:38
>>716
OSIの考え方を用語するつもりはないが、
OSIは政治的に潰されたんだよ。これ豆知識ね。
718:仕様書無しさん
08/03/28 07:28:36
>>717
OSI モデルの第 8 層って奴だな。
あと、宗教層・経済層ってのを加えるときもある。
719:仕様書無しさん
08/03/28 09:11:35
>>718
それは、知らなかった。補足ありがとう。
720:仕様書無しさん
08/03/28 21:34:09
一時期 layer8.jp とか取ろうと思ったこともあったが、
やっぱり取られてたぜ。
721:仕様書無しさん
08/03/31 07:33:52
ハードコーディングとストアドを比べたらストアドの方がよい。
けれどハードコーディングには次のメリットがある。
たとえば、
WHERE
(col1 LIKE #para1# or #para1# = '')
AND
(col2 = #para2# or #para2# = 0)
AND
(col3 = #para3# or #para3# IS NULL)
この程度でIF文はいらん。
実行時にコンパイルされるから、ハードコーディングなら、col1～col3 に
インデックスがあれば利用される。
ストアドならアクセスパスは固定されてしまって、col1～col3 にインデックス
があっても利用されない。
こういうときはストアドでも、敢て動的SQLにするんだけど、そこまで気を
使っているコーディングを見ることがないな…。
722:仕様書無しさん
08/03/31 08:56:59
>>721
>この程度でIF文はいらん。
そんなこと言うから変なコードが増える。
IF文をけちってなにかいいことでもあるのか。
723:仕様書無しさん
08/03/31 09:28:34
>>722
ヘタクソやね～。
母言語とSQLでスパゲッティ作っておいしいか？
724:仕様書無しさん
08/03/31 10:03:52
スパゲッティ？
725:仕様書無しさん
08/03/31 20:01:02
>>721ぐらいなら普通IFなんて使わんだろ。
726:仕様書無しさん
08/03/31 21:21:00
"commit"をハードコーディングする俺の会社orz
727:仕様書無しさん
08/03/31 21:27:21
>>726
それなんか問題あんの？
どーでもいいじゃん
728:葉猫 ◆Jz.SaKuRaM
08/03/31 22:08:26
正直、ストアドのwhere句に条件式入れるのと、exeのsql文のwhere句に入れる違いがわからん。
729:仕様書無しさん
08/04/01 07:24:50
>>728
プランナについて勉強しよう
730:仕様書無しさん
08/04/01 12:07:32
勉強できるほどの知能があれば、とっくにｺﾃやめてるだろう。
731:仕様書無しさん
08/04/01 18:24:21
commit はハードコーディングじゃないの。
（一ヶ所にまとめるけどね）
少なくとも俺はストアドの中には書かせない。
ネストしたらえらいことだ。
732:仕様書無しさん
08/04/01 19:02:34
>>722
sWhere = " WHERE a.colx = '" + 画面.xx + "'";
if (画面.yy != 未入力){
sWhere += " AND a.coly = '" + 画面.yy + "'";
}
if (画面.zz != 未入力){
sWhere += " AND EXISTS (SELECT * FROM TABLE b ";
sWhere += " WHERE a.key = b.key";
sWhere += " AND b.colz = '" + 画面.zz + "')";
}
ってなコーディングは山ほど見たな… 吐きそう …オェ～
もっとへたくそは " AND "がいるか判定してたり…orz
これはこうなるべ。
sWhere = " WHERE
sWhere += " a.colx = :parX";
sWhere += " AND (a.coly = :parY OR :parY IS NULL) ";
sWhere += " AND (EXISTS "
sWhere += " (SELECT * FROM TABLE b ";
sWhere += " WHERE a.key = b.key";
sWhere += " AND b.colz = :parZ)";
sWhere += " OR :parZ IS NULL";
sWhere += " )";
良く見ろよ。
固定のSQLじゃないか？（ストアドにした方がすっきりするべ）
動的SQL（コストベース）なら coly も、インデックスが
存在して効率的なら使われるんだな。
733:仕様書無しさん
08/04/01 21:42:39
>>727や731のコードが汚いことはよくわかった。
宣言的トランザクション使えよ。
734:仕様書無しさん
08/04/01 21:58:27
>>733はバカ
735:仕様書無しさん
08/04/01 22:18:44
ORまっぷっぷは、SQLも覚えられないボケが崇拝するお花畑のちょうちょに過ぎないし。
プロシージャはマニア魂を刺激しちゃって、ろくなことにならないときあるし。
やっぱハードコーディングが一番いいよ。
効率的だし、ブレないし、マニアックになり過ぎないし。
736:仕様書無しさん
08/04/01 22:20:44
でも最近はORマッパで済ませちゃうのがもてはやされる。
Railsとか。
737:仕様書無しさん
08/04/01 22:25:08
結論から言うと適材適所でしょ
ルールはきちんと作ってだけどね
738:仕様書無しさん
08/04/01 22:31:39
関係ないけどJOIN禁止のプロジェクトとかまだあんのかなぁ
739:仕様書無しさん
08/04/01 23:02:24
３年間オラクレばっかやってた。
今度SQL鯖やるんだけどJOINって何だよおしえれorz
740:仕様書無しさん
08/04/01 23:05:51
グイでグイグイやってたらSQLは勝手に出来る
741:仕様書無しさん
08/04/01 23:18:16
結局ハードコーディングの方があとで分かりやすいんだよな
742:仕様書無しさん
08/04/01 23:19:39
Set OraDynaset = Nothing
743:仕様書無しさん
08/04/01 23:20:27
うん。
別ファイルにしてあると、開くのにマウスこちこちしないといけないからめんどくさいしね。
744:仕様書無しさん
08/04/01 23:21:49
今日書いたSQLは3年後5年後も通用するが今日使ったO/R mapperは
3年後5年後には誰も使わないレガシーな技術になってると思う
745:仕様書無しさん
08/04/01 23:43:57
>>739
（＋）
746:仕様書無しさん
08/04/02 00:13:02
unionしてsumしてクロス集計ってアリなの？
747:仕様書無しさん
08/04/02 09:37:09
ORマッパがいいのなら、素直にオブジェクト指向データベース使えよ。
なぜ、今まで使われなかったのか、考えてみ。
748:仕様書無しさん
08/04/02 20:32:28
>>745
それはオラクル特有のおまじないじゃん？
749:仕様書無しさん
08/04/02 22:10:52
今さら (+) なしの生活には戻れないわ・・・
もうすっかりOracleに毒されちゃってるのよ・・・
750:仕様書無しさん
08/04/02 22:29:39
最近のSQL Serverだと*=や、=*は使えないんだっけ？
つーか、Oracleでも9i以降ならOUTER JOINで書かないか？
751:仕様書無しさん
08/04/02 22:48:57
ora9iのOUTER JOINはバグが潜んでる
752:仕様書無しさん
08/04/02 23:55:27
バグは、9.1.4までじゃない？
(+)を書く奴は氏ねとは言わんけど、金取れるプロじゃないわな。
753:仕様書無しさん
08/04/03 00:45:44
URLﾘﾝｸ(www.google.co.jp)(%2B)
754:仕様書無しさん
08/04/03 02:38:01
>>752
何で死ね扱いなんだ？
俺は書きやすいし読みやすいから (+) の方がすきなんだが
755:仕様書無しさん
08/04/03 07:58:45
*=とかよりはJOINの方が見やすいという人が多い。
自分もそう思います。
756:仕様書無しさん
08/04/03 09:20:53
>>754
SQLの意味が分かってない。
SQL とは Structured Query Language(構造化問合せ言語)
省略語じゃないとかそんなことはどうでもよいけど、
構造化いうのは、句ごとに役割が決まっているわけ。
WHERE句に結合条件と抽出条件を混在させても違和感を
覚えない時点で、プロとしてのセンスはない。
757:仕様書無しさん
08/04/03 09:37:48
>>756
あの旧世代の腐れ構文が構造化されているように見えるとは恐れ入った。
758:仕様書無しさん
08/04/03 09:46:18
xxxx JOIN Table ON
という書き方が冗長というのは、同じ非英語圏の人間だから
わからんではないが、WHERE句に結合条件を書くのは痛い。
759:仕様書無しさん
08/04/03 10:05:05
>>757
まぁ、あれだ。
マシン語から新世代に近づくほど、
自然言語に近づくもんなんだ。
ループがある方が旧世代なんだな。
760:仕様書無しさん
08/04/03 11:34:11
>>757
腐っていようが…。
WHERE句に結合条件を書いたら、もっと腐る
ということが分からない時点で終わってる。
761:仕様書無しさん
08/04/03 12:30:31
>>760
>腐っていようが…。
「構造化されてなんかいない腐れ構文」には同意頂けたようで。
…まあ、Oracle の旧書式は直感的だが、もっと腐ってるとは思う。
>WHERE句に結合条件を書いたら
「抽出条件」てのが「1行1項目しかない『定数』との結合条件」と考えれば
両者の間になんの違いもないわけだが。
-- そういやこないだ、
-- JOIN ～ ON (～ AND HOGE = 0)
-- なんて記述を見かけた。
762:仕様書無しさん
08/04/03 12:37:27
>>761
何が面白いのか解説してよ
763:仕様書無しさん
08/04/03 15:50:26
LEFT JOIN
764:仕様書無しさん
08/04/03 16:03:24
まちごうた。
Oracle9.1.4以前はバグでちゃんと
動かんかったけ記憶があるが。
>>761
違い分かるか？
FROM
table_a a
LEFT OUTER JOIN table_b b
ON a.key1 = b.key1
AND 0 = b.key2
FROM
table_a a
LEFT OUTER JOIN table_b b
ON a.key1 = b.key1
WHERE
b.key2 = 0
761 は文句言いながら副問合せ書く奴と見たｗ
765:仕様書無しさん
08/04/03 17:56:22
>>764
お前は莫迦か。
後者は結合後に抽出してんだろが。
766:仕様書無しさん
08/04/03 18:21:33
文脈読めよ。
>>761の
-- そういやこないだ、
-- JOIN ～ ON (～ AND HOGE = 0)
-- なんて記述を見かけた。
に対して >>764 だ。
767:仕様書無しさん
08/04/03 18:29:04
FROM
table_a a
LEFT OUTER JOIN
(SELECT * FROM table_b WHERE key2 = 0) b
ON a.key1 = b.key1
ってインデックス外すバカがいるわな。
768:仕様書無しさん
08/04/03 20:33:26
ここで悦に入って何か得られるモノがあるのだろうか･･･
769:仕様書無しさん
08/04/03 22:56:03
>>732のようなコードのメンテをやらされてると、この仕事辞めたくなるな。
そんなもんの修正はそれに違和感感じない連中だけでやってくれって感じだ。
770:仕様書無しさん
08/04/04 07:34:06
>>732
なんだこれ・・・
こんなんjavaで書いてきたらソースレビューの時点で突っ返すぜ
もし下請けが書いてきたらくびになっても検収印はおさねえ！
771:仕様書無しさん
08/04/04 07:37:39
出来ない奴はとっとと氏ね
ってことだな。
772:仕様書無しさん
08/04/04 09:05:47
>>769
俺は
sWhere += ～
sWhere += ～
sWhere += ～
:
こういうのが並んでる時点で唾棄。
773:仕様書無しさん
08/04/04 09:44:07
sprintf( buf, "select %s from %s\n", col, tbl );
774:仕様書無しさん
08/04/04 09:47:30
質問です。
各テーブルごとにテーブルクラスを作成し、
データの受け渡し受け取りには、テーブルクラス.レコードを定義して使用しています。
で、各テーブルごとの違いは、レコードクラスの違いくらいであとの処理は同じなので、
同じ処理を書いて、あまりステップ数を膨らませるのは嫌なのですが、
何かよい方法はないでしょうか？
775:仕様書無しさん
08/04/04 09:55:19
>>774
>質問です。
ｽﾚの選択も満足にできないの？
776:774
08/04/04 10:01:21
SQL文ハードコーディングを嫌がるスレということなので、
↑の質問にも答えてもらえると思ったのですが、ちょっとスレ変えることにします
777:仕様書無しさん
08/04/04 20:33:23
>>774
javaならhibernate使えよ。
778:葉猫 ◆Jz.SaKuRaM
08/04/04 21:40:57
継承も使えずにクラスを使うとはなかなかやりまつね
779:仕様書無しさん
08/04/04 21:41:56
はずかしげもなくまだ生きてる貴様に比べれば誤差未満だな
780:仕様書無しさん
08/04/05 19:51:35
自作APIの最終select文作成部分のコード。
snprintf( buffer, BUFFER_MAX, "SELECT %s FROM %s %s %s %s %s %s %s", fieldStr, tableStr, whereStr, orderStr, lockStr, limitStr, offsetStr, optionStr );
それぞれの部分を、専用の関数で構造体からSQLに変換して作ってる。
メジャーないくつかのSQL DBに対応済み。SQL以外のDBにもいくつか対応済み。
基本的なテーブルのselectややinsertやupdateなら一切SQLを書くことも見ることもない。
せいぜいフィールド名と条件や値とかを指定するだけ。
必要があればSQLを直接渡せるようにもなってる。
これぐらい自作APIでやってる人いる？