SQL文をハードコーディングするやつはとっとと氏ね

1 ：仕様書無しさん：2007/02/07(水) 01:32:56

って思う

2 ：専門卒（英語科）　　田崎：2007/02/07(水) 01:53:41

>>1
馬鹿ね。
普通はハードコーディングするでしょｗ？

3 ：仕様書無しさん：2007/02/07(水) 01:54:00

２ゲット

4 ：仕様書無しさん：2007/02/07(水) 01:55:11

あらゆるSQLはテキストにするプロジェクトに関わったことがある。
はっきりって何もいいことがない。

5 ：仕様書無しさん：2007/02/07(水) 01:59:35

ハードコーディングすると保守性さがんじゃん
何もいいことないとかバカじゃね？

6 ：仕様書無しさん：2007/02/07(水) 02:02:26

デバッグしづらいだけだろ。

7 ：仕様書無しさん：2007/02/07(水) 02:05:46

所詮プログラムと一対一になるものをわける意味がわからん。

8 ：仕様書無しさん：2007/02/07(水) 02:06:33

300行位使ってSQL成形するやつ見た事ある

あんなの触る位なら死んだ方がいいね

9 ：仕様書無しさん：2007/02/07(水) 02:09:13

>>7
君この業界諦めた方がいいよ

10 ：仕様書無しさん：2007/02/07(水) 02:15:39

>>5
UIしかやったことのない厨房はひっこんでろ。

11 ：仕様書無しさん：2007/02/07(水) 02:16:25

>>8
３０００行というやつもいたぞ。

12 ：仕様書無しさん：2007/02/07(水) 02:18:48

むしろ早くLINQみたいなのが出てくれと思ってる

13 ：仕様書無しさん：2007/02/07(水) 02:19:13

RDBをいじるプロジェクトには3回参加した。
C++の中にSQL文字列が埋まってるのは確かにちと無様だが、
未だにどうやるのがいいのか分からん。
ハードコーディングじゃない、ってのはどうやるんだ？

14 ：仕様書無しさん：2007/02/07(水) 02:25:43

SQL文を書かなくていい程度ですむプロジェクトにしか関わってないなら幸せだな
>>2,5 に同意

15 ：仕様書無しさん：2007/02/07(水) 02:27:32

>>13
リソースに突っ込んだり、
暗号化した独自の形式の何かに入れておいてそれを使うとかじゃねーの？
どこで何を使っているか等の管理が面倒になって工数が増すという利点がある。

16 ：仕様書無しさん：2007/02/07(水) 02:30:15

>>13
俺もわからん。

17 ：仕様書無しさん：2007/02/07(水) 02:31:10

>>14
ちょｗｗｗどっちだ？

>>15
工数が増すという利点にワロタ

18 ：仕様書無しさん：2007/02/07(水) 02:38:53

DAOとかO/Rマッパーとかそういうのを意図していると思った > スレタイ

19 ：仕様書無しさん：2007/02/07(水) 03:33:25

>>18
そういう話題の方が意義があるよな。
SQLをプログラムから別にするだけで保守性が増すなんて猿以下のアイデアとしか思えん。
土台のモデルが腐っていればスパゲティ度がむしろ増加する。

20 ：仕様書無しさん：2007/02/07(水) 08:38:43

直書きするか否かというのはプログラマの裁量でなく、プロジェクト上の実装方針に依るのでマを責めてはいけない。
実装方針決定者はＳＱＬの書き方に多様なアプローチがあることを知るべき。

直書きだと、どの箇所に何があるかとか管理できないし、一箇所のＳＱＬを変えるだけでビルドやらされたりと、確かに碌なことにならない。

21 ：仕様書無しさん：2007/02/07(水) 08:40:52

また変な宗教はやらせないでくれよ

22 ：1：2007/02/07(水) 08:41:11

>>18
そういうこと

23 ：仕様書無しさん：2007/02/07(水) 08:56:53

引き継いで弄ってたソースがSQLべた書きだったんだが、
タダのべた書きではなく、プレースホルダすら使ってねぇ
べた書きだった。文字列連結しまくり。

まぁ、いろんな意味で
この会社辞めようと思ったソースコード＃15
http://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 ：仕様書無しさん：2007/02/07(水) 10:55:26

SQLを分離して、本体はビジネスロジックに集中ですね

27 ：仕様書無しさん：2007/02/07(水) 12:04:57

でたービジネスロジック厨ｗ

28 ：1：2007/02/07(水) 12:05:32

>>23
クラックされた某サイトが正にそれで、
プレースホルダを使ってない上に値をエスケープしてないがためにSQLインジェクションできまくりな
悲惨なソースコードだった

29 ：14：2007/02/07(水) 13:05:22

>>17
ごめん >>2,10 に同意だった...orz

30 ：仕様書無しさん：2007/02/07(水) 18:35:20

SQLをごちゃごちゃする部分は極力ストアドにして、
プログラム側ではもっぱらそれを呼び出すことに専念
する方向でコーディングした俺は正解なんだろうか。

31 ：仕様書無しさん：2007/02/07(水) 18:45:00

ストアドはいくない

32 ：仕様書無しさん：2007/02/07(水) 20:16:42

ストアドか
それも選択の１つだけど
開発が面倒じゃない？
管理も

33 ：仕様書無しさん：2007/02/07(水) 20:26:06

一回組んだらそうそう変えないようなのは楽だしパフォーマンスもあがるし、
ＳＱＬも分離できてウマー。

開発は確かに面倒。管理もだな。

動的に検索条件(Where句)が変わるようなのは、特に。

34 ：仕様書無しさん：2007/02/07(水) 20:27:07

ハードコーディング無しで、DB使うアプリ書ける？そんなの無理でそ。
パラメータ受け取ってSQL文を生成するライブラリを書いてお茶を濁す
のが精一杯。
パフォーマンスの問題で、どうしてもDBMS固有の方言使っちゃうから、
DBMSの切り替えが発生した場合は、ライブラリの書き替えは避けられない。

35 ：仕様書無しさん：2007/02/07(水) 20:29:54

ストアドって長くすると、デバッグが大変のような。

36 ：仕様書無しさん：2007/02/07(水) 20:31:17

>>34
リソースとか別ファイルにしておくってことだろ? ハードコーディングしないって。

37 ：仕様書無しさん：2007/02/07(水) 20:35:57

>>34
そうそう。それでEJBは失敗した。

38 ：仕様書無しさん：2007/02/07(水) 20:49:18

>>36
そういうことなんだが、組みにくいわ、別ファイルの管理は面倒だわ、
ファイルIO発生しまくりだわ、欠点も多いのだよ。

>>35
かなりな。

39 ：仕様書無しさん：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 ：2007/02/07(水) 21:31:10

ストアドは１トランザクション中に複数のSQLを投げる必要がある場合なんか効果的だよね。

45 ：仕様書無しさん：2007/02/07(水) 22:11:37

ストアドは再現性の無いバグ(本人が気付けないだけ？)に悩まされそうで怖い。
ソースに埋め込んだ方が、トランザクションの一貫性の検証がしやすいし、
トレースも楽でいいよ。
再コンパイルを避けるためだけにSQL文を外に追いやるってのはどうなの？って感じ。

46 ：仕様書無しさん：2007/02/07(水) 22:19:10

Delete文を動的SQLで生成するルーチン作ったらwhere句の手前にいつも’\0’が入ってたwwwww
ちょwwwwCOMMIT発行すんのまwwwwwwwｑｗせｄｒｆｔｇｙふじこ

47 ：仕様書無しさん：2007/02/07(水) 22:23:07

>>46
お前、出禁な。

48 ：仕様書無しさん：2007/02/07(水) 22:28:02

>>46
俺はUPDATEで同じことやらかしたけど、
消えたわけじゃないから罪は軽いよね(´・ω・`)

49 ：仕様書無しさん：2007/02/07(水) 22:30:33

>>48
出禁40日。>>46は無期限！

50 ：仕様書無しさん：2007/02/07(水) 22:53:28

データ取るためのSQLと受け取り側のアプリは密な結合だもんなあ。
分割しても結局どちらも修正入ることが殆どだし。

51 ：仕様書無しさん：2007/02/07(水) 22:53:37

SELECT文はXMLからロード＆更新系は動的生成
これで完璧に動いてますが

52 ：仕様書無しさん：2007/02/07(水) 22:58:12

おじいちゃん、またそんなｵﾅﾆｰｺｰﾄﾞ書いて。。

53 ：仕様書無しさん：2007/02/07(水) 22:58:34

>>40
そこでDataSetですよ

54 ：仕様書無しさん：2007/02/07(水) 23:00:06

またXMLかよ
いい加減にしる！

55 ：仕様書無しさん：2007/02/07(水) 23:03:51

>>40
> データ用のクラス用意

やるやるｗｗｗ

少なくとも、SQLを書いていいところ(DBアクセス・業務プロセス系)と
書いちゃいかんところ(UIなど)を分けておくと、少し幸せになれる。

56 ：仕様書無しさん：2007/02/07(水) 23:04:41

>>46-49
ワロタｗｗｗｗｗ

57 ：69式フリーPG ◆hND3Lufios ：2007/02/07(水) 23:13:44

ストアドのいいところはシステムを止めずにロジック変更が出来ることもあるな。

58 ：仕様書無しさん：2007/02/07(水) 23:18:29

>>57
気づかなかった

59 ：仕様書無しさん：2007/02/07(水) 23:25:56

だからといって、1行インサートするだけのｵﾅﾆｰストプロ書くのは止めてください。先輩。

60 ：仕様書無しさん：2007/02/07(水) 23:32:36

>>37
おまえ、Seasarの人間？EJB批判すんのもいいけど、考え無し過ぎる独自仕様もどうかと思うぜ。

61 ：仕様書無しさん：2007/02/08(木) 00:10:38

これからの時代ORMでしょ。SQLを生で使うのダサいよ。
Java厨ならHibernateを使え。キャッシュをうまく使えばSQLの直書きより性能いいゾ。

62 ：仕様書無しさん：2007/02/08(木) 00:13:18

常識的に考えて、このスレはJava屋限定にすべきだろ。
>>40とか、何しに入ってきてるんだよ。。

63 ：仕様書無しさん：2007/02/08(木) 00:14:47

Java厨ってさ、SQL書くのが下手な奴多くね？実行計画の見方も知らない見たいだし。

64 ：仕様書無しさん：2007/02/08(木) 00:22:19

ＤＢといえばOracleオンリーな、柔軟性の無い奴もよくいるな。

65 ：仕様書無しさん：2007/02/08(木) 00:35:46

SQLの書き方次第でパフォーマンスに大きな違いがでる間は、ハードコーディング
せざるをえない。

66 ：仕様書無しさん：2007/02/08(木) 00:42:42

toruqueを使えばSQLなんて書かなくていいよ。あほじゃん？

67 ：仕様書無しさん：2007/02/08(木) 00:43:10

そんな微妙なチューニングが必要になる場合って、大抵テーブル設計が
糞だけどな。

68 ：仕様書無しさん：2007/02/08(木) 02:14:30

ORマッピングなんて作り手の自慰行為じゃねーか
EJBと同じ匂いがするぜ

69 ：仕様書無しさん：2007/02/08(木) 07:10:53

>>66
パフォーマンス無視だけどなｗ

70 ：仕様書無しさん：2007/02/08(木) 07:54:17

>>61
ハイバネはまだまだバギーすぎて、本腰入れて使うのは厳しくない？
DBとの相性もあるかもしれないけど。

71 ：仕様書無しさん：2007/02/08(木) 08:31:29

この手の話は
酒のつまみにはなるけど
飯の種にはならんな

72 ：仕様書無しさん：2007/02/08(木) 08:32:04

EJBで性能でなくて生SQLに全部書き換えしたプロジェクト知ってる。

73 ：仕様書無しさん：2007/02/08(木) 08:41:05

そいへばテーブルのvarchar項目にSQL断片を入れておいて
SELECTで組み上げてからそれをまた実行する変な仕事を
こないだしたな。そのクエリ結果の中にまたSQL文が入ってる(w)

74 ：仕様書無しさん：2007/02/08(木) 08:46:19

>>73
ｗｗｗｗｗ

75 ：仕様書無しさん：2007/02/08(木) 09:36:08

>>70
たぶんOracleのJDBCドライバが腐ってるせいだと思う。
Hibernateは悪くない。

76 ：仕様書無しさん：2007/02/08(木) 09:38:36

ADO.NETが一番よくできてる

77 ：仕様書無しさん：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 ：仕様書無しさん：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 ：仕様書無しさん：2007/02/08(木) 15:21:25

ORマッピングの最高峰はWebObjects

87 ：仕様書無しさん：2007/02/08(木) 15:25:52

>>86
アップル信者死ね。

88 ：仕様書無しさん：2007/02/08(木) 15:34:34

>>87
アホ
俺は生粋のMS信者

89 ：仕様書無しさん：2007/02/08(木) 17:44:23

ハードコーディングってなに？

90 ：仕様書無しさん：2007/02/08(木) 19:52:29

>>89
表面を金属とかで堅く覆うことだろ．

91 ：仕様書無しさん：2007/02/08(木) 19:54:58

>>89
一生懸命プログラミングすること

92 ：仕様書無しさん：2007/02/08(木) 21:15:37

ととっとしネ

93 ：仕様書無しさん：2007/02/08(木) 21:48:10

>>86,88
EOF,っても通じないしなぁ。
Cayenneとかはどーなんでしょ

94 ：仕様書無しさん：2007/02/08(木) 22:37:25

>73
メタメタですね

95 ：仕様書無しさん：2007/02/09(金) 00:48:56

>>93
>Cayenne

たぶんさ、Cayenneみたいなつくりだと、springとか使っても
service層とdao層きちんと分けないでつくっちゃうやつがプロジェクトに
出そうだから、辞めた方がいいんでは。

96 ：仕様書無しさん：2007/02/09(金) 02:36:48

>>79
補助ツールとしては便利だけどね。
アレなしだと触れない奴はちょっとだな。

>>80-81
禿同

>>83
ちょkwsk
俺もORマッピング使ったことない。

97 ：仕様書無しさん：2007/02/09(金) 08:47:24

ORマッピングフレームワークを使わない理由

・興味があって調べたらxmlを書きまくらないとﾀﾞﾒなのが分かる
・どういう設定をすればいいのかぱっと分からない
・それで便利になるの？という疑心暗鬼
・スピードは？　融通性は？
・うーん。。。
・(ﾟ⊿ﾟ)ｲﾗﾈ

98 ：仕様書無しさん：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 ：仕様書無しさん：2007/02/09(金) 15:13:28

クライアント数が多いシステムだときついね。

101 ：仕様書無しさん：2007/02/09(金) 15:15:02

>>99
INSERT文が

　INSERT INTO HOGE VALUES(...

だったらいいけど

　INSERT INTO HOGE(UPDDATE) VALUES(...

ならダメじゃないか？

102 ：99：2007/02/09(金) 15:32:10

>>101
いやだから、いままでINSERT INTO HOGE VALUES(...
って書いてたのをO/Rマッピングにすると変えなきゃならんの？、てこと。

もっと簡単に言うと、
1個のDBに対して複数のWebシステムがぶら下がってたとして
そのうちの1つのWebシステムの拡張の為にDBのテーブル項目を増やしたとしたら
残りのWebシステムのソースは直さなきゃいかんの？、てこと。

103 ：仕様書無しさん：2007/02/09(金) 15:35:48

>velocityとかのテンプレートエンジン使って自動生成しる。
>複雑なSelect文なんかはO/Rマッピングツールは苦手だから
>そこらへんはビュー作って対応すると幸せ。

やっぱもう無理
面倒すぎ

104 ：仕様書無しさん：2007/02/09(金) 18:53:02

逆に直さなくてもよくなるケースもある罠。

テーブルにカラムが追加された時は、>>101の逆になる。

105 ：仕様書無しさん：2007/02/09(金) 19:03:00

>>103
つーかXMLで一カ所にまとまってる方がいいつーの。
XML差し替えだけで他のDBに移行できるんだし

106 ：仕様書無しさん：2007/02/09(金) 19:43:46

O/Rマッピング最低。実用に耐えない。
使いにくいのは慣れるとしても、一括更新と一括削除が出来ないのが致命的。出来ないんだよ、マジで。
100レコード消すとしたら、ループで100回まわす。更新も同様。
だから不要データを一括削除しようとしたら、2000件ぐらいで登録スピードに抜かれた。
高負荷時には300件消すのに10分近くかかった。ちなみにSQLで消すと5秒。
仕方ないので、クーロンで削除シェル動かして対処した。
ちなみに結合や関数も使えない。結合された表をビューにして使うことになる。
RDBMSで結合や関数が簡単に使えないなんて最低。

SQLを設定ファイルに分離するのも意味がない。殆どの場合SQLに変更が入れば処理も変更になるからだ。
第一、設定ファイルにしてればテストしなくていいって言う奴、意味不明。
違いはコンパイルするかしないかぐらいだろう。

107 ：仕様書無しさん：2007/02/09(金) 19:55:37

>>106
iBatisでは素で出来るし
HibernateもHQLでできるんじゃん？

108 ：仕様書無しさん：2007/02/09(金) 19:58:45

>>106
カラムが増えたりするし、SQL文が分散してないから、
大体ハードコーディングするよりらく。開発中も結構らくだし、
IDEとかの機能と絡めれば、全然ORマッピングのほうが開発が
はやいと思うけど。

言語とか開発環境とか普段どんなんでやってんの？

109 ：仕様書無しさん：2007/02/09(金) 20:03:31

Ｏ／Ｒマッピングが一括更新に向いてないのは作者達も認めているところで
そこはむしろ、SQLによる更新やストアドプロシジャなどとの併用を勧めている。
全てがオブジェクトで処理できないから使えないという考えは柔軟性に欠ける
のでは？　保守性や開発効率を考えて適材適所で使い分ければいいと思う。

それと、他のＯ／Ｒマッピングがどうかはしらんが、例えば、Hibernateは
結合も関数も使える。1対1、1対多、多対多全てがオブジェクトにマッピング
される。

110 ：仕様書無しさん：2007/02/09(金) 20:31:35

文字列連結すんなって.....
じゃあどうやってSQL文を作れば良いんだよ。

111 ：仕様書無しさん：2007/02/09(金) 20:38:02

行間を読んでくれ・・・

112 ：仕様書無しさん：2007/02/09(金) 21:14:29

股間を揉んでくれ・・・

113 ：仕様書無しさん：2007/02/09(金) 22:03:06

つω

114 ：仕様書無しさん：2007/02/09(金) 22:09:25

保守性や開発効率を考えたら
DBの変更や仕様が変わったときに
XMLファイルとDBとソースの3箇所をいじらなきゃならないORマッパーなんて
ありえないだろｗ

115 ：仕様書無しさん：2007/02/09(金) 22:18:13

とりあえずJava系から出てきたものって全部糞

116 ：仕様書無しさん：2007/02/09(金) 22:26:57

RDB(≒SQL)とオブジェクト指向の相性の悪さはよく言われている。

117 ：仕様書無しさん：2007/02/09(金) 22:28:07

DBのメタ情報読んでXMLとクラスを自動生成するツールあるけど。

118 ：仕様書無しさん：2007/02/09(金) 22:30:09

でも普通はXMLを保守して、クラスの生成とＤＢの更新ってパターンだな。

119 ：仕様書無しさん：2007/02/09(金) 22:40:50

糞、糞、言うだけで、それがどうして糞なのかの理由を書き込まない奴は脳みそが少し足りないんじゃないかと真剣に思う。

120 ：仕様書無しさん：2007/02/09(金) 22:46:00

>>117-118
なんかプログラムのためのプログラムやっている気分だな。

121 ：仕様書無しさん：2007/02/09(金) 22:50:08

ﾊｲﾊﾞﾈｲﾄ使わせたら
見事削除対象のレコード数分だけselectとdeleteを実行する実装されてたよ…(´・ω・｀)

もう尻拭いばっか

122 ：仕様書無しさん：2007/02/09(金) 22:58:24

プログラミングが楽しくない

それだけで糞

123 ：仕様書無しさん：2007/02/09(金) 23:00:21

Pro*Cならmakefileにプリコンパイルを書いてリンクするライブラリを追加するだけ。
OCIならプリコンパイルもいらない。

フィールドとやり取りする単調なコードを書くのがコード生成スクリプトを作ればよろし。

なんでいちいち保守性の落ちるようなことをするのか理解できんわ。

124 ：仕様書無しさん：2007/02/09(金) 23:40:13

時々不思議に思うんだけど，ORマッピングツールを導入するメリットで詠われる，
DBを変更したら～って下り．
DBってそんなに変えるもんなの？
設定ファイルを書き換えるような気楽さで変わるようなもんじゃないと思うんだけど．
最近はOracleやSQLServerも開発用に無償で使えるバージョンも整ってることだし．

125 ：仕様書無しさん：2007/02/10(土) 00:02:39

>>118
それって、運用段階でどれだけ地獄になるかわかってる？特にDBの更新

126 ：仕様書無しさん：2007/02/10(土) 00:05:27

んでデグレるんだな。
Pro*Cだってmakefileにプリコンパイルを書いてないバカのおかげで時々あるけどさ。

127 ：仕様書無しさん：2007/02/10(土) 00:09:13

＞見事削除対象のレコード数分だけselectとdeleteを実行する実装されてたよ…

ｶｺｲｲ＾＾

128 ：仕様書無しさん：2007/02/10(土) 00:15:34

>>125
運用段階でＤＢを変更する事態になったら、どんなやり方しようが影響はあると思うが・・・

129 ：仕様書無しさん：2007/02/10(土) 00:22:34

うちの会社のPL/SQLプロシージャは
最初にテーブルをことごとくDROPして
CREATEしなおしてから処理しだす

理由は断片化の問題とかもあったらしいが
テーブルが無いとプロシージャのコンパイルが通らないのが気に入らなかったらしい
コボル野郎が作るSQLプログラムは意味わかんねえ

130 ：仕様書無しさん：2007/02/10(土) 03:30:59

ビルド時にSQLとコードを結合するライブラリとかはどうなの

131 ：仕様書無しさん：2007/02/10(土) 09:20:16

フィールド変更っていうシナリオがそんなに発生しないんだけど、
そういうのが発生したとして
ハードコーディングされたSQL文のフィールド名を探して置換してコンパイルし直すのと、
XMLファイルをいじってorツールでxmlとクラスを自動生成してコンパイルしなおすのと
そんなに変わらない気がする

132 ：仕様書無しさん：2007/02/10(土) 10:03:19

>>131
例えば、先週実際にあったこういう仕様変更とか、

取引先マスタ
取引先コード,取引先名,郵便番号,住所,担当者・・・

を

取引先コード,取引先名,郵便番号,住所,営業担当者,製造担当者・・・

にする。

133 ：仕様書無しさん：2007/02/10(土) 10:24:08

>>132

>>131とは、別人だが、
その場合だと、
ORマッパーーの場合

変更は、XMLとデータコンテナクラス

DaoにSQL直記入の場合

Daoとデータコンテナクラス

でほとんど変わらないと思うんだが

むしろ営業担当とか製造担当のデータが
新規作成するテーブル上にある場合
加えて新しくXMLファイルとデータコンテナを作らない
とならないので、かえって、面倒だと思ったことがある。

134 ：132：2007/02/10(土) 11:08:55

どうやっても食えない例として挙げてみた。

こんなケースは、ORマｯパーとSQL直記入と両方使っていようものなら、
変更箇所がそうとう増える。

135 ：仕様書無しさん：2007/02/10(土) 11:17:15

ORマッパだけで済むなら
ORマッパ周りだけの修正で済むけど
現実にはSQL直記入しているんだから
変更部分はORマッパ周りとSQL直記入部分

ORマッパの分だけ手間増えてるじゃん

136 ：仕様書無しさん：2007/02/10(土) 11:34:23

フィールド変更はメンテの想定外なんだよ

137 ：仕様書無しさん：2007/02/10(土) 12:10:34

ソースとXMLの両方修正するのうぜ。
どっちみちソースは修正しないといけないだろ

138 ：仕様書無しさん：2007/02/10(土) 12:17:32

XML自体の書きやすさというか保守性も疑問だ？
同じ内容を全部JavaなりC++なりで書いた方が
わかりやすくねぇか？

139 ：仕様書無しさん：2007/02/10(土) 13:03:11

XMLの保守に疲れたあなたに、一服の清涼剤を・・・
つ Ruby on Rails

140 ：仕様書無しさん：2007/02/10(土) 13:13:13

それはないｗｗ

141 ：仕様書無しさん：2007/02/10(土) 13:28:22

新規のDB設計なのに、未だに自然キー（特に複合キー）を主キーにしてる仕様書を
よく見るんだけど・・・。頭の固いコボラーかな。
その設計書渡された人の苦労も想像できず、これで一仕事終えた気になってんだろうな。

142 ：仕様書無しさん：2007/02/10(土) 13:31:32

そろそろ割り切りたいと思っているあなたに、
つ Ruby on Rails

143 ：仕様書無しさん：2007/02/10(土) 13:33:31

人工キーを主キーとすべきだよね

144 ：仕様書無しさん：2007/02/10(土) 13:41:24

なんでもかんでも人工キーってのもあれだけど、なんでもかんでも自然キー
ってのは頭悪すぎる。ＳＱＬが無駄に長くなりやすいし、ＯＲＭには当然向かない。

145 ：仕様書無しさん：2007/02/10(土) 14:08:07

>>141
むしろ、Coboler の方こそ「採番癖」が強いと思うのだが・・・
自然キーを上手く拾い出せるのならば、それに越したことはない。
（この「ならば」の見極めが難しいのだが）

必要もないのに無駄な属性を作り出すのは下手のやること。

146 ：仕様書無しさん：2007/02/10(土) 14:21:13

ORMはサービス層を保護するためにやるのが目的
メンテがどうとかいってる奴は頭わるすぎ。

147 ：仕様書無しさん：2007/02/10(土) 14:22:04

>>145
いつの話してる。そんな時代はとっくに過ぎ去った。

148 ：仕様書無しさん：2007/02/10(土) 14:24:23

自然キーは読んで字のごとく自然と目の前に提示されている。それを見出し、
キーに設定する能力は別にいばるほどのものではない。
>>145はＯＲマッパーを使ったことないだろ？

149 ：仕様書無しさん：2007/02/10(土) 14:29:42

テーブルには必ずGUIDカラムを作るのが
一般的だっつーの

150 ：仕様書無しさん：2007/02/10(土) 15:13:56

それをいうならサロゲートキーだろ
GUIDはその実現方法のひとつ

151 ：仕様書無しさん：2007/02/10(土) 15:19:19

>>121
HQLでなんとかならんかったのか？

152 ：仕様書無しさん：2007/02/10(土) 15:54:24

データの寿命は業務より長く、いま一意な自然キーは「たまたまそうなってる」だけだ罠

153 ：仕様書無しさん：2007/02/10(土) 16:03:00

複合キーの弊害はいろいろあるが、俺が特に面倒臭く思うのは、データリストの
特定のデータを特定したり、htmlのselectのvalue値をどうするかで余計な頭を
つかわされる時だな。

154 ：仕様書無しさん：2007/02/10(土) 16:27:50

>151
当然HQLを使うべき処理なんだがそれを使っていなかったんだよ…

ソースレビューなんてやる時間なかったから
性能試験でようやく発覚…

ソースを見て愕然としたわけですよ

155 ：仕様書無しさん：2007/02/10(土) 16:47:31

Visual Studio 2005のDB関連ウィザード類ってお前らから見てどうですか

156 ：仕様書無しさん：2007/02/10(土) 17:19:14

なにこれ！？って感じ

157 ：仕様書無しさん：2007/02/10(土) 17:26:23

>>155
じゅんってきちゃいました

158 ：仕様書無しさん：2007/02/10(土) 17:34:57

つかﾊｲﾊﾞﾈなんか使わせるほうがアホだろ

159 ：仕様書無しさん：2007/02/10(土) 17:47:42

頑なに複合キーを主キーにしたがるレガシーな脳みその持ち主のみなさん。
ttp://ja.wikipedia.org/wiki/%E4%B8%BB%E3%82%AD%E3%83%BC　の「主キーの選択」
のとこ読んで、脳みそをもちょっと活性化させなさい。

160 ：69式フリーPG ◆hND3Lufios ：2007/02/10(土) 18:11:45

MFCのCRecordsetだってウィザードだけでは使いにくいんだよな。

161 ：仕様書無しさん：2007/02/10(土) 18:58:46

俺この前マスターメンテの変更画面で主キーが変更可能な仕様書みたよ。
ま、外部キーとして使われてないフィールドだったからよかったけどおっかねぇよ。

162 ：仕様書無しさん：2007/02/10(土) 19:52:36

>>1

XMLバインディングしろってことか？

よく共通クラスとかいって使っている奴いるけど、結局ハードコーディングなんだよな。
多少重くなるが後々のメンテを考えるならXMLバインディングがデフォ

163 ：仕様書無しさん：2007/02/10(土) 19:54:56

XMLは、糞

164 ：仕様書無しさん：2007/02/10(土) 22:33:48

素朴な疑問
ここを読んでるとXML嫌いなやつは多そうなんだが
そういうやつはそれなりに構造を持ったデータを何で記述してるんだ？
構造を持ったデータを記述する統一記法としては
まずまずなんじゃないかと思っているんだが

統一が甘い部分がある(attributeの書き方とか構造の展開方法とか...)
とは思うけどよりよい手段はあるのか？

165 ：仕様書無しさん：2007/02/10(土) 22:35:53

つ YAML

166 ：仕様書無しさん：2007/02/10(土) 22:38:51

・ハードコーディング >2
・あらゆるSQLはテキスト >4
・300行位使ってSQL成形 >8
・リソースに突っ込んだり >15
・DAOとかO/Rマッパーとかそういうの >18
・ストアド >30
・パラメータ受け取ってSQL文を生成するライブラリを書いてお茶を濁す >35
・テーブルと対になるデータ用のクラス用意する >40
・SELECT文はXMLからロード＆更新系は動的生成 >51
・これからの時代ORM >61
・toruqueを使えばSQLなんて書かなくていいよ >66
・テーブルのvarchar項目にSQL断片を入れておいて >73
・ADO.NET >76

167 ：仕様書無しさん：2007/02/10(土) 22:42:44

>>164

Java使いなんでJavaのコードだな、
結局コード上に書いて行くのが最良だと思う。
オブジェクト指向のデータとその操作をオブジェクトに
するという面からも正しいし。

168 ：仕様書無しさん：2007/02/10(土) 22:50:12

>>167 排他もトランザクションも自前で実装すんの？

169 ：164：2007/02/10(土) 22:50:40

>>167
言語も環境も閉じてる時はいいけどさ
たとえばWeb Service系だと外とやりとりしないといけないよな
そう言うときはどうする？

170 ：仕様書無しさん：2007/02/10(土) 22:53:52

データの受け渡しのXMLはいいよ思うよ。

171 ：仕様書無しさん：2007/02/10(土) 23:00:47

別にXML自体を叩いてるわけじゃないと思うんだが…

172 ：仕様書無しさん：2007/02/10(土) 23:04:34

つ >>163

173 ：仕様書無しさん：2007/02/10(土) 23:04:57

>>168

データの話なんで、的外れな意見だな。

>>169

正直そのケースは考えてなかったな。
プログラムでXMLを生成して、
プログラムでXMLを読むようなケースでは、
XMLで問題無いと思う。

174 ：仕様書無しさん：2007/02/10(土) 23:05:46

>>168
？言ってる意味がよく分からんな。

XMLとトランザクションや排他は関係ないだろ。

175 ：仕様書無しさん：2007/02/10(土) 23:18:45

詳細設計書に決めたれた形式に沿って書くのは大変だったな
vbaのマクロとかで

176 ：仕様書無しさん：2007/02/10(土) 23:23:39

俺もYAMLに一票

177 ：仕様書無しさん：2007/02/10(土) 23:28:44

今見てみたけどYAML良いなぁ
これなら、許せるかも

178 ：仕様書無しさん：2007/02/10(土) 23:59:40

やーむるっていうの？

179 ：仕様書無しさん：2007/02/11(日) 00:44:52

昔、西城秀樹が歌ってたなぁ

180 ：仕様書無しさん：2007/02/11(日) 00:53:02

xml 自体はいいです。
既にパーサーあって、自前でつくる必要も、
わけのわからないものを使う必要ない。

181 ：仕様書無しさん：2007/02/11(日) 00:58:40

>>180
コボラと同じ思考パターンだな

182 ：168：2007/02/11(日) 01:03:28

>>173-174
いや俺はてっきり（XML使わない＝ＯＲＭ使わない）のつもりで
いたもんだから・・・
余計なお世話かもしらんけどＯＲＭ使うと設定でできちゃうもんで。

183 ：仕様書無しさん：2007/02/11(日) 01:15:55

XML自体は可搬性が高くて優れてはいるが
Parserはどれもこれももうちょっとどうにかならんかな。
XMLの記述がどうとでもなることが災いして、
シンプルなものにはなりづらいのはわかるが、非常に手間だ。

184 ：仕様書無しさん：2007/02/11(日) 01:46:15

排他はともかく、トランザクションの規約による自動化はORMじゃなくてAOPの範疇じゃね？
ハイバネとかもSpringと組み合わせることによって実現するしさ。

185 ：仕様書無しさん：2007/02/11(日) 02:16:26

Webサーバのフィルタでもできるべし。

186 ：仕様書無しさん：2007/02/11(日) 02:25:22

今の世の中いつの間にか猫も尺由美子もＸＭＬだな。

187 ：仕様書無しさん：2007/02/11(日) 02:26:35

>>185
そのパターンはやるなってのが一般的な見解になりつつない？

論理的にHTTPのリクエスト自体とビジネスロジック、DBトランザクションの
範囲は一致しないし。

なんかどっかに記事あったような。IBMなんかの。

なによりフィルタでやると、ネットワーク系のI/Oの時間がさらにボトルネックとして追加される。

188 ：仕様書無しさん：2007/02/11(日) 02:52:19

でも、Webアプリの場合、HTTPリクエスト≒ＤＢトランザクションじゃね？
リクエストを受けてトラン開始、レスポンス返す前にトラン終了ってパタン。
ORMのセッションをWebサーバのセッションに格納してってパタンもよくサン
プルで見るんだけど。一般的な見解とやらはよくわからんが。

189 ：仕様書無しさん：2007/02/11(日) 03:28:28

トランザクションがもっと狭くて済むならそっちの方が良いだろ。
まして、データ自体やモデルからは、トランザクションの範囲は決められないだろうに、
>>168のレスが何を意図するのかさっぱりわからんよ。

190 ：仕様書無しさん：2007/02/11(日) 06:08:20

XMLはぱっと見いい感じに思えるけど
実はいろいろと問題を抱えてる
XMLのｽﾚに行くといい

191 ：仕様書無しさん：2007/02/11(日) 06:21:13

>>190
つーか、ORマッピングの設定ファイルに使って
SQL文書いておくってレベルではXML自体の問題は発生しないだろ。
DTDとかのおかげで設定エラーも文法レベルのは簡単に見つかるし。

192 ：仕様書無しさん：2007/02/11(日) 07:38:23

ORマッピングの場合、ソースとXMLとに、
テーブル構造を書くので、非常に無駄。
後、SQLとソースの関係が煩雑になりがち

193 ：仕様書無しさん：2007/02/11(日) 09:44:01

>>192
ORM使う以上、テーブル構造を意識したソース書いた時点で負け

194 ：仕様書無しさん：2007/02/11(日) 10:07:18

>>193

すくなくても、Hibernateでは、書かないと動かないかったが、
テーブル構造に依存しないコードってどんなコード
カラム名が一切出てこない、Listのみでデータを、やりとりするのかよｗｗｗ
また、どんな方法を使うにせよ、テーブル同士のリレーションを考えにいれず
コードが書けるとは思えないのだが

195 ：仕様書無しさん：2007/02/11(日) 10:13:15

下手な釣りすんなボケ

196 ：java.lang.Map様：2007/02/11(日) 12:09:05

どうやらオレの出番が来たようだな！

197 ：仕様書無しさん：2007/02/11(日) 12:35:18

java.utilに帰れ。

198 ：69式フリーPG ◆hND3Lufios ：2007/02/11(日) 14:26:26

猫も尺由美子

199 ：仕様書無しさん：2007/02/12(月) 01:15:47

結局、JAVA叩きに落ち着いてますねーーーー

200 ：仕様書無しさん：2007/02/12(月) 01:50:26

dbMAGICを触ったことのある俺が来ましたよ。

あれのどこがいいのか未だに分からん。

201 ：仕様書無しさん：2007/02/12(月) 01:53:22

それはない。ｗ

202 ：仕様書無しさん：2007/02/12(月) 20:18:13

>>193
どういう意味でテーブル構造という言葉を使ったのか詳しく
カラム名云々言ってる奴は無視して

203 ：仕様書無しさん：2007/02/12(月) 20:29:11

>>202
DAOより後段は、単なる「オブジェクトの入れ物」と考える。
入れ物の形を気にして、入れるもの（＝オブジェクトモデル）の
形が制約されてしまうのは本末転倒。

204 ：葉猫 ◆Jz.SaKuRaM ：2007/02/12(月) 20:31:19

ここはあえてosqlでバッチ処理。

205 ：仕様書無しさん：2007/02/13(火) 01:04:41

>>204がいいことを言った！！！

206 ：仕様書無しさん：2007/02/13(火) 04:39:50

>>203

でXMLとソースの２箇所に２重に構造が書かれているじゃん
もしDAOがソースでかかれて無い場合は、
すまんが、そう言ってくれ。

207 ：仕様書無しさん：2007/02/13(火) 09:20:52

結局O/Rマッピングは、データベースの代わりに使う物じゃなくて、オブジェクト永続化のためにある。
問題はその使い道がまったくないと言う事だ。

208 ：仕様書無しさん：2007/02/13(火) 11:33:22

仕事のための仕事

209 ：仕様書無しさん：2007/02/13(火) 11:52:40

O/Rマッピングは便利そうなんだが
3テーブル以上の表結合とか簡単なんだろうか

210 ：仕様書無しさん：2007/02/13(火) 12:59:29

結合も関数も使えないって。一括更新も一括削除も出来ないんだから。
キャラクターデータのセーブにぐらいしか使えないよ。

211 ：仕様書無しさん：2007/02/13(火) 13:03:25

結合も関数も普通に使えますが・・・

212 ：仕様書無しさん：2007/02/13(火) 19:07:28

>211
SQLを書かなくていいはずのO/Rマッピングで、なぜか用意されているcreateSQLQuely()を使ってって事か？
それとも誰も見向きもしない独自仕様の、HQLを駆使してって事かな？

213 ：仕様書無しさん：2007/02/13(火) 20:48:21

JDBCで何か問題が？

214 ：仕様書無しさん：2007/02/13(火) 21:23:02

単純に解析や翻訳のオーバーヘッド減らして性能上げたいだけだろ？
今のサーバ性能じゃ仕方ない気がするが

マシン性能が１０万倍速くなってから理想を言うべきだと思うYO
まあ、そうなっても小賢しいチューニングは続くんだろうがな

215 ：仕様書無しさん：2007/02/13(火) 21:39:42

>>212
つ one-to-one, many-to-one, many-to-many

216 ：仕様書無しさん：2007/02/13(火) 21:44:31

>>215

おいおい、、、

レベルの低い解答だな、、、、

おまえなんか２１２の言ってることを理解してないな。

まぁ、２１２もよく知らないで色々言ってるだけなんだけどさ

217 ：仕様書無しさん：2007/02/13(火) 21:59:34

爺が多いなー

218 ：仕様書無しさん：2007/02/13(火) 22:00:14

？？？

219 ：仕様書無しさん：2007/02/13(火) 22:08:08

なあ、テクノロジはどんどん進化しているわけだよ。爺さんたちよ。
自分がやっとこさ身につけた技術が過去のものになる悲しさは理解できるけどさ、
この業界はものすごいスピードで進化してるわけだよ。頑張ってついていかなくちゃ、
アルツハイマーになっちゃうよｗ

220 ：仕様書無しさん：2007/02/13(火) 22:13:06

個人的にはテーブルという概念がもうね・・・

221 ：仕様書無しさん：2007/02/13(火) 22:38:19

もうね・・・そうね・・・なんちゅうーか・・・あれだよ・・・あれ・・・それ・・・アレ？

222 ：仕様書無しさん：2007/02/13(火) 23:06:14

なんつーか、最近技術系のブログを見てて思うのは
若手の単なる思い付きみたいなアイデアがやたらもてはやされて、
「こいつら本当に基礎の技術あってその上でする話はほとんどしてねーよな」
って事だな。

だから、時々凄いトンデモな解法が大手を振ってまかり通ったりする。

それがORマッパとAjax。あとComet。そー感じる。

223 ：仕様書無しさん：2007/02/13(火) 23:32:57

爺晒しage

224 ：仕様書無しさん：2007/02/13(火) 23:55:10

もし、この世に「単なる思い付きでないアイデア」
というものがあるならば、是非教えてもらいたい。

225 ：仕様書無しさん：2007/02/14(水) 00:05:23

アインシュタインの相対性理論とか、そうだろ。
単なる最初は単なる思い付きなんだけど、
そこから磨きこんであそこまで美しい理論になった。

Object思考やLispとかも当時はかなりイロモノだったと思うけど、
時の流れに応じて磨かれて、今やかなりいいものとして市民権を得ている。

それに引き換え、COMやXMLやSOA、Web2.0の浅はかさと言ったら…。

Webだとある「よさげな」思い付きに対して
「こいつはすげえや！」「これぞブレイクスルー！」
みたいな感じで猫も杓子も飛びつくから凄い変なものが
異常に市民権を得たりする。

「僕は最近は年上の経営者なんかより若い人たちと話す事を重視している」
っつージジイ見ると本当にキモイ。

226 ：仕様書無しさん：2007/02/14(水) 00:10:44

＞COMやXMLやSOA、Web2.0
どうだめなのか詳らかにしろや。

227 ：仕様書無しさん：2007/02/14(水) 00:13:35

あと二三年で消える言葉だから黙って見てな。

228 ：仕様書無しさん：2007/02/14(水) 00:15:22

>>225
・・・お前、10代だろ？(w

229 ：仕様書無しさん：2007/02/14(水) 00:16:34

猫も尺由美子

230 ：仕様書無しさん：2007/02/14(水) 00:21:45

XMLも２・３年で無くなるのか。そしたらYAMLに置き換わるかな。

231 ：仕様書無しさん：2007/02/14(水) 00:23:46

>>230
SXMLに置き換わる。

232 ：仕様書無しさん：2007/02/14(水) 00:24:01

>>230
S式に置き換わります。

233 ：仕様書無しさん：2007/02/14(水) 00:28:12

>>209
まずViewを作ろうぜ・・・
亀スマソ

234 ：仕様書無しさん：2007/02/14(水) 00:44:27

>>233

Viewって遅い印象があるんだが、
もしかして、使い方がわるいだけ？

235 ：仕様書無しさん：2007/02/14(水) 00:54:32

VIEWが遅くて、通常のSELECT文の方が速いというのはどういうアレなん？

236 ：仕様書無しさん：2007/02/14(水) 01:05:08

>>234
どこで、遅いかにもよると思うが。

>>235
ヒント：インデックス

237 ：仕様書無しさん：2007/02/14(水) 01:05:29

>>235

アレなんといわれても、事実遅いからしょうがない。

238 ：>>234：2007/02/14(水) 01:15:43

>>236

インデックスのせいだったのか、勉強になった。
俺って素人同然じゃんorz

239 ：仕様書無しさん：2007/02/14(水) 01:16:04

スマートにしようと頑張れば頑張るほど無駄に複雑になっていくのが男の浪漫。

240 ：仕様書無しさん：2007/02/14(水) 01:23:35

速度狙ってＶｉｅｗ使うというケースは、
どっちにしろあまりないような気がする。

Joinは結構DBMSの負荷高い処理だし。

241 ：仕様書無しさん：2007/02/14(水) 01:43:03

>>228
俺もそう思う。Linuxだかなんだかの「はしか」にかかった時期の。

242 ：仕様書無しさん：2007/02/14(水) 01:49:39

インデックスとかの前に実行計画チェックしろと

243 ：仕様書無しさん：2007/02/14(水) 06:20:14

マテビュー使ってスナップショット取れば?

244 ：仕様書無しさん：2007/02/14(水) 09:41:50

AjaxはNetscapeがJavaアプレットとJavaScript、LiveConnectでやろうとしてたことそのものだと思うが、
アプレットは時代の流れに消えてXMLHttpRequestみたいなブラウザ組み込みのオブジェクトが使われてるだけで

245 ：仕様書無しさん：2007/02/14(水) 13:57:01

いつのまにやらXMLHttpRequestなんてのがJSに組み込まれてんのな

246 ：仕様書無しさん：2007/02/14(水) 19:31:03

>216
じゃ結合と関数と一括削除のやり方を教えてくれよ。マジで。ビューとバッチ使った方法以外で。
Hibernate詳しいって自分で言ってる奴はよくいるんだが、一括削除の方法を聞くと消える奴ばかりで、
いまだに一括削除のやり方が分からん。

247 ：仕様書無しさん：2007/02/14(水) 19:35:20

>>246
つーかiBatisは無視ですか、そうですか。

248 ：69式フリーPG ◆hND3Lufios ：2007/02/14(水) 20:36:01

福岡の那の津埠頭にはSOLってラブホがありますが、あれがSQLに見えたときは
休んだほうがいいとオモタ。

249 ：仕様書無しさん：2007/02/14(水) 21:37:17

タケノコのように生えてる銀色の塔を思い出した。

250 ：仕様書無しさん：2007/02/14(水) 23:00:32

どーでもいいが、
strSql = strSql + "～～～"
strSql = strSql + "～～～"
strSql = strSql + "～～～"
以下略　な書き方を解消する方法を開発してくれ。
だるいから。

251 ：仕様書無しさん：2007/02/14(水) 23:04:56

>>250
HibernateTemplate ht = new HibernateTemplate(sessionFactory);
ht.get(Hoge.class, id);

252 ：仕様書無しさん：2007/02/14(水) 23:07:48

>>251
ぐぐったが、、、
情報すくねー（泣
けどさんく～

253 ：仕様書無しさん：2007/02/14(水) 23:20:03

>>250
string sql = String.Format("SELECT {0} FROM {1} WHERE {2}"...);

とか言ったりして……ハハ

254 ：仕様書無しさん：2007/02/15(木) 00:18:33

>>253
さすがにそう書くくらいならPreparedStatementニスル。

255 ：仕様書無しさん：2007/02/15(木) 00:33:24

>>254
そう書かなくてもしろよ！
SQLインジェクションどうすんだよ！

256 ：仕様書無しさん：2007/02/15(木) 00:48:17

>>253
俺ガイルｗｗｗ

257 ：仕様書無しさん：2007/02/15(木) 01:18:58

>>246

http://www.hibernate.org/hib_docs/v3/reference/en/html/batch.html#batch-direct

216じゃないけど、これじゃだめかな？

258 ：仕様書無しさん：2007/02/15(木) 08:48:14

ハイバ使っても
String hqlDelete = "delete Customer c where c.name = :oldName";
みたいなこと書くんだ

へー

259 ：仕様書無しさん：2007/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 ：仕様書無しさん：2007/02/15(木) 21:30:13

>>259

冗長なだけのような･･･

261 ：仕様書無しさん：2007/02/15(木) 21:43:12

冗長大好き<java房

262 ：仕様書無しさん：2007/02/15(木) 23:01:35

>>261
Java周辺の話って庭の草取りに燃料気化爆弾使うようなのばかりだな。

263 ：仕様書無しさん：2007/02/15(木) 23:06:48

一応Javaの方でも反省はあるみたいだけどね。POJOとか。
あとC++みたいに言語自体がでかいのと比べると
ドングリの背比べのような気もする。
Rubyとか流行らないかなぁ

264 ：仕様書無しさん：2007/02/16(金) 00:51:24

C++って言語でかいか？

265 ：仕様書無しさん：2007/02/16(金) 01:13:37

言語仕様が複雑って意味ででかいと言ってるならでかいだろう

266 ：仕様書無しさん：2007/02/16(金) 22:20:05

すぐに言語比較に持っていくんだから・・・

267 ：仕様書無しさん：2007/02/17(土) 02:15:14

SQLとSQLとSQLの比較よろ。

268 ：仕様書無しさん：2007/02/17(土) 18:32:09

ADO.NET使いはこのスレにいるかい

269 ：仕様書無しさん：2007/02/17(土) 20:02:37

おジャバ様のすくつにそんな人いません＞＜

270 ：仕様書無しさん：2007/02/17(土) 20:17:59

>>268
ノ

後輩に何度ヤメレと言っても、>>250のような書き方を改めてくれない。
上司じゃないから強制は出来んしなぁ・・・会社辞めるときﾇｯｺﾛｽ

271 ：仕様書無しさん：2007/02/17(土) 21:58:39

>>270
おまいさんはどういうふうに書いて（処理して）るんだい？

272 ：仕様書無しさん：2007/02/17(土) 23:29:32

>>271
確かに知りたいよなぁ．．．。素のCでSQLのオンコーディングする時、
うちは
strcpy(acSql,
" SELECT"
　" col_a"
　",col_b"
" FROM"
　" sample_table"
" WHERE"
・・・
);
てな感じで埋め込んでるが、もっとマシな手段ないかなぁ。

273 ：仕様書無しさん：2007/02/17(土) 23:35:41

>>272
どんな環境なのか知らんけど、これだとSQLインジェクションし放題じゃない？

274 ：仕様書無しさん：2007/02/17(土) 23:39:07

>>272
少なくともsprintf的な書き方をした方が・・・。
そうすれば、sql文を別ファイルなり、データベースなり、リソースなり、どこにでも置ける。
strcpyとかstrcatでくっつける、ってのはキツイと思うよ。

275 ：仕様書無しさん：2007/02/18(日) 00:07:09

ストアドオンリーってのが一番いいのかな

276 ：仕様書無しさん：2007/02/18(日) 00:12:01

動的に条件が変わる場合のストアドはどう実装すれば……
条件毎にストアドつくる？

277 ：仕様書無しさん：2007/02/18(日) 00:14:41

>>275
以前はそう思ってたが、今はDBに実装載せるのはどうかと思う

278 ：仕様書無しさん：2007/02/18(日) 00:16:44

そういえばVBのプログラムで
1.Accessのmdbファイルを一個用意
2.mdbファイルにリンクテーブル作りまくり
3.クエリも作りまくり（パラメータクエリ・更新クエリetc）
4.VBからmdbのクエリ呼ぶ
っていうのを見たことがあったなあ。
クエリでOracleとSQLServerとMySQLを連結したりとか。

279 ：仕様書無しさん：2007/02/18(日) 00:18:45

>>276
WHERE句とかの話なら、パラメータや引数であかんの？

280 ：仕様書無しさん：2007/02/18(日) 00:19:47

>>278
一時的なデータ編集用ならありかもしれないけど、
恒常的に使うシステムとしては脆弱すぎ。

281 ：仕様書無しさん：2007/02/18(日) 00:20:46

>>277
その心は？
いろんな事情があるかもしれないけど、参考にお聞かせ願いたい。

個人的にはどこに実装してもかまわんと思うけどね。
DBなんてそうそう換えるもんじゃないから、ストアドにぶちこんであとｼﾗﾈでいいんじゃないかなー、なんて。

282 ：仕様書無しさん：2007/02/18(日) 00:23:10

SQLの書かれてるファイルなりリソースと
それを実行するソースが分かれてるのも
良くないと思う。

283 ：仕様書無しさん：2007/02/18(日) 00:25:53

>>280
激しく同意なんだけど病院で使われているという恐ろしい事実

284 ：仕様書無しさん：2007/02/18(日) 00:29:58

>>282
そうか？
個人的には関数の本体コードとそれを呼び出すコードが別ファイルにあるようなモンだと思うんだけど('A`)

285 ：284：2007/02/18(日) 00:34:18

そうでもないような気がして来た

286 ：仕様書無しさん：2007/02/18(日) 10:11:25

動的にwhere句に現れるフィールドを変更したいって事？

287 ：仕様書無しさん：2007/02/18(日) 10:34:02

ストアドはデバッグしづらいから
速度がでないなどの問題がない限り使わないで欲しい。

288 ：仕様書無しさん：2007/02/18(日) 10:51:10

>>287

禿同
使うにしても３０行ぐらいまででお願い。

289 ：仕様書無しさん：2007/02/18(日) 11:16:56

パラメータ使うに決まってるだろうがハゲ学生が

290 ：仕様書無しさん：2007/02/18(日) 12:16:47

一つのシステムで完結するなら良いけど，
Webシステムでオンラインユーザからの更新と，
クラサバのVB製システムから更新が同時に入ったりする
古くて大規模なシステムだと，
結局ロジック部分をストアドプロシージャでまとめるしか無かったりする．

まぁストアドが全般的にデバッグとかしにくいってのは禿同

291 ：仕様書無しさん：2007/02/18(日) 17:58:56

あー
クライアントの種類が１つじゃない場合には有利か

まぁストアドが全般的にデﾉ

292 ：仕様書無しさん：2007/02/18(日) 21:30:02

>>271
SQLはXMLの中に書いて自動生成させてるだよ。（環境がVB.NET＋ADO.NETなもので

準備済みSQL使えというてるのに、
わざわざ>>250のような書き方でSQLインジェクションの穴作ってくれるの…('A`)

293 ：仕様書無しさん：2007/02/18(日) 22:13:48

普通に結合度の高さを判断して高いと思われるほうにくっつけるだよ

294 ：仕様書無しさん：2007/02/18(日) 22:44:46

あー、用意されてんならそれ使うべきだね

295 ：仕様書無しさん：2007/02/18(日) 23:31:46

外部結合とかサブクエリのSQL自動生成出来るの？

296 ：仕様書無しさん：2007/02/19(月) 00:54:28

SQL自体を変えること自体があんまりないような気がするんだが……
ハードコーディングしてもしなくても大差ないんじゃね？

297 ：仕様書無しさん：2007/02/19(月) 01:10:25

>>295
できるけど、できたらそれ使うか？
そういう問題じゃない気が。。

298 ：仕様書無しさん：2007/02/19(月) 01:36:52

複雑なSQLが必要な場面って
大抵システムのボトルネックになるから人力で調整が必須なものなんだよね。

299 ：仕様書無しさん：2007/02/19(月) 07:01:13

SQLで苦労するって
テーブル構成が糞なんじゃないかと

300 ：仕様書無しさん：2007/02/19(月) 18:03:43

データ取得　→　Viewつくって一発
データ更新　→　ストアドつくって一発

ベタでいいじゃん

301 ：仕様書無しさん：2007/02/19(月) 22:31:22

>>300
原則これだよね。

302 ：仕様書無しさん：2007/02/19(月) 22:52:49

だから、Viewは、遅いと（ｒｙ　
ループですな

303 ：仕様書無しさん：2007/02/19(月) 23:13:44

viewならびゅーっといきそうなもんだが

304 ：仕様書無しさん：2007/02/19(月) 23:17:09

viewより手組の方が早いと考えるのは素人

305 ：仕様書無しさん：2007/02/19(月) 23:18:18

>>300
View作って取得すると実際はどのテーブルにどのデータが入ってるのか
ってのが分かりにくいからあんまり好きじゃないんだよなー。

中途半端に計算された値とかも入ってると保守のとき泣ける。

まぁ、結局テーブル設計がクソって所に帰着する事が多いが。

306 ：仕様書無しさん：2007/02/19(月) 23:48:37

viewはorder byできないじゃない。

307 ：仕様書無しさん：2007/02/19(月) 23:50:00

>>306
ｳｿﾂｹ

308 ：仕様書無しさん：2007/02/19(月) 23:54:57

>>300
どういう論理展開なんだ？

309 ：仕様書無しさん：2007/02/20(火) 00:12:27

>>306
SQL自体を勉強しなおしてから出直せ。

310 ：仕様書無しさん：2007/02/20(火) 08:04:32

>>306
神降臨

311 ：仕様書無しさん：2007/02/20(火) 11:37:59

>>298
既存のパッケージ品をカスタマイズして使わされる時も複雑になるね。
汎用機時代のファイル構造をそのままRDBに入れ直（ry

>>302
ビュー遅いか？
元のテーブル構造が悪いと思うが……。
あるいはちゃんと結合できてないとか。

>>305
俺もあまり好きじゃないけど、設計書みればわかるから問題になったことはないなあ。
元テーブルの構造を隠蔽して単純化できるからその点は好き。

>>306
使ってるDB教えてくれ。

>>308
俺も思った。
ビューとストアドを使うのはいいが、ベタ書きする理由にはならんよな。

さてメシ食ってこよう

312 ：仕様書無しさん：2007/02/20(火) 12:41:23

自己主張が強いな。

313 ：仕様書無しさん：2007/02/20(火) 13:48:07

iBatisみたいにSQL外に出てると、後のSQLレベルの
チューニングがDBエンジニアだけでできて楽ちん。

314 ：仕様書無しさん：2007/02/20(火) 15:30:41

それはiBatis使わないとできないのか？

315 ：仕様書無しさん：2007/02/20(火) 16:19:48

>>311
>>308はベタ書きじゃなくて、ベタな（一般的な）手法という意味じゃなかろうか。

316 ：仕様書無しさん：2007/02/20(火) 16:44:22

>>313
DBエンジニアがいればいいけどな。。。

317 ：仕様書無しさん：2007/02/20(火) 18:32:42

社内ルールでストアドはおろかビューも使えません
理由は「俺が知らないから（by上司）」
ORマッピングツールなんて夢のまた夢さ

318 ：仕様書無しさん：2007/02/20(火) 20:31:32

それは正しい

319 ：仕様書無しさん：2007/02/20(火) 22:04:29

>>317
ストアドはまだ許す。代替手段があるし、知らん言語は知らんだろうと。
だが、Ｖｉｅｗ程度で投げるな。orz...

320 ：仕様書無しさん：2007/02/20(火) 22:21:35

viewってテーブル構成が糞だと
updateできなかったりなんだりでもうﾜｹﾜｶﾒじゃん

だから使わないほうがいいのさそう言う会社では

321 ：仕様書無しさん：2007/02/20(火) 22:31:17

ハードコーディングならハードコーディングで統一してほしかったな、ウチのプロジェクト……
いろんな手法が混ざってんのは最悪だよ。
ハードコーディング派の中でも>>250みたいな書き方する奴とプレースホルダ使う奴と……

スマン愚痴になってしまった

322 ：仕様書無しさん：2007/02/20(火) 22:36:54

>>321
俺のかかわったプロジェクトにいたっては、
そのほかに、長文Viewを書く奴と、ストアドでカーソル駆動する奴と、
何を狂ったか、RecordSetを一旦テキストファイルに落として操作する奴が
いたわけだ。

323 ：仕様書無しさん：2007/02/20(火) 23:19:53

＞RecordSetを一旦テキストファイルに落として操作する奴

それはさすがにネタだろ？

324 ：仕様書無しさん：2007/02/20(火) 23:35:02

>>323
ワークテーブルならぬワークファイル、しかも固定長だよ。
奴がコボラだったから、テキストファイルを操作するほうが具合よかったそうだ。

325 ：仕様書無しさん：2007/02/21(水) 05:47:32

どうりでウチのシステムのcronにrm -rf /var/hogehogeとか入ってるわけだ

326 ：仕様書無しさん：2007/02/21(水) 07:33:17

>>324
おつかれ

327 ：仕様書無しさん：2007/02/21(水) 11:54:04

>>317
うちも全く同じだったので､上司と血を見るほどの大げんかをしてしまった。
こちらが完全に理論武装してパフォーマンス比較までレビューしたせいか、涙を浮かべて逆ギレされた。
しまいには「その比較実験は完全に捏造だ！」とまで言われ､そのせいで処分まで受けてしまった｡

328 ：仕様書無しさん：2007/02/21(水) 12:10:58

>>327は実にバカだな。

329 ：仕様書無しさん：2007/02/21(水) 12:25:41

>>327
馬鹿かぁーーー！！
お前かーーーー！！

あのあと大変だったんだぞーーーー！！！

そういうときはだな、先輩と上司と一緒に
内々で三人で先にレビューしてだな、上司に
提案させるんだよ！！！！

もう、未だにお前の件で俺が色々やってんだぞーーー！！

まぁ、次ぎ合った時に風俗おごってくれ。

330 ：仕様書無しさん：2007/02/21(水) 12:28:58

>>327
バカな奴だ。329が正解だよ。

331 ：仕様書無しさん：2007/02/21(水) 12:49:12

>こちらが完全に理論武装してパフォーマンス比較までレビューしたせいか、
何が嬉しくてここに書き込るのか知らんが、上司の顔を潰すことを目的にプレゼンしたんだろ。
逆切れしてるのは>>327じゃないの？
ここまで空気を読めないヤツよりは、>>322の一番最後のコボラの方がマシな気がする。

332 ：仕様書無しさん：2007/02/21(水) 14:11:44

ケンカはダメ！みんな仲良くしよ♪

333 ：仕様書無しさん：2007/02/21(水) 15:05:58

アホ上司は、アホだが上司だからな
理論武装と同じ程度の会社組織を壊す覚悟が必要だったな

334 ：仕様書無しさん：2007/02/21(水) 15:09:40

こういうやつは客に対しても同じことしそうだ。
購入した備品にけちつけてみたり。

335 ：仕様書無しさん：2007/02/21(水) 15:53:57

327の能力は評価するが
一緒には仕事したくないタイプ

336 ：仕様書無しさん：2007/02/21(水) 16:28:25

>327の人気に嫉妬

337 ：仕様書無しさん：2007/02/21(水) 17:04:57

ひあああああっ……！あああン！もうっ、もうダメぇ……！イっちゃう……！イっちゃ
う、イっちゃう、イっちゃう、イっちゃあひいいいいいいいいッ！イくうっ！そんなにされ
たらすぐイっちゃうよぉーっ！ああああああ！イク、イク、イク、イク、イク、イクッ！あ
っ、熱いい～ッ！ああああああ！イクうッ！イクイクイクイクっ！イクうううううううううう
う～！あああああああぁ……！あうっ……ああああ……イクう……あひいいいいいい
いぃ……！はへええええ！イグっ！イグうっ！イグイグイグイグ！イグーッ！あへ！
はへえっ！ひゃひいいいい！に、妊娠しちゃうっ！妊娠しちゃうううゥ～！気持ちイイ
ぃ～！妊娠キモチイイよぉ～！ああああああああ！妊娠しながらイグう！イグっ！イ
グうっ！イグうぅーっ！

338 ：仕様書無しさん：2007/02/21(水) 17:09:39

こんなところにまで任豚の魔の手が・・・！！
>>327はスレタイはとっとと氏ね

339 ：仕様書無しさん：2007/02/21(水) 17:23:23

これが世に言う「コミュニケーション能力の欠如」というやつかね。

340 ：仕様書無しさん：2007/02/21(水) 17:34:07

とっとさんって誰？

341 ：仕様書無しさん：2007/02/21(水) 18:37:41

まあそれまでにもいろいろあったんだろうよ
そこまで327を叩くなって
もっとまったりいこうぜ

342 ：仕様書無しさん：2007/02/21(水) 21:44:44

>>341
ま
　こ
　　と

343 ：仕様書無しさん：2007/02/22(木) 01:26:31

いま動いているシステムにバグが大量発生していてソースを色々見てるんだけど、
ガチガチにハードコーディングされてる上にDB構造の更新と整合性がとれていない・・・orz
すでに動いているからあんまり変えたくないんだけど、
やっぱりハードコーディングのままいく・・・のが無難かな？

え？上司や先輩に相談？
SQLとVBわかる人いないんですが・・・

344 ：仕様書無しさん：2007/02/22(木) 12:15:22

>>343
SQLやVBのコードを相談するんじゃなくて、

「ハードコーディングされてて更新と整合性がとれてないんですけど、これに合わせたほうがいいですか?
ちゃんと作り直すとバグは減ると思いますけど○○日くらいかかって、工数は××くらいになりますけど、
これってお客さんから保守で取れますか?」

とかを相談すればいい。

345 ：仕様書無しさん：2007/02/22(木) 13:00:26

>>344
おれは客の時は
そんなん、最初の時に全部しっかり言質とって設計確認してあるし
しかも、やってますっていってソースレビューさせてくんなかったよな！
って毎回言ってやってる。

だいたい半額以下に値切ります。保守費用俺が取ったりw

346 ：仕様書無しさん：2007/02/22(木) 16:08:39

>>345
納品物にソースが入っていればそういうことは言えなくなるし
実際に工数がかかるわけだから、イヤなら他に言ってください、で交渉決裂ってだけだね。

347 ：仕様書無しさん：2007/02/22(木) 16:23:51

>>346
まぁ、うち社長が経済ヤクザだからなw

348 ：仕様書無しさん：2007/02/22(木) 16:27:19

>>347
俗に言う「不良顧客」ってやつだな。
金払いが悪いなら用はないな。

349 ：仕様書無しさん：2007/02/22(木) 16:53:43

>>343
漏れの経験上、余程単純なシステムでない限り、
下手に修正を入れると、ドつぼにはまると思ひまふ。

触らぬ神にたたり無しです。

350 ：仕様書無しさん：2007/02/22(木) 17:03:45

技術者としては綺麗さっぱり修正したいが、ワーカーとしてはそんな金にならねえ癖に大変な事はやってる暇ねえと言う現実だ

351 ：仕様書無しさん：2007/02/22(木) 18:03:31

そういう意味ではハードコードは色々便利だなw

352 ：仕様書無しさん：2007/02/22(木) 18:08:02

>>351
どういう意味だw

353 ：仕様書無しさん：2007/02/22(木) 18:56:12

言ってみたかったw

354 ：仕様書無しさん：2007/02/23(金) 01:23:29

ハードコーディングをSQLServerで
パラメータ部分を　'　を　''　に変換してたら
SQLインジェクションなんて全然関係ない
ハードコーディング万歳

355 ：仕様書無しさん：2007/02/23(金) 07:31:33

エスキューエルハードコーディング
相手は死ぬ

356 ：仕様書無しさん：2007/02/23(金) 07:34:02

ハードコーディング自体を嫌うのは、
コンパイラーが死ぬほど、遅かった時代の爺だけだと思われ。

357 ：仕様書無しさん：2007/02/23(金) 07:40:07

インデックス張るの忘れてたw
特に何も言われないので、バージョンアップのたびに小出しにしてやろう。

358 ：仕様書無しさん：2007/02/23(金) 08:18:36

SQL外出しのなにが嬉しいのかさっぱりわかんね。
中出しで十分。

359 ：仕様書無しさん：2007/02/23(金) 08:56:58

ビジュアル的には外出しの方が萌えね？

360 ：仕様書無しさん：2007/02/23(金) 11:14:40

中出しの方が自然だろ

361 ：仕様書無しさん：2007/02/23(金) 14:23:41

>>5
外に出しても大差ないだろ

362 ：仕様書無しさん：2007/02/23(金) 14:51:17

ちゃんとつけないとな。

363 ：仕様書無しさん：2007/02/23(金) 15:03:05

いい流れですね

364 ：仕様書無しさん：2007/02/23(金) 17:26:49

市販のプロテクトを信用してると
穴が開いてることがあるぞ。

365 ：仕様書無しさん：2007/02/23(金) 17:53:44

お前ら、中出しだの外出しだの穴だのいい加減にしろよ

366 ：仕様書無しさん：2007/02/23(金) 18:18:35

要するに、>>365はお口に出して欲しい。ということだな？

367 ：仕様書無しさん：2007/02/23(金) 19:27:58

>>343
これ見て思い出したんだが、昔、とんでもないシステムの改修させられたな。

当時アクセス２０００がすでに主流の時代にアクセス２．０だかなんだかで作られた
システム（そのこと自体は別にいいんだが）で、

なんか日付がずれるっつーからソースを見てみたら、
全ての月が３１日である、という前提でソースが書かれていた。
そりゃお前、１月や３月はいいが、２月や４月になるとズレるわな。
その他いろいろなバグ、バグ、バグ・・・

こんなもんどう考えても修正不可ってんで、結局その改修はウヤムヤになった。

368 ：仕様書無しさん：2007/02/23(金) 21:42:24

>>367
似たようなので、「全ての年は月曜から始まる」って前提のソースがあったw

369 ：仕様書無しさん：2007/02/23(金) 22:57:33

なんつーか、単なるアホなんじゃなかろうか

370 ：葉猫 ◆Jz.SaKuRaM ：2007/02/23(金) 23:51:53

SQLだと曜日や日にちの計算が楽でいいけど、ここはあえてZellarの公式で曜日を求めてみるテスト

371 ：仕様書無しさん：2007/02/24(土) 00:04:02

何のDBか忘れちゃったけどさ、
CとかC＋＋のソースに直にSQL書いて
独自のプリプロセッサで変換するやつがあったな。

struct hoge h;
SQLBEGIN
h = SELECT COL1,COL2,COL3 FROM Table1
SQLEND

見たいな。
展開すると普通にAPI+SQL文字列なソースになるだけだけどな。
なんか糞懐かしくって泣けて来たよ。

372 ：仕様書無しさん：2007/02/24(土) 00:11:12

Pro*Cには似てないな

373 ：仕様書無しさん：2007/02/24(土) 10:31:51

何が嫌ってPro*C嫌いだなぁ。

374 ：仕様書無しさん：2007/02/24(土) 10:37:32

Javaがある今、Pro*Cの存在意義ってないな

375 ：仕様書無しさん：2007/02/24(土) 14:50:23

>>367
それ、SQL関係なくねw？

376 ：仕様書無しさん：2007/02/24(土) 16:18:53

Javaさえあれば何もいらない人は思考が停止してるよね

377 ：仕様書無しさん：2007/02/24(土) 16:23:21

Pro*C/C++ は C に埋め込むにはいいんだが
C++ に埋め込むととたんにがっかりするからな。

>>376
Java厨の知能レベルじゃそんなもんだろう。
ところで Pro*COBOL の存在意義（ｒｙ

378 ：仕様書無しさん：2007/02/24(土) 20:11:46

プロジェクトでﾊｲﾊﾞﾈ使おうということになったらしいが、使える人がいないらしい

379 ：仕様書無しさん：2007/02/24(土) 20:17:17

ハイバネなんて使っていいことないよ

380 ：仕様書無しさん：2007/02/24(土) 20:21:02

上の方で大絶賛してる奴がいるぞ

381 ：仕様書無しさん：2007/02/24(土) 20:26:21

メリット・デメリット・向き・不向きをわかって
総合的判断で取り入れるのならいいけどね。＞ハイバネ
無条件で大絶賛とか、使える人もいないのにとりあえず使ってみようでは
いいことがあるわけない。

382 ：仕様書無しさん：2007/02/24(土) 20:36:25

lazyロードとかトランザクションとか
気を使うとこが、かえって増えるから
個人的にはハイバネは、嫌いだな。
PJ内に詳しい人がいれば別なのかもしれんが。

383 ：仕様書無しさん：2007/02/24(土) 21:46:12

>>382
>PJ内に詳しい人がいれば別なのかもしれんが。
黒船願望ｷﾀ━━━━(ﾟ∀ﾟ)━━━━ !!!!!

384 ：仕様書無しさん：2007/02/24(土) 21:54:05

C/C++ならだまってOCI

385 ：仕様書無しさん：2007/02/26(月) 21:35:42

データ検索機能を実装するときみんなどうしてるのかな。
データの持ち方にもよるんだろうけど、俺は（というかプロジェクトでは）
SQLを動的に生成して投げてしまう。

386 ：仕様書無しさん：2007/02/26(月) 21:50:24

それ以外に方法が？

387 ：仕様書無しさん：2007/02/26(月) 22:25:15

入力された検索条件をテーブルにいったん落として、
それをSelectで拾ってさらにSelect。全検索のログも残って便利。

388 ：仕様書無しさん：2007/02/26(月) 22:41:56

言語、データ量、やりたい処理にもよるんでないの。

複雑なら、ストアドでカーソルとってループしたり。

389 ：仕様書無しさん：2007/02/26(月) 22:53:27

先生！
動的な生成はハードコーディングに入りますか？

390 ：仕様書無しさん：2007/02/26(月) 23:25:43

動的ってダイナミック？
オンザフライ？

391 ：仕様書無しさん：2007/02/26(月) 23:32:54

動物的

392 ：仕様書無しさん：2007/02/26(月) 23:58:26

RDB使う以上Javaよりも低レイヤの言語使ってもあんま意味無いよね。
いくら頑張ってもけっきょくDBのボトルネックが問題になるし。

393 ：仕様書無しさん：2007/02/27(火) 01:16:12

RDB使う以上どんな言語使ってもDBのボトルネックが問題になるし。

あれ？

394 ：仕様書無しさん：2007/02/27(火) 20:53:19

Java使う以上JavaVMがボトルネックになるよね＾＾

395 ：仕様書無しさん：2007/02/27(火) 22:41:30

それいじょうにRDBのボトルネックがでかいって言ってるんじゃねぇの？

396 ：仕様書無しさん：2007/02/27(火) 22:54:00

いくらがんばってもRDBがボトルネックになるんだったらJava使っても使わなくても変わんないんじゃ・・・

397 ：仕様書無しさん：2007/02/27(火) 23:28:17

Java言いたいだけかと

398 ：仕様書無しさん：2007/02/28(水) 00:20:03

つまり、RubyとかPHPとかJavaとか、実行速度が遅い言語でもいいって事じゃね？
Cとか実装に時間がかかる＆ナーバスな言語にこだわる必要は無いって事を言いたいんだと思われ。

399 ：仕様書無しさん：2007/02/28(水) 00:26:48

どうでもいいけどサーバサイドのJavaは全く遅くないどころか、
スケーラビリティとか考えたら現時点では最速だろ。

400 ：仕様書無しさん：2007/02/28(水) 00:36:24

スケーラビティ考えてSQLハードコード

401 ：仕様書無しさん：2007/02/28(水) 01:24:06

JVM立ち上がってれば速いよな

402 ：仕様書無しさん：2007/02/28(水) 01:58:41

>>399
スケールできるだけで最速ではないと思う。
スケールの容易さではLAMPにも迫られてるような気もするし。

403 ：仕様書無しさん：2007/02/28(水) 02:52:19

このスレは、スケールよりも保守性の方の話題なわけだが

404 ：仕様書無しさん：2007/02/28(水) 06:41:21

PHPって結構早いような希ガス

405 ：仕様書無しさん：2007/02/28(水) 08:45:08

>>404
保守性が落ちていくのがな．
マイナーバージョンアップで言語仕様が大幅に変わるのは病めていただきたい．

406 ：仕様書無しさん：2007/02/28(水) 09:54:22

本当に良いモノってのは、変える必要は無いんだよ。

407 ：仕様書無しさん：2007/02/28(水) 10:03:58

Java厨に言えよ

408 ：仕様書無しさん：2007/02/28(水) 19:59:55

確かに単体ではJavaのほうが速い。
しかし、今のところ重厚長大なJavaで作りこんで単体で高速なものを目指すより、
PHPやPerlでさっくり作って、パフォーマンスはロードバランサで稼ぐほうが、
コストも安いし保守も楽。

409 ：仕様書無しさん：2007/02/28(水) 20:00:38

パフォーマンスもあがる。Javaに勝ち目は無いよ。

410 ：仕様書無しさん：2007/02/28(水) 20:05:35

保守楽か？

411 ：仕様書無しさん：2007/02/28(水) 20:47:16

>>408
変態ｗﾊｹｰﾝ

412 ：仕様書無しさん：2007/02/28(水) 21:52:03

PHPは、知らんがPerlの保守は、地獄の悪寒がするよ。

413 ：仕様書無しさん：2007/02/28(水) 21:59:15

言語の違いによる保守性の話はスレちがいだということを理解できない輩がいますね

414 ：仕様書無しさん：2007/02/28(水) 22:01:10

この場合の保守性というのは、少ないJava鯖より大量のPHP/Perl鯖のほうが
再起動などメンテナンスしやすいという意味では

415 ：仕様書無しさん：2007/02/28(水) 22:02:14

PHPはパッケージを使うとORマッパーぽいことも出来るみたいだけどなー。

416 ：仕様書無しさん：2007/02/28(水) 22:33:02

PHPがサックリあたりまでは解るが保守楽かぁ？

仕事だとIBMのIDE(WDSc:Eclipesの商用Ver))使ってるけど、
PHPよりもJavaの方があきらかにサックリ作れるぞ。

それに要件が決まっているなら作りこむ量は一緒だろ。

417 ：仕様書無しさん：2007/02/28(水) 22:36:50

Javaじゃ大量の鯖を導入できないじゃん。WebLogic高くて。

418 ：仕様書無しさん：2007/02/28(水) 22:40:29

Javaとかどうでもいいんだよ
ハードコーディングすること自体はどうなのよ

419 ：仕様書無しさん：2007/02/28(水) 22:43:58

んだ。誰かJava vs LAMPのスレ立ててそっちでやれや

420 ：仕様書無しさん：2007/02/28(水) 22:44:11

ハードコーディングするかしないかは大した問題ではない。

421 ：仕様書無しさん：2007/02/28(水) 22:45:54

>>420
これは上司の一言スレのネタですね

422 ：仕様書無しさん：2007/02/28(水) 23:18:52

ハードコーティングが悪か？って言われてもケースバイケースだろ。

たとえば、ホストがOracleでクライアントがAccessの時に
AccessからSQL投げるのと、Oracleでストアドとどっちかマシか？って話なのか？

423 ：仕様書無しさん：2007/02/28(水) 23:23:34

>>422
それじゃマシも何も、用途が違うじゃねえか

424 ：仕様書無しさん：2007/02/28(水) 23:45:13

Javascriptの保守の方が大変じゃね？

425 ：仕様書無しさん：2007/02/28(水) 23:46:14

ストアドのほうが開発者側の意識として緊張感が違うと思うｗ
感覚的なものだけど

426 ：仕様書無しさん：2007/03/01(木) 00:02:11

400以上のレスをロールバックw

427 ：仕様書無しさん：2007/03/01(木) 00:04:03

>>423
いや、この場合だと用途は同じでOracleにあるデータを
集計してAccessに取り込むって目的だが、
AccessからVBA(ADO)でSQL投げて結果を受け取るか、
ADOでストアド呼ぶか？の違いがあるだけだが。

漏れが提案する以前は、Oracleから全明細読み込んで
Accessで集計していた。

SQLを一切使わないOracleで不思議と感動した。ｗ

428 ：仕様書無しさん：2007/03/01(木) 00:16:17

ケースバイケースは魔法の言葉

429 ：仕様書無しさん：2007/03/01(木) 01:17:01

>>427
そーゆーショボイ用途で使われてるDB鯖に限ってスッペクを奢ってたりするから不思議。

430 ：仕様書無しさん：2007/03/01(木) 02:10:00

わかった！！
１は最近、『ハードコーディング』って言葉を覚えたんだなｗ

431 ：仕様書無しさん：2007/03/01(木) 06:47:49

>>429
正直Oracleはいらん罠。
まあ、元ネタはCOBOLer上がりのヤツが提案したので、
各所でグダグダな設計だった。

データの更新はSQLを一切使わずにCOBOLとロードモジュール？（謎モジュール）
だけで実現していたので、ある意味ここの>>1が喜びそうなシステムではあるな。

漏れは最悪だと思ったが。w

432 ：仕様書無しさん：2007/03/01(木) 09:42:01

>>429
毎回全件取得だと高速なディスクと大量のメモリがないと
まともに使えるようなレスポンスが得られないからなｗｗｗ

433 ：仕様書無しさん：2007/03/01(木) 10:10:21

ストアド知らんだけだろ

434 ：仕様書無しさん：2007/03/01(木) 10:59:17

俺のチンコがソフトコーティングされてます

435 ：仕様書無しさん：2007/03/01(木) 12:32:20

>>434 仕事はいいから包茎手術に逝け。な？

436 ：仕様書無しさん：2007/03/01(木) 13:47:17

しかし、ストアドを乱用する奴もいるよね。

437 ：仕様書無しさん：2007/03/01(木) 15:54:39

>>436
マスタで一覧取得とか1件更新すらも、とにかくDBアクセスストアドっていう
ストアダーに出会ったことがある。

俺の中では、集計とか重い処理なんかの時にストアド使っていくもんだと思ってたんだが･･
他の皆の意見はどうなのよ？

438 ：仕様書無しさん：2007/03/01(木) 16:09:24

重い処理をDBにやらせるのはどうかと思う。

439 ：仕様書無しさん：2007/03/01(木) 16:10:31

>>437
・WebとWin32クライアントが混在や並行稼働している（別々の言語からアクセスする可能性がある）
・ストアドのドキュメントがきっちり分類されて管理されている
ならば可能な限りストアドにしてしまった方がいい場合がある。と思う。

440 ：仕様書無しさん：2007/03/01(木) 19:59:59

ストアドもいろいろな効用があるからなぁ。
あからさまに長い時間がかかる処理はストアドだろうし、
かなり複雑な処理もストアドだろうなぁ。

ただ、DB2とかだとテーブルの統計情報を元にアクセスプランを
組み立てるタイプのだとある程度実務をこなしてから
ストアドにしないと、最適化に無駄が出る気がするので、
最初にいきなりストアド作ってほったらかしはアレかもしれん。

いまどきは人間の最適化よりもRDBMSのオプティマイザーの方が賢いし。

COBOLerがCOBOLでコーティングしたり妙なストアド組むよりも
素直なSQLを投げた方がRDBの性能引き出せる場合もある。

441 ：仕様書無しさん：2007/03/01(木) 20:06:09

>>427
いいなぁ。VPNで運用する要望が出たらリプレースで丸儲けだぜｗ

442 ：仕様書無しさん：2007/03/01(木) 20:22:48

無意味に妙に一貫性のある開発スタイルを採用しているものの方が、
機能追加や保守の際にはまることが多い。
トリッキーなコードをさらにトリッキーにすることで維持するくらいなら
掟を破っても良いんじゃないかと思うオレは若すぎますか？

443 ：仕様書無しさん：2007/03/01(木) 21:44:15

>>442
具体的になんなんだ？

Javaとかでｲﾝﾀｰﾌｪｲｽや継承しまくったクラス設計をﾄﾘｯｷｰに感じてを保守しにくい、とか
VBで１メソッドを何十行もダラダラと長く記述するのを保守しやすい、とか
言うなら、藻前は若いんじゃなくて爺だと思うけど。

444 ：仕様書無しさん：2007/03/01(木) 21:50:14

SQL文をハードコーディングするやつはとっとと引越しー

445 ：仕様書無しさん：2007/03/02(金) 00:37:30

>>437
ストアダーになってみたことはある。
Update系は意外と楽できる。

446 ：仕様書無しさん：2007/03/02(金) 02:27:54

俺の経験だと、コードに対する名前を他のテーブルから引っ張ってくるような部分も
結構、ストアドにすると良い感じだったな。Joinより見やすいし
外部結合時が必要な時も、パフォーマンスが出たように記憶している。

447 ：仕様書無しさん：2007/03/02(金) 15:39:11

隊長！Hibernateとかいろいろ使った結果、1周してJDBCに帰ってまいりました。

448 ：仕様書無しさん：2007/03/02(金) 15:54:15

JSP+Servlet+JDBC最強だよな

449 ：仕様書無しさん：2007/03/02(金) 16:09:56

>>448
あまりに強すぎて、討ち死に続出。

450 ：仕様書無しさん：2007/03/02(金) 17:16:12

JSPよりServletの方がいいだろ

451 ：仕様書無しさん：2007/03/02(金) 20:23:14

詳細テーブルと親テーブルのレコードが1:nの奴にupdateするときとか便利だよね＜ストアド

452 ：仕様書無しさん：2007/03/03(土) 00:05:23

>>448-450
これだからJava厨はきらいなんだ。。。

453 ：仕様書無しさん：2007/03/03(土) 00:11:30

>>452
ごめんな。。

454 ：仕様書無しさん：2007/03/03(土) 00:14:58

>>453
あ、いや、こっちこそ。。

455 ：仕様書無しさん：2007/03/04(日) 00:33:01

ストアドは賛否両論あるとして、
トリガって実務で使ってるか？

俺が趣味でやってる会員制サイト（エロではない）（SQLServer2005）作るときに、
「そういや実務でトリガって使ったこと無いな」と思って、試しに
トリガ使ってみたら便利だった。

退会処理はマスターの該当ID消すだけで、他のテーブルに持ってる
そいつのレコードが全消しとか。

456 ：仕様書無しさん：2007/03/04(日) 00:41:50

>>455
つ参照整合性

457 ：仕様書無しさん：2007/03/04(日) 02:12:14

>>455
使う。便利だ。似たような用途だ。
例えば、新規取引先を登録したときなど。
問題は、あんまり知っている奴が多くないので、メンテで苦労することか。

458 ：仕様書無しさん：2007/03/04(日) 08:24:09

>>455
別アプリと連携させるときに使うよ。
マスタ情報が更新されたら渡す、みたいな。

削除は削除フラグ立てることが多いな。
場合によるけど。

459 ：仕様書無しさん：2007/03/04(日) 10:39:24

>>455
俺の経験ではトリガ使わずに、アプリ側で制御するね。
理由は不明。なんでだろうね。

460 ：仕様書無しさん：2007/03/04(日) 10:57:00

>>459
トリガは便利だが、使い方を間違えると収拾付かなくなるし、
ケースバイ・ケースだろうな。

基本の味付けはアプリでして、調味料的にトリガにすると丁度よい。

しかし、アプリで行うとハードコーディングという問題が発生し、スレタイへ戻る。

461 ：仕様書無しさん：2007/03/04(日) 12:33:12

トリガからストアドを呼び出してスパゲッティ

462 ：仕様書無しさん：2007/03/04(日) 18:17:00

極力ルールはアプリ側に置きたいので使わない

463 ：仕様書無しさん：2007/03/04(日) 19:44:14

ロジックの分離イクナイ

464 ：仕様書無しさん：2007/03/04(日) 20:32:17

トリガは便利だけど、知っている奴が少ないのが難点だな。

(DB2/400は)テーブルをコピーしてもトリガはコピーされないって点を
忘れると悲劇が待ってるし、仕方ないと思うが更新処理のパフォーマンスが
落ちる場合もあるので、使う時は気をつけている。

ロジックの分離と言うかさりげなくアクセスログを取っているって
使い方が多いな。
「このフィールドを更新したの誰だよ？」って感じで。

465 ：仕様書無しさん：2007/03/04(日) 21:41:42

SQLのハードコード云々よりも
・ストアド禁止
・ビュー禁止
・トリガー禁止
のルールを徹底させようとするPM/SEのほうが先に氏んでくれと思う。

466 ：仕様書無しさん：2007/03/04(日) 21:49:15

ビューとトリガーは禁止でいいよ

467 ：仕様書無しさん：2007/03/04(日) 22:01:33

ビューは、遅くて使い物にならん。

468 ：仕様書無しさん：2007/03/04(日) 22:01:38

＞「このフィールドを更新したの誰だよ？」って感じで。

あるあるｗ

馬鹿ユーザが「いじってない！」とか抜かしたときに
本当かどうか調べられるし

469 ：仕様書無しさん：2007/03/04(日) 22:14:55

テンポラリテーブルはありでつか？

470 ：仕様書無しさん：2007/03/04(日) 23:39:56

通常SQL部分はクラスでラップするから、ハードコーディングでいいんでは？
場合によってストアドも使うし、トリガは注意して使えば問題ないし、
ビューもテーブル設計の変更ができない時に仕方なく使う分にはいいんじゃない？

471 ：仕様書無しさん：2007/03/05(月) 00:23:02

>>465
ルールを徹底させるだけマシだとおもう。

好きに使っていいよってプロジェクトの悲惨さに比べたら・・・

472 ：仕様書無しさん：2007/03/05(月) 00:30:12

そうだな。駄目なら駄目としてくれたほうがすっきりする。

473 ：仕様書無しさん：2007/03/05(月) 00:56:19

トリガーは微妙なんだが、ストアドやビューを好きに使われると
ナニか困るのか？

逆説っぽくてアレなんだが、困るストアドを作るやつは
ストアド禁止にしても困るコーティングすると思う。
ビューも同様な。

474 ：仕様書無しさん：2007/03/05(月) 08:17:50

>>467
それはアンタのSQLが悪いだけｗｗｗ

>>473
同意

475 ：仕様書無しさん：2007/03/05(月) 08:27:20

駄目な奴は何をやっても駄目．

最低限，SQLをプログラムの各所に散らばらすのは止めて欲しい．
前に見た奴だと，ボタン押下イベントの中でSQL投げてたのを見たことある．

476 ：仕様書無しさん：2007/03/05(月) 08:42:19

え？普通じゃね？

477 ：仕様書無しさん：2007/03/05(月) 09:02:29

ボタンを押下した後にＤＢ検索にいくなら、
嫌でもSQL投げないと、何も始まらないよな。

478 ：仕様書無しさん：2007/03/05(月) 09:03:02

>>473
人単体で見れば確かにそのとおり。

ただ、全体で見たときに非常に美しくなくなるんだよね。
極端な話、マスタ登録はストアド側でマスタ更新はプログラム側ってこともありうるのよ。
同じレイヤーのロジックをストアドで組んだりプログラムで組んだりっていうのは
アーキテクチャとして正しい姿なのか？っていうのは疑問。

>>476
え？
イベントハンドラとロジックはわけようぜ兄弟

479 ：仕様書無しさん：2007/03/05(月) 09:18:23

VBの簡単な画面でそれやられると萎える

480 ：仕様書無しさん：2007/03/05(月) 09:18:52

たかがVBだからな

481 ：仕様書無しさん：2007/03/05(月) 10:47:56

>>475 >>479-480
VB入門書にそういう記述をしている本がけっこうあるからなのさ。

482 ：仕様書無しさん：2007/03/05(月) 11:05:18

VB厨がプログラムを分割しようとすると妙に不自然な形になるからなぁ。
長大なイベントハンドラを許容しておいたほうが無難かもしれん。

483 ：仕様書無しさん：2007/03/05(月) 11:48:56

>>466
うそを言うな、ウソを。

484 ：仕様書無しさん：2007/03/05(月) 12:27:10

>>482
モジュールに関数書いて、呼び出すようにしても、クラス化しろよ低脳とか言われちゃうしな

485 ：仕様書無しさん：2007/03/05(月) 12:31:12

>>474

ビューにインデックスを張れない以上、
ビューの遅さは、どうしようもないと思うけど。

486 ：仕様書無しさん：2007/03/05(月) 12:36:52

ビューと通常のSELECTだとビューが遅いというのは、どこで遅くなっているんだろうか

487 ：仕様書無しさん：2007/03/05(月) 12:38:06

>>484
Foo formに1:1で対応するFoo logicクラスを作ってそこに全ての処理を延々書き連ねたコードなら見た。
イベントハンドラでは、そのlogicクラスのインスタンスを生成して、イベントハンドラに対応する長大なひとつのメソッドを呼ぶ。
アホかと。

488 ：仕様書無しさん：2007/03/05(月) 12:51:19

>>486

出来上がったビューにインデックスが張れないから遅いんだよ。

489 ：仕様書無しさん：2007/03/05(月) 12:55:59

>>488
別のビュー作ればいいじゃん

490 ：仕様書無しさん：2007/03/05(月) 13:11:22

>>489
え？

491 ：仕様書無しさん：2007/03/05(月) 13:12:29

>>488
じゃないけど
ちょっとそれ教えて欲しいと思った
今までDataSetで取り込んだりした後自分でPk設定してたりしてるんで
元々ViewにKeyを埋め込めるのならそうしたい

492 ：仕様書無しさん：2007/03/05(月) 13:14:29

ビューが実態のあるオブジェクトなDBもあるのか？
普通はテーブルを参照するオブジェクトだと思うが。

参照の仕方をユーザー毎に区切ったりする場合に使うのでは。

493 ：仕様書無しさん：2007/03/05(月) 13:21:18

ビューの元になるテーブルに適切なインデックスが張られていれば
ビューもそんなに問題にならないと思うけど

もしかしてjoinの代わりにビュー使ってるの？

494 ：仕様書無しさん：2007/03/05(月) 13:33:06

ビューにインデックス貼るって、用途無視してビュー作ってるだけじゃんw
ビューって言いたいだけだろ

495 ：仕様書無しさん：2007/03/05(月) 13:54:05

早い遅いはDB板で。

O/Rマッパーマンセーとかそういうレス希望

496 ：仕様書無しさん：2007/03/05(月) 15:17:42

>>488
実行計画とって、きちんとINDEXが使われるようなVIEWにしろｗｗｗ
つか、元表にちゃんとINDEX作れｗｗｗ

>>492
Oracleなんかじゃマテリアライズドビューなんていう
実データを持つVIEWのようなものは存在する。

>>493
正解。

497 ：仕様書無しさん：2007/03/05(月) 19:41:07

>>478
＞極端な話、マスタ登録はストアド側でマスタ更新はプログラム側ってこともありうるのよ。
＞同じレイヤーのロジックをストアドで組んだりプログラムで組んだりっていうのは
＞アーキテクチャとして正しい姿なのか？っていうのは疑問。

そういう美しさを追求したいのなら、システムを設計する際に
アクセス権を含めてかなりカッキリと設計しておけ、って気がするが。

マスタ更新系に関してはストアドを作成し、そのオブジェクトに管理者のOWNER
権限がないとINSERTできない。とかな。

逆に参照はすべてDBAが用意したビューのみしか利用できないとかか。
素人プログラマにビュー作られてパフォーマンスが出ないとか言うなら
餅は餅屋な感じでプロのDBAのテーブル設計してもらって最適な
KEY,INDEX,VIEW,制約をやってもらう。

498 ：仕様書無しさん：2007/03/05(月) 21:28:16

>>496

当然元表のＩＮＤＥＸは、使われているが
話にならんぐらい遅いよ。

499 ：仕様書無しさん：2007/03/05(月) 21:31:19

こういう
ttp://www.geocities.jp/mickindex/database/db_view.html
ページもあるから、Ｖｉｅｗは、遅いって言うのも一般的な話だと思う。

500 ：仕様書無しさん：2007/03/05(月) 21:48:46

>>498
VIEWでなく、普通にSELECTした方が速いのかい？

501 ：仕様書無しさん：2007/03/05(月) 21:52:21

>>500
絞込み順番で速度が変わるのでViewだと遅くなることが多い。

502 ：仕様書無しさん：2007/03/05(月) 22:07:54

DB2でJDBC経由で使う分にはVIEWとSELECTとの違いは体感しないけどなー。

マイクロソフトのOSからODBC経由でSQL投げると不思議と遅くなる事が
あるけど、なんなんだろうな。
SQLServer買えｔって嫌がらせなんだろうか？って思う事がある。

まあ漏れはSELECTかMQTのどっちかの人だけど。

503 ：仕様書無しさん：2007/03/05(月) 22:08:52

>>500

インデックスが張ってあるカラムで検索するなら、
圧倒的に実表を使ったほうが早い。

504 ：仕様書無しさん：2007/03/05(月) 22:12:28

ところで具体的にVIEW使うと遅くなるRDBってナニ？
>>502と同様にDB2だと、ﾃｰﾌﾞﾙでも、ビューでもﾏﾃﾘｱﾗｲｽﾞでも
どれも同じ速度で結果が返ってくるけど。

505 ：仕様書無しさん：2007/03/05(月) 22:15:44

>>504

Ｏｒａｃｌｅだよ。

>DB2だと、ﾃｰﾌﾞﾙでも、ビューでもﾏﾃﾘｱﾗｲｽﾞでも
>どれも同じ速度で結果が返ってくるけど。

ソース希望。

506 ：仕様書無しさん：2007/03/05(月) 22:22:20

>>505
ソースもなにもやって見れば解る。

適当なテーブルにビューを作成して、ついでにマテリアライズしておくと、
実テーブルとビューでマテリアライズな結果を帰ってくるような設定にしていおけば、
DB2のオプティマイザがマテリアライズの結果を返すので、
どのオブジェクトを参照しても9msくらいの早さで結果が返ってくる。

さすがは商用DBといったトコか。

Oracleに向かってこういう事いうと反論が山ほど返ってくるだろうけど、
Oracleは使う側がOracleを熟知していないとパフォーマンスでないよな。

507 ：仕様書無しさん：2007/03/05(月) 22:24:27

ハードコードしてそうな人が多そうだから、そっちに話を戻そうか

508 ：仕様書無しさん：2007/03/05(月) 22:49:33

ま、ストアド作ってもそいつを呼び出すもんはどうするのかってこともあるしね。

509 ：仕様書無しさん：2007/03/05(月) 22:55:53

Oracleのせいにしたいやつがいるな。

510 ：仕様書無しさん：2007/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 ：仕様書無しさん：2007/03/05(月) 23:05:39

ビューで集約操作をすれば遅くなる、って言ってるだけじゃん
ビューは遅い、なんて言い切るなよボケ

512 ：仕様書無しさん：2007/03/05(月) 23:08:04

>>510
動的生成するにはハードコードだわな。

513 ：仕様書無しさん：2007/03/05(月) 23:08:22

|| '-' ||

新しい顔文字かと思った

514 ：仕様書無しさん：2007/03/05(月) 23:19:02

|| '-' ||
（。Ｙ。）

515 ：仕様書無しさん：2007/03/05(月) 23:20:58

>>514
女神様じゃ～

516 ：仕様書無しさん：2007/03/05(月) 23:34:48

|| '-' ||
（。Ｙ。）ノ
　　肉

517 ：仕様書無しさん：2007/03/06(火) 07:57:35

>>506
それ偶然だから。

518 ：仕様書無しさん：2007/03/06(火) 09:05:33

ハードコーディングの定義って何？

where句の条件が動的に変化して
それ以外のselect句が固定であったとき、
where句以外をソースに書いておくのがハードコーディング？

519 ：仕様書無しさん：2007/03/06(火) 09:53:21

>>518
ソースコードの中にSQLを直書きすること。

520 ：仕様書無しさん：2007/03/06(火) 12:31:53

それの何が問題なの？

521 ：仕様書無しさん：2007/03/06(火) 12:58:47

常に同一のSQLなら生SQLでいいけど、そうでもないのに
プレースホルダも使わずに
"select * from hoge where " + condition + ";"
なんて書いてるこわーいコードが世の中には溢れかえっている。

522 ：仕様書無しさん：2007/03/06(火) 12:59:04

変更の度にコンパイル

523 ：仕様書無しさん：2007/03/06(火) 13:42:09

>>521

ハードコーディング以前の問題。

>>522

今時、コンパイルに何時間もかかるわけじゃなし。
問題無いと思うが。

524 ：仕様書無しさん：2007/03/06(火) 17:39:02

数値のリテラルよりマシ。

525 ：仕様書無しさん：2007/03/06(火) 21:31:10

>>521見て思ったんだが、上の方で出てるHibernateとかはこの問題は発生しないの？
使ったことないんでよくわからん

526 ：仕様書無しさん：2007/03/06(火) 21:35:37

>>525
Hibernate関係ねー。よっぽど使い方まちがえたらSQLインジェクション発生する。

527 ：仕様書無しさん：2007/03/06(火) 22:39:42

>>526
やっぱりそうだよね。ありがとう。

528 ：仕様書無しさん：2007/03/22(木) 21:09:04

保守

529 ：仕様書無しさん：2007/03/30(金) 21:52:17

保守

530 ：仕様書無しさん：2007/03/31(土) 00:10:44

>>524
同じ意味のconstが複数あった時にゃ、リテラルの方がマシと思った

531 ：仕様書無しさん：2007/04/02(月) 22:12:30

プリペアドステートメントってどうよ

532 ：仕様書無しさん：2007/04/03(火) 12:45:58

O/Rマッパーでも使えというのか？
SQLを書いた方が早い場合もあるんじゃないか？

533 ：仕様書無しさん：2007/04/03(火) 13:07:08

オラクルはわからんけどSAP R/3は内部でSQLをハードコーディング
してるのをよく見かけるぞ。

534 ：仕様書無しさん：2007/04/03(火) 16:07:16

SAPだったら別に良いんじゃないかという希ガス

535 ：仕様書無しさん：2007/06/11(月) 20:42:07

>>1
SQLインジェクションとかそういうことを危惧しての発言なのか、それとも単にリテラル文字列が気に入らないだけ？
後者ならお前はただのアホとしか言いようが無いぞ。

536 ：仕様書無しさん：2007/06/11(月) 20:43:22

あーハードコーディングとか言ってるから後者だな。
１は馬鹿丸出し。

537 ：69式フリーPG ◆hND3Lufios ：2007/06/11(月) 20:50:53

プレースホルダを埋めた形でハードコーディングしてますが。

設定ファイルとかに外出ししてもさ、コンパイルせずに済むのってORDER BYとか
だけじゃん？

538 ：仕様書無しさん：2007/06/11(月) 21:01:46

Java界では保守性があがると言うもっぱらの噂ですよ。馬鹿っぽい気もするけどさ。

539 ：仕様書無しさん：2007/06/11(月) 21:07:25

コードとSQL文の距離が離れることで、可読性が落ち保守性が落ちる。

540 ：仕様書無しさん：2007/06/11(月) 22:19:02

S2Dao最強でOK

541 ：仕様書無しさん：2007/06/17(日) 16:09:59

ハードコーディングしたほうがSQLインジェクションには強い

542 ：仕様書無しさん：2007/06/17(日) 17:38:27

じゃあS2Dao Tigerでいいや

543 ：仕様書無しさん：2007/06/20(水) 22:09:17

>>541
検索条件を変えられないなら、ハードコーディングしようがしまいが
SQLインジェクションには無敵

544 ：仕様書無しさん：2007/06/20(水) 23:43:29

それは、ともかくSQLExceptionの変数をsexにしてるソースがあってさ
なんか、楽しいから、やめてほしいなぁと思うわけよ。

545 ：仕様書無しさん：2007/06/20(水) 23:49:22

ﾜﾗﾀ

546 ：仕様書無しさん：2007/06/22(金) 22:57:10

SQLインジェクション云々いってるやつって何なの？
それに対策立てた上での議論だろ？

547 ：仕様書無しさん：2007/06/22(金) 23:09:47

VBのソースって半分以上がSQLだよね

548 ：仕様書無しさん：2007/06/22(金) 23:23:11

ＸＰ的にはハードコーディングだな
困ってから作り直せばいいだろ。どうせ困る前に納期だ。

549 ：仕様書無しさん：2007/06/22(金) 23:25:11

ハードコーディングじゃない方法ってどんなの？

550 ：仕様書無しさん：2007/06/23(土) 00:03:22

XPなら重複コード禁止だろ
重複コード無しでSQLハードコーディングは無理だな。不可能。

551 ：仕様書無しさん：2007/06/23(土) 00:07:08

"SELECT *" を使いまくればSQLなんて楽勝!

552 ：仕様書無しさん：2007/06/23(土) 00:14:16

コボラ乙

553 ：仕様書無しさん：2007/06/23(土) 00:17:48

>>５５０

何処が重複になるのか詳しく説明プリーズ

554 ：仕様書無しさん：2007/06/23(土) 00:41:05

柔軟性がどうこう言うﾔﾂに限って再利用可能なものをつくらないよなｗ

555 ：仕様書無しさん：2007/06/24(日) 12:54:09

SQLはハードコーディングでいい。
外出しにしても再利用などできない。

いやならO/Rマッピング使う。

556 ：仕様書無しさん：2007/06/24(日) 13:29:24

O/Rマッピングで美しく解決できるのなんて
チューニングの不要なやり逃げ案件だけ

557 ：仕様書無しさん：2007/06/24(日) 14:36:13

Webアプリの糞つまんねーCRUD部分にだけ適用するのが正解。

558 ：仕様書無しさん：2007/10/04(木) 20:25:35

hhddf

jfghhgh

tyyrtr

werwerwer

utuytu

559 ：仕様書無しさん：2007/11/15(木) 01:49:11

SQL が変わる時ってロジックも変わってることが多いんで、
SQL だけ外に出しても意味なくない?
SQL を自動生成してるんなら別だけど。

560 ：仕様書無しさん：2007/11/16(金) 00:49:22

>>559
それどころか予期せぬ障害を引き起こしたりもする．
ウチのアホSEがSQLを変更するのは設定ファイル変更で，
プログラムの変更は入りませんから，再テストの必要は無いですね，
って言って見事にバグらせたことがある．
っつーか事前検証くらいしろよっていう話なんだけどさ．

561 ：仕様書無しさん：2007/11/16(金) 23:19:41

htmlをロジックと分離するのは、それがデザインであるという以外に
定数として埋め込む手間とかいろいろあるんだよな。
SQLだと後者のメリットしかないんだけど、俺は外出しがいい。

>>559
Where句だけ変わる事って結構あると思うけど。
特に集計するときとか。

自動生成はまた別の問題を抱えていて、条件によって構文すら異なる。
レアケースでだけ構文エラーを起こしたり、解釈が変わってしまうのがいやになったよ。
まるで、Cのマクロで意図しない式に展開されてるときと同じ感覚。

>>560
それはリファクタリングがなってないだけだよな。
変更前後のSQLを差し引きしたら、どこが違うかなんて一発でわかるのに。

562 ：仕様書無しさん：2007/12/07(金) 22:17:12

>>561
何が言いたいのか全くわからん

563 ：仕様書無しさん：2007/12/18(火) 22:31:47

半端な気持ちで外出しするとメンテではまる。
どのプログラムから
どのタイミングでどのテーブルのどのフィールドを
どのSQLを使って参照・更新するのかが、チームで共有されていて
ちゃんと管理されていて、調べやすければメリットがあるけど、
ずさんな場合は依存関係を調べるのに結局ソースにあたるハメに陥り
その上、間接的に読まれるせいでソースをGREPしづらいし、数倍面倒になる。

564 ：仕様書無しさん：2007/12/19(水) 01:49:10

せっかく分けたのにちょっとした修正時に結局両方直さなければならないのは悲しい事だ

565 ：仕様書無しさん：2007/12/19(水) 06:52:44

563とか564のスレを読む限り、外出しの推進派と反対派では外出しの方法が違うのでは？と勘ぐってしまう。
564の意見とか的外れもいいとこ。

566 ：仕様書無しさん：2007/12/19(水) 07:11:14

重複、ここでやれ。
http://pc11.2ch.net/test/read.cgi/prog/1180118552/l50

567 ：仕様書無しさん：2007/12/19(水) 09:46:47

>>565
そう勘ぐったのなら、具体的にどう違うと思ったのか指摘すればいいのに。

568 ：仕様書無しさん：2007/12/19(水) 19:46:57

スレとレスも間違えてるしな

569 ：葉猫 ◆Jz.SaKuRaM ：2007/12/20(木) 21:54:00

1000行ﾚﾍﾞﾙのストアドをソースに埋め込む気にはならんな ('A`)ﾏﾝﾄﾞｸｾｰ

570 ：仕様書無しさん：2007/12/20(木) 22:31:40

何言ってんだオメー
さっさと氏ねよ

571 ：仕様書無しさん：2007/12/22(土) 03:15:40

結局、ソースファイルと外出しsqlの両方とも修正しなくといけなくなるだけ。

572 ：仕様書無しさん：2007/12/22(土) 03:17:33

マ板のスキル低下は著しいなｗｗｗｗｗｗｗ

573 ：仕様書無しさん：2007/12/22(土) 13:17:03

java向けのスレなのにC++とかのプログラマが来て些細なテクニック論に
なってるなこのスレ

574 ：仕様書無しさん：2007/12/22(土) 13:43:16

そんな前提>1に書いてないので認めないｸﾏｰ

575 ：仕様書無しさん：2007/12/22(土) 16:00:08

>>283
ちょwwそれうちの病院www
クエリはないけど、リンクテーブルだらけのmdbファイルあったわ。
でも処理はVBじゃないっぽい。

独自にデータ集計したりするときに俺もそこからインポートしてるけど。

576 ：仕様書無しさん：2007/12/22(土) 19:05:06

>>573
＋＋マが全部こんなのだって訳じゃないんだぞといっておく

577 ：仕様書無しさん：2007/12/22(土) 19:49:43

スレの最初のほうを読んで、それ以降はチラ見してただけだから、Javaスレになってたなんて気ずかなかったよ。

578 ：仕様書無しさん：2007/12/22(土) 20:07:09

づ

579 ：仕様書無しさん：2007/12/22(土) 22:09:20

SELECT文とかを変数につっこんでExecuteとかマジやめて欲しいんだけど。
特にWebアプリの場合ね。
ストアドを作ってそれを呼ぶだけにするのば一般的だと思ってたんだけど
そうでもないの？
そういえばカカクコムとか昔攻撃されてたね。

580 ：仕様書無しさん：2007/12/22(土) 22:15:40

>>579
DB側に処理をおくのは・・・って考え方もあるよ
インジェクション対応して無いなんてのはどうやっても問題外

581 ：仕様書無しさん：2007/12/22(土) 23:07:37

hibernateってヒントつけられないから馬鹿だよね。
使い物にならん。

582 ：仕様書無しさん：2007/12/22(土) 23:11:39

> するのば
　　　　　↑
あまり一般的じゃないと思う

583 ：仕様書無しさん：2007/12/23(日) 00:21:49

Webの開発だったら普通はストアドプロシージャを実行するよ。
LINQなんて論外。

584 ：仕様書無しさん：2007/12/23(日) 00:26:17

>>583
ストアドはないだろ・・・

585 ：仕様書無しさん：2007/12/23(日) 00:35:25

>>584
PROCEDUREというやつの事です。
Accessだとクエリだっけ？

586 ：仕様書無しさん：2007/12/23(日) 00:37:30

SQLをハードコーディングする人って多いのね。

587 ：仕様書無しさん：2007/12/23(日) 00:49:31

インジェクション対策ならプリペアードクエリでいいだろ

588 ：仕様書無しさん：2007/12/23(日) 00:55:00

DBへの処理はDB側で行うのかプログラムに書いちゃうかはプロジェクトによって分かれるね。
今のプロジェクトはDBへの処理は必ずストアドを使うように言われてる。
そもそもプログラムを実行するユーザーにはストアドのGRANT権限しか付与してくんない。
まあどっちでも良いや。

589 ：仕様書無しさん：2007/12/23(日) 00:58:24

DB側に処理もって行ったら不可分散しにくいじゃん

590 ：葉猫 ◆Jz.SaKuRaM ：2007/12/23(日) 09:48:57

一時テーブルを使えないとスピードが遅くなるからDB側でちょ (｀･ω･´) ｼｬｷｰﾝ

591 ：仕様書無しさん：2007/12/23(日) 11:10:09

お前マジキメェ
さっさと失せろ

592 ：仕様書無しさん：2007/12/23(日) 17:58:23

どう書くのが推奨なの？
SQL生成用の関数作ってパラメータ放り込むぐらいしか考えつかん

593 ：仕様書無しさん：2007/12/23(日) 18:07:02

ORマッパ

594 ：仕様書無しさん：2007/12/23(日) 22:04:21

今時一次テーブルとかスキル無いコテってなんなの？

595 ：仕様書無しさん：2007/12/23(日) 22:49:36

以前も自らのアホっぷりを晒したレスを論破されて逃走
挙句の果てに火病って糞スレ立てるほどのアホの子ですから

596 ：仕様書無しさん：2007/12/25(火) 00:23:35

なんでも*つければ
良いってもんじゃねーぞ。

597 ：仕様書無しさん：2007/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 ：仕様書無しさん：2007/12/25(火) 02:20:05

GRANT権限ってなんだ

599 ：仕様書無しさん：2007/12/25(火) 06:22:04

>>598
GRANT文を実行できる権限じゃね？

600 ：仕様書無しさん：2007/12/25(火) 11:01:49

>>597
名前で検索って、それじゃIDの意味ねーよｗ
↑どうでもいいことを言ってみる。

601 ：仕様書無しさん：2007/12/25(火) 23:06:57

>>597
WHEREを画面の入力によって組み立てたりすると
途端に破綻するんだろ？

602 ：仕様書無しさん：2007/12/26(水) 00:48:48

>>599
中間管理職か...

603 ：仕様書無しさん：2007/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 ：仕様書無しさん：2007/12/26(水) 07:04:29

インジェクションされまくるじゃないか、とかは別にして、
結局ハードコーディングした方がいいじゃん、つ流れになりそうな話だなぁ

605 ：仕様書無しさん：2007/12/26(水) 07:21:19

バカどもがどうしようと構わんが、マ板の質落ちたねぇ・・・

606 ：仕様書無しさん：2007/12/26(水) 21:49:21

>>605
どうしたら上質だんだよ。

607 ：仕様書無しさん：2007/12/26(水) 23:16:54

んだんだ

608 ：仕様書無しさん：2007/12/26(水) 23:35:51

>>606
やっぱブラック、いろんな意味で。

609 ：仕様書無しさん：2007/12/27(木) 00:15:23

>>603
SQL実行する前に値チェックをプログラムでやればいいだろ

610 ：仕様書無しさん：2007/12/27(木) 18:18:24

INSERTする前には必ずSELECTして重複チェックしてください。

611 ：仕様書無しさん：2007/12/27(木) 18:22:31

>>610
それはあまりに間抜けな仕様。

論理的な重複排除はPKかUNIQUE INDEXの一意制約違反で
INSERT時のSQL実行エラーを戻してもらえればいい。
あとはアプリケーションでエラー処理をきちんと実装する。

612 ：仕様書無しさん：2007/12/27(木) 19:18:27

>>610
SELECTとINSERTの間に他のセッションからINSERTされちゃうことってないの?

613 ：仕様書無しさん：2007/12/27(木) 19:40:31

>>611
俺らがSELECTされない間に、あいつはINSERTされてるんだよ、畜生。

614 ：仕様書無しさん：2007/12/27(木) 21:00:42

>>613
俺なんかSELECTされる事が無いまま、そっけなくDELETEされるんだぜ。

615 ：仕様書無しさん：2007/12/28(金) 00:36:29

>>614
お前は一度でもINSERTしたのか！

616 ：仕様書無しさん：2007/12/28(金) 10:25:30

ハードコーディングってなんぞ？
JDBCは組込みSQLはハードコーディングに入ってんのか？

617 ：仕様書無しさん：2007/12/28(金) 12:01:41

SQLを外に出してる奴は、他の言語内言語である正規表現とかも外に出してるのか？

618 ：仕様書無しさん：2007/12/28(金) 12:03:43

spring framework位使いこなしなよ。おじいさん＾＾

619 ：仕様書無しさん：2007/12/28(金) 12:07:49

中出しはらめぇ

620 ：仕様書無しさん：2007/12/29(土) 06:26:03

springとＳＱＬのハードコーディングは、何の関係も無いと思うが・・・

621 ：仕様書無しさん：2007/12/29(土) 17:04:29

ハードコーディング自体は悪くないが、
複数のメソッドで部分部分ＳＱＬ文字列組み立てるのは勘弁してくれ。

622 ：仕様書無しさん：2007/12/30(日) 12:55:40

昔バカスイーツＳＥ女がいて
ソースが汚いとすぐハードコーディングハードコーディング言ってうるさかった

623 ：仕様書無しさん：2007/12/30(日) 13:39:39

>>617
SQLと正規表現だと別もんだと思うんだが・・・
正規表現エンジン変えられるようにしてたりしたら外に出すなぁ

624 ：仕様書無しさん：2007/12/30(日) 20:34:26

ハードコーディング肯定してる奴らってIDE使ってないんじゃないかって気はする

625 ：仕様書無しさん：2007/12/30(日) 21:55:06

何言ってんだ？

626 ：仕様書無しさん：2007/12/31(月) 06:18:06

>>610くらいからの流れにｸｿﾜﾛﾀ

627 ：仕様書無しさん：2007/12/31(月) 11:01:55

>>623
RDBMS変わりうること前提にした外出しなの?

変わることなんかそうそう無いと思うんだが

628 ：仕様書無しさん：2007/12/31(月) 12:25:29

ハードコーディング＝静的ＳＱＬ
それ以外＝動的ＳＱＬ
ってこと？

なら静的に書いたほうがオーバーヘッドがない分性能はいいよ

629 ：仕様書無しさん：2007/12/31(月) 12:26:48

>>628
静的・動的ってどういう意味で使ってる?

俺はORMを使うかどうかという意味だと思っていたのだが。

630 ：仕様書無しさん：2007/12/31(月) 12:31:14

どういう意味？？？
静的＝コンパイラにＳＱＬのロジックを展開させてＬＭでは最終的なＤＢアクセスのロジックは固定
動的＝ＳＱＬが内部的に変わるのでＳＱＬ翻訳後にＤＢアクセスするのでの余計なオーバーヘッドがかかる

こんな感じ？

631 ：仕様書無しさん：2007/12/31(月) 12:36:48

あ
ここマ板か
失礼、ＤＢ板と勘違いした

632 ：仕様書無しさん：2007/12/31(月) 13:20:31

O/Rマッパは汎用的なのは良いが
オプティマイザの実行計画が
実は大変なことになってることが多いのが悲しいな。

633 ：仕様書無しさん：2007/12/31(月) 13:33:38

>>627
正規表現の場合の話がしたいの？SQLの場合の話がしたいの？
SQLと正規表現は別もんって書いてあるよね？

634 ：仕様書無しさん：2007/12/31(月) 13:35:45

>>632
裏で色々あったんだろうがDBMagazineのTopLinkは奇麗だったな・・・

635 ：仕様書無しさん：2008/01/01(火) 20:57:02

>>630
SQLの場合はこんな感じかな。DB2限定だが。
静的：実行計画を事前に取得しておく。
動的：実行時に実行計画を取得する。

ORACLEって静的バインド出来ないよね？

636 ：仕様書無しさん：2008/01/04(金) 16:45:58

1 が言いたいのはたぶん、
同一のテーブルを参照するSQLを
いたるところに書くことに辟易
してるってことを言いたいんだと思う

637 ：仕様書無しさん：2008/01/04(金) 21:56:46

それは、ハードコーディングだろうが、
外部ファイルに書こうが一緒だ。

638 ：仕様書無しさん：2008/01/04(金) 22:25:27

レスも空気も読まずにageレスか・・・さすが冬

639 ：仕様書無しさん：2008/01/05(土) 01:24:58

１が言いたいことはたぶん
プログラム内でSQL文を組み立てて発行することを言ってるんだと思う。
前にVBプログラマが作ったソースを見たら
sql = "SELECT * FROM テーブル"
conn.exec(sql)
みたいなコーディングだったんだけど、こういうのがハードコーディング？
DBにプロシージャとかを作成してアプリ側はそれを呼ぶだけにして欲しいってことじゃないの？

自分は小さい規模（ユーザー数１０００人前後）のシステムしか作ったことがないので
普通にDBにプロシージャを作って、C#でDBに接続してプロシージャを実行とかやってる。
上のレスを見たら分散処理のためにハードコーディングするとかあったけど
よく意味がわからなかった(^^;
ヤフーとか２ｃｈのようにもの凄い大量のアクセスがあるシステムでは
分散処理とか考えてコーディングしないとヤバイのかな？
もっと勉強しなきゃだな。
うちはWebサーバ1台とDBサーバ1台だけでやってて特に問題無い程度のアクセス数だけど
複数台のサーバで処理を分散とかの勉強もしなきゃなぁ。

640 ：仕様書無しさん：2008/01/05(土) 02:01:43

>>639
半年ROMれ

641 ：仕様書無しさん：2008/01/05(土) 02:25:38

>639
あー半年と言わず三年ROMれ

642 ：仕様書無しさん：2008/01/06(日) 10:32:28

ここの住人って常駐派遣が多そうだな。

643 ：仕様書無しさん：2008/01/06(日) 11:04:37

客先常駐の請負仕事なだけで派遣じゃないよｗ

644 ：仕様書無しさん：2008/01/06(日) 18:46:56

偽装派遣のにおいがするんだが・・・

645 ：仕様書無しさん：2008/01/06(日) 18:49:37

てゆうかマジで客先常駐なんてありえないよね。
ぶっちゃけ惨めじゃん。
自分の会社じゃないところに行ってさ。
うちにもちっさい会社のエンジニアが沢山常駐してるけどかわいそうだよ。
会社によるだろうけど派遣社員にはネットやメールを使わせないとか
そういうルールもあるし。

646 ：仕様書無しさん：2008/01/06(日) 23:11:03

常駐させてるのも、そういうルールを作ったのも
お前の会社なんだろ。

647 ：仕様書無しさん：2008/01/07(月) 22:04:27

思い付きだけで書かれたものを残されるとツライと思う。
でも、OJTだけで教育しようとしてるウチじゃあ無くならないんだろうな。

648 ：仕様書無しさん：2008/01/08(火) 10:58:26

>>647
詳細設計完了後に思いつきで
仕様変更を連絡して来なきゃ、
そのケースはかなり減ると思うｗｗｗ

649 ：仕様書無しさん：2008/01/08(火) 22:05:35

先輩方！お手本ソースを教えて教えて！

650 ：仕様書無しさん：2008/01/13(日) 22:06:25

M + ijime = Mijime = みじめ = 惨め

いじめられても笑顔で居られる客先常駐って惨めだよね

651 ：仕様書無しさん：2008/02/06(水) 01:24:00

まだあったのなー。
最近、自宅で趣味でJavaのWEBシステム構築やってんだけど、
ハードコーディングが楽だわ。

SQLインジェクションはバインド変数で解決、
不要なカラムは取得せずSQLもすっきり、I/Oもすっきり。

なんで>>1はハードコーディング嫌ってんの？作業振りしやすいから？
プログラマにDB周りをある程度把握させとかないと問題あったとき、危険だと思うけど。
どっちにしろO/Rマッピングは1から10まで全部一人でやっちゃうプログラマにはあんま美味しくないよ

652 ：仕様書無しさん：2008/02/06(水) 14:56:30

>>651
あとO/Rマッパはチューニングしにくい罠

653 ：仕様書無しさん：2008/02/24(日) 17:40:04

ハードコーディングってそもそも何？

654 ：仕様書無しさん：2008/02/24(日) 18:11:09

俺はiBATISくらいの薄い方が好きだ

655 ：仕様書無しさん：2008/02/24(日) 19:15:37

SpringJDBCがよい

656 ：仕様書無しさん：2008/02/24(日) 19:23:02

http://bbs.cgiboy.com/Guestbook/BBS/07232290/
荒らしならここをつぶすのがいい

へいさにおいこめくずども

657 ：仕様書無しさん：2008/03/02(日) 22:49:26

SQLをDBに持つとか別テキストに持つだとか構造をXMLにしてもっておくだとか
いろいろなプロジェクトがあったが、結局はSQLを直すときはソースも直す場合が多いよね。
そうなると分けるとよけい保守性が悪くなるよね。

658 ：仕様書無しさん：2008/03/03(月) 00:31:54

修正の規模による

659 ：仕様書無しさん：2008/03/03(月) 22:31:21

項目Ａ(3ﾊﾞｲﾄ)、項目Ｂ(6ﾊﾞｲﾄ)

(更新前)
AAA,BBBCCC
AAA,BBXCCC
AAA,BBPCCC

(更新後) ←　このようにしたいです。
AAA,BBZCCC
AAA,BBZCCC
AAA,BBZCCC

目的は、項目Ｂの頭３バイトだけを”ＢＢ＊”で条件に指定して、
項目Ｂの頭３バイトを全て”ＢＢＺ”に更新したい場合どうすればよいのでしょうか？
項目Ｂの後３バイトの”ＣＣＣ”はそのまま残さなくてはいけないため、
どのようなＳＱＬ文にすれば良いのかわかりません。

どうしても後３バイトを生かしたままの更新なので。。。。困ってしまします。

お知恵をお貸しください。

660 ：仕様書無しさん：2008/03/03(月) 22:41:36

>>659
concat(concat(substr(B,1,2),'z'),substr(B,4,3))でupdateしたらどうか？

661 ：仕様書無しさん：2008/03/03(月) 22:50:13

>>660
本当にありがとうございます！！
さっそく明日実行してみます。！！
「現場で使えるＳＱＬ」って本読んでもうまくＳＱＬ文思いつかなくて。。。
本当にありがとうございます！！

662 ：仕様書無しさん：2008/03/03(月) 23:05:55

設計が悪いようにしか思えん。

663 ：仕様書無しさん：2008/03/04(火) 00:38:36

これ酷いな

664 ：仕様書無しさん：2008/03/04(火) 13:13:52

ハードコーディング最強

665 ：仕様書無しさん：2008/03/04(火) 17:31:29

S2DAOでいいや

666 ：仕様書無しさん：2008/03/04(火) 22:17:23

>>659 コボラーのにおいがする

667 ：仕様書無しさん：2008/03/05(水) 00:34:15

ストアドは使わないの？
コンパイル時間がかからないから初回がやたら遅いSQLにいいじゃん。

668 ：仕様書無しさん：2008/03/05(水) 01:17:28

DBにSQL文いれときゃいいじゃん

669 ：仕様書無しさん：2008/03/06(木) 09:35:17

>>668
それを取得するSQLはどうするんだ？

670 ：仕様書無しさん：2008/03/07(金) 00:50:45

Dim SQL As String
SQL=DLookup("SQL","M_SQL管理テーブル","id=xxx")

671 ：仕様書無しさん：2008/03/07(金) 02:30:25

Accessはポイだポイ。

672 ：仕様書無しさん：2008/03/11(火) 06:32:38

>>670
Aceess かどうかはともかく、SQL 文を id(多分数値型のつもりでしょ) で管理するってのは、
関数やら手続きを連番で管理するのと同じにおいがする。
id='xxxマスタ取得' とか id='xxx一覧取得' とかなら、数値管理よりはましかな。

673 ：仕様書無しさん：2008/03/14(金) 01:36:48

>>672
これやった事ある。
SQLを修正するときは探すのも面倒なので新規にテーブルに
放り込んでたｗ
ソース側はid変えるだけ。
思ったよりも混乱は生じなかったよ。
DBに2回アクセスするのが欠点だけどｗ

674 ：仕様書無しさん：2008/03/14(金) 02:29:54

SQLを別の場所に置いたとして、SQL修正後のテストのために
どのプログラムから、そのSQLが使われてるかとか常に管理してんの？
それとも複数のプログラムからはSQLを共有しない？

675 ：仕様書無しさん：2008/03/14(金) 02:44:42

>>674
>それとも複数のプログラムからはSQLを共有しない？
その通りまったく同じSQLがたくさんはいっている。
ソース内で同じIDのSQLを呼び出さないルール
ソース側との整合性だけとれてればいいので管理しない。
テスト時に帰ってきたSQLが正しいかだけチェックしてる。
ぶっちゃけると中国人プログラマが勝手にこのルールに
してしまったので皆つきあわされたｗｗ

676 ：仕様書無しさん：2008/03/14(金) 07:59:11

SQLを動的に作る自作API使ってる。1500行。
メリットはどんなSQL DBにも対応可能。
汎用性／柔軟性が高い。開発効率が良い。

デメリットはストアドとかが使えない。

677 ：仕様書無しさん：2008/03/14(金) 20:24:52

それならS2JDBCでも使えよ。
まぁ、Javaじゃないかもしれんが

678 ：仕様書無しさん：2008/03/14(金) 22:28:20

SQLを外出しにして管理しても再利用できる汎用的なSQLは
せいぜい全体の２・３割程度で、ほとんどは１箇所でしか使われない。
単純で汎用的なSQLについてはOR-MAPした方が便利だが、
帳票出力、データ集計、条件が複雑に変化するな検索など
ビジネスロジックそのものと言えるSQLはオンコーディングか、
ストアドにしてしまった方がシンプルかと…

679 ：仕様書無しさん：2008/03/14(金) 23:27:03

おれもストアドだな

680 ：仕様書無しさん：2008/03/15(土) 00:17:05

ストアド使い出すと、増えすぎて見通しが悪くなるから好かん

681 ：仕様書無しさん：2008/03/15(土) 00:40:08

ストアドはうざいから俺も好かん

682 ：仕様書無しさん：2008/03/15(土) 01:03:25

異様に処理時間のかかるアホみたいなのを平気で組むヤツが居るんよな

683 ：仕様書無しさん：2008/03/15(土) 01:08:04

Oracleマニアみたいな人が作って残していった
バッチ処理で1万行のプロシージャと闘ったときは死ぬかと思った。
単純になるなら歓迎だけど、意地でもストアドみたいなポリシーはやめて欲しい。

684 ：仕様書無しさん：2008/03/15(土) 12:26:23

>>683
それはストアドにしたから複雑になったんじゃなくて、
SQL一発でできることを無駄にカーソルで処理するから複雑になってるのでは？

685 ：仕様書無しさん：2008/03/15(土) 12:42:31

>>683
１プロシージャに１万行なんて、そいつがキチガイなだけだろ

686 ：仕様書無しさん：2008/03/15(土) 21:56:57

「カーソル」が使われているストアドは、COBOLからの書き換え以外認めない。

687 ：仕様書無しさん：2008/03/16(日) 23:46:20

>686
それはまた極端なｗ

688 ：仕様書無しさん：2008/03/22(土) 08:18:00

人間中庸が肝心だ。

689 ：仕様書無しさん：2008/03/22(土) 22:36:55

PHPでSQLをハードコーディングしてあってびびった。
SQLは切り出せよ。
SQLインジェションされてサニタイズ漏れたら終わりだろがと。

言ったが今でも放置されたまま。

690 ：仕様書無しさん：2008/03/22(土) 22:54:54

>>689
ハードコードしてあっても
プレースホルダ使うだけでだいぶ変わるがな。

つか「インジェション」ってｗｗｗ

691 ：仕様書無しさん：2008/03/23(日) 01:07:26

SQLをハードコーディングすることとSQLインジェクションの問題は直行しているから、>>689の指摘は的外れだったんじゃないかなぁ？

692 ：仕様書無しさん：2008/03/23(日) 10:07:08

>>691
直行？直交にしてもわからんしな。関係ないってコトじゃないのか。

693 ：葉猫 ◆Jz.SaKuRaM ：2008/03/23(日) 13:15:03

ストアドにちておけば内部で文字列化ちてselectとかexecuteみたいなｱﾎなことちないかぎり
問題ないちな (･∀･)

694 ：仕様書無しさん：2008/03/23(日) 13:57:07

ストアド簡単なのに作ろうとしない馬鹿が多すぎてこまる。
提案してもメンテできない・わからないで握りつぶされる。
結果ハードコーティングでバグおこしてデスマ。
あほSEは早く欝になって首つってくれ！！！！！

695 ：仕様書無しさん：2008/03/23(日) 14:08:35

>>694
> 提案してもメンテできない・わからないで握りつぶされる。

ありがちだが、その連中の言い分も分からなくはない。

696 ：仕様書無しさん：2008/03/23(日) 14:45:01

>>694
ストアドは扱いが難しい。

テーブル設計が完了した段階でデータベースの構造をフリーズして
後はデータの出し入れだけにしたいという方針が普通の感覚だと思うんだが、
プログラムと同じ感覚でストアドを作ると、この方針と衝突する。

データの意味づけが拡張されてストアドの修正が必要になっても、まかりならんって
ことになったりする。
そういう時はしかたないので、プログラム側でストアドに相当するSQLを新しく
発行するようにして、ストアドは呼ばなくなる。

設計段階でストアドの要件もしっかり決めておけってのが正論なんだろうが。
間に合わせ的に使ってしまったりするな。

697 ：仕様書無しさん：2008/03/23(日) 15:00:25

俺がストアド嫌いな理由は、デバッガが使いにくいから。と
単純なSELECTやINSERTだったら、
ORマッピングツールのほうが良くて
混在すると鬱陶しいから、極力ORマッピングツールを使う。

提案してもメンテできない・わからないっていう、
SEはしんだほうがいいなと俺も思う。

698 ：愛ちゃん：2008/03/23(日) 17:20:48

ORマッピングとかORマッパってどういうものなんでしょうか？

699 ：仕様書無しさん：2008/03/23(日) 17:31:52

SQL書かなくてもＲＤＢが使える魔法の箱さ！

700 ：仕様書無しさん：2008/03/23(日) 17:41:55

ストアドは自動テストに組み込み難いんだよな
デバッグも面倒だし

701 ：仕様書無しさん：2008/03/23(日) 17:43:21

制約が多すぎで使えねー、
検索系で組み込んだら遅くて使えねー、
マスタメンテ以外につかえねーの三拍子

意地でも使ってやるって人の背中にはデスマオーラが漂ってる

702 ：仕様書無しさん：2008/03/23(日) 18:16:54

派生開発案件で元が腐ってたとかならともかく、
ストアドなど書かずに済むようにDB設計するのが基本だと思う。

あと、「性能」を理由にすぐにストアドを使いたがるプログラマって
単に手続き的にしか物事を考えられない（まともなSQLの書き方を知らない）
人が多いような。

703 ：仕様書無しさん：2008/03/23(日) 19:42:09

バージョン管理とかはメンドクサくないの？

704 ：仕様書無しさん：2008/03/23(日) 21:54:50

ストアドはバージョン管理めんどくさい。
ストアドは、データベースやSQL Serverの外から呼び出すプログラミング環境が
貧しかった時代の亡霊だと思う。昔はストアドで何でもかんでもやってた。

705 ：仕様書無しさん：2008/03/23(日) 23:37:49

ORマッパについて解説しているサイトをご存じないですか？

706 ：仕様書無しさん：2008/03/24(月) 00:38:02

今までの意見をまとめると、RDBSは糞ってことで良いか？

707 ：仕様書無しさん：2008/03/24(月) 00:52:36

ハードコーディングってなんだろう

708 ：仕様書無しさん：2008/03/24(月) 01:25:17

>707
>91

709 ：仕様書無しさん：2008/03/26(水) 22:46:34

ストアドの方がパフォーマンスが良いとかはもう昔の話？
あと権限についてですが、ハードコーディングだと実行権限付与がめんどくないですか？そんなことないかな。
自分の会社はWebの開発が多いのですが、例えばIISを使っている場合だと
IISの匿名ユーザーにストアドの実行権限を付与してるだけです。
テーブルの書き込み権限とかは一切与えてなく、ストアドの実行権限のみです。
その方が安全とか先輩が言ってました。

710 ：仕様書無しさん：2008/03/26(水) 22:50:37

そりゃそうだ
最近SQLを満足にかけない奴がORまっぱとかほざいてるだけのような気がする

休日は自宅にヒキコモリ。
仕事じゃひとつの言語にヒキコモリ。
ヒキコモリ人生万歳ですか？

711 ：仕様書無しさん：2008/03/26(水) 22:55:45

>709
別に昔の話ではない。今も通じる。

権限は……面倒くせえからDBAでアクセスしちまえｳﾊﾊﾊってのばかり見かけるが

712 ：仕様書無しさん：2008/03/26(水) 22:56:22

>710
前半と後半の乖離ぐあいにﾜﾗﾀ

713 ：仕様書無しさん：2008/03/26(水) 23:30:39

>>709
ストアドの方がパフォーマンスがよいって言うのは今でも正しいけど、
テーブル設計とSQLの筋さえよければ今は十分なパフォーマンスが稼げる。
だからクエリをDB側ではなくアプリ側に持っていく事によって得られる
開発パフォーマンスの向上が今は重視されている感じだな。

714 ：仕様書無しさん：2008/03/26(水) 23:32:59

実行プランを認識してない馬鹿が組むSQLは見てらんない
死ねばいいのに

715 ：仕様書無しさん：2008/03/26(水) 23:41:11

>>704
OSI7層モデルから勉強しなおせ。

716 ：仕様書無しさん：2008/03/27(木) 22:28:29

>>715
OSI7層って実行速度より美しい理論モデル作りたがりの産物じゃん
当時の実装は各境界の通信でオーバーヘッド出まくりで
遅くて使い物にならないものが多かった
マシンの性能が上がった今なら実装のしようもあるだろうが
IPにとって代わられちゃったし

717 ：仕様書無しさん：2008/03/28(金) 01:56:38

>>716
OSIの考え方を用語するつもりはないが、
OSIは政治的に潰されたんだよ。これ豆知識ね。

718 ：仕様書無しさん：2008/03/28(金) 07:28:36

>>717
OSI モデルの第 8 層って奴だな。
あと、宗教層・経済層ってのを加えるときもある。

719 ：仕様書無しさん：2008/03/28(金) 09:11:35

>>718
それは、知らなかった。補足ありがとう。

720 ：仕様書無しさん：2008/03/28(金) 21:34:09

一時期 layer8.jp とか取ろうと思ったこともあったが、
やっぱり取られてたぜ。

721 ：仕様書無しさん：2008/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 ：仕様書無しさん：2008/03/31(月) 08:56:59

>>721
>この程度でIF文はいらん。
そんなこと言うから変なコードが増える。
IF文をけちってなにかいいことでもあるのか。

723 ：仕様書無しさん：2008/03/31(月) 09:28:34

>>722
ヘタクソやね～。
母言語とSQLでスパゲッティ作っておいしいか？

724 ：仕様書無しさん：2008/03/31(月) 10:03:52

スパゲッティ？

725 ：仕様書無しさん：2008/03/31(月) 20:01:02

>>721ぐらいなら普通IFなんて使わんだろ。

726 ：仕様書無しさん：2008/03/31(月) 21:21:00

"commit"をハードコーディングする俺の会社orz

727 ：仕様書無しさん：2008/03/31(月) 21:27:21

>>726
それなんか問題あんの？
どーでもいいじゃん

728 ：葉猫 ◆Jz.SaKuRaM ：2008/03/31(月) 22:08:26

正直、ストアドのwhere句に条件式入れるのと、exeのsql文のwhere句に入れる違いがわからん。

729 ：仕様書無しさん：2008/04/01(火) 07:24:50

>>728
プランナについて勉強しよう

730 ：仕様書無しさん：2008/04/01(火) 12:07:32

勉強できるほどの知能があれば、とっくにｺﾃやめてるだろう。

731 ：仕様書無しさん：2008/04/01(火) 18:24:21

commit はハードコーディングじゃないの。
（一ヶ所にまとめるけどね）
少なくとも俺はストアドの中には書かせない。
ネストしたらえらいことだ。

732 ：仕様書無しさん：2008/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 ：仕様書無しさん：2008/04/01(火) 21:42:39

>>727や731のコードが汚いことはよくわかった。

宣言的トランザクション使えよ。

734 ：仕様書無しさん：2008/04/01(火) 21:58:27

>>733はバカ

735 ：仕様書無しさん：2008/04/01(火) 22:18:44

ORまっぷっぷは、SQLも覚えられないボケが崇拝するお花畑のちょうちょに過ぎないし。
プロシージャはマニア魂を刺激しちゃって、ろくなことにならないときあるし。

やっぱハードコーディングが一番いいよ。
効率的だし、ブレないし、マニアックになり過ぎないし。

736 ：仕様書無しさん：2008/04/01(火) 22:20:44

でも最近はORマッパで済ませちゃうのがもてはやされる。
Railsとか。

737 ：仕様書無しさん：2008/04/01(火) 22:25:08

結論から言うと適材適所でしょ
ルールはきちんと作ってだけどね

738 ：仕様書無しさん：2008/04/01(火) 22:31:39

関係ないけどJOIN禁止のプロジェクトとかまだあんのかなぁ

739 ：仕様書無しさん：2008/04/01(火) 23:02:24

３年間オラクレばっかやってた。
今度SQL鯖やるんだけどJOINって何だよおしえれorz

740 ：仕様書無しさん：2008/04/01(火) 23:05:51

グイでグイグイやってたらSQLは勝手に出来る

741 ：仕様書無しさん：2008/04/01(火) 23:18:16

結局ハードコーディングの方があとで分かりやすいんだよな

742 ：仕様書無しさん：2008/04/01(火) 23:19:39

Set OraDynaset = Nothing

743 ：仕様書無しさん：2008/04/01(火) 23:20:27

うん。
別ファイルにしてあると、開くのにマウスこちこちしないといけないからめんどくさいしね。

744 ：仕様書無しさん：2008/04/01(火) 23:21:49

今日書いたSQLは3年後5年後も通用するが今日使ったO/R mapperは
3年後5年後には誰も使わないレガシーな技術になってると思う

745 ：仕様書無しさん：2008/04/01(火) 23:43:57

>>739
（＋）

746 ：仕様書無しさん：2008/04/02(水) 00:13:02

unionしてsumしてクロス集計ってアリなの？

747 ：仕様書無しさん：2008/04/02(水) 09:37:09

ORマッパがいいのなら、素直にオブジェクト指向データベース使えよ。
なぜ、今まで使われなかったのか、考えてみ。

748 ：仕様書無しさん：2008/04/02(水) 20:32:28

>>745
それはオラクル特有のおまじないじゃん？

749 ：仕様書無しさん：2008/04/02(水) 22:10:52

今さら (+) なしの生活には戻れないわ・・・
もうすっかりOracleに毒されちゃってるのよ・・・

750 ：仕様書無しさん：2008/04/02(水) 22:29:39

最近のSQL Serverだと*=や、=*は使えないんだっけ？
つーか、Oracleでも9i以降ならOUTER JOINで書かないか？

751 ：仕様書無しさん：2008/04/02(水) 22:48:57

ora9iのOUTER JOINはバグが潜んでる

752 ：仕様書無しさん：2008/04/02(水) 23:55:27

バグは、9.1.4までじゃない？
(+)を書く奴は氏ねとは言わんけど、金取れるプロじゃないわな。

753 ：仕様書無しさん：2008/04/03(木) 00:45:44

http://www.google.co.jp/search?q=(%2B)

754 ：仕様書無しさん：2008/04/03(木) 02:38:01

>>752
何で死ね扱いなんだ？
俺は書きやすいし読みやすいから (+) の方がすきなんだが

755 ：仕様書無しさん：2008/04/03(木) 07:58:45

*=とかよりはJOINの方が見やすいという人が多い。
自分もそう思います。

756 ：仕様書無しさん：2008/04/03(木) 09:20:53

>>754
SQLの意味が分かってない。
SQL とは Structured Query Language(構造化問合せ言語)

省略語じゃないとかそんなことはどうでもよいけど、
構造化いうのは、句ごとに役割が決まっているわけ。

WHERE句に結合条件と抽出条件を混在させても違和感を
覚えない時点で、プロとしてのセンスはない。

757 ：仕様書無しさん：2008/04/03(木) 09:37:48

>>756
あの旧世代の腐れ構文が構造化されているように見えるとは恐れ入った。

758 ：仕様書無しさん：2008/04/03(木) 09:46:18

xxxx JOIN Table ON
という書き方が冗長というのは、同じ非英語圏の人間だから
わからんではないが、WHERE句に結合条件を書くのは痛い。

759 ：仕様書無しさん：2008/04/03(木) 10:05:05

>>757
まぁ、あれだ。
マシン語から新世代に近づくほど、
自然言語に近づくもんなんだ。
ループがある方が旧世代なんだな。

760 ：仕様書無しさん：2008/04/03(木) 11:34:11

>>757
腐っていようが…。
WHERE句に結合条件を書いたら、もっと腐る
ということが分からない時点で終わってる。

761 ：仕様書無しさん：2008/04/03(木) 12:30:31

>>760
>腐っていようが…。
「構造化されてなんかいない腐れ構文」には同意頂けたようで。
…まあ、Oracle の旧書式は直感的だが、もっと腐ってるとは思う。

>WHERE句に結合条件を書いたら
「抽出条件」てのが「1行1項目しかない『定数』との結合条件」と考えれば
両者の間になんの違いもないわけだが。
-- そういやこないだ、
--　　JOIN ～ ON (～ AND HOGE = 0)
-- なんて記述を見かけた。

762 ：仕様書無しさん：2008/04/03(木) 12:37:27

>>761
何が面白いのか解説してよ

763 ：仕様書無しさん：2008/04/03(木) 15:50:26

LEFT JOIN

764 ：仕様書無しさん：2008/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 ：仕様書無しさん：2008/04/03(木) 17:56:22

>>764
お前は莫迦か。
後者は結合後に抽出してんだろが。

766 ：仕様書無しさん：2008/04/03(木) 18:21:33

文脈読めよ。
>>761の
-- そういやこないだ、
--　　JOIN ～ ON (～ AND HOGE = 0)
-- なんて記述を見かけた。

に対して >>764 だ。

767 ：仕様書無しさん：2008/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 ：仕様書無しさん：2008/04/03(木) 20:33:26

ここで悦に入って何か得られるモノがあるのだろうか･･･

769 ：仕様書無しさん：2008/04/03(木) 22:56:03

>>732のようなコードのメンテをやらされてると、この仕事辞めたくなるな。
そんなもんの修正はそれに違和感感じない連中だけでやってくれって感じだ。

770 ：仕様書無しさん：2008/04/04(金) 07:34:06

>>732
なんだこれ・・・
こんなんjavaで書いてきたらソースレビューの時点で突っ返すぜ
もし下請けが書いてきたらくびになっても検収印はおさねえ！

771 ：仕様書無しさん：2008/04/04(金) 07:37:39

出来ない奴はとっとと氏ね

ってことだな。

772 ：仕様書無しさん：2008/04/04(金) 09:05:47

>>769
俺は
　sWhere += ～
　sWhere += ～
　sWhere += ～
　　　:
こういうのが並んでる時点で唾棄。

773 ：仕様書無しさん：2008/04/04(金) 09:44:07

sprintf( buf, "select %s from %s\n", col, tbl );

774 ：仕様書無しさん：2008/04/04(金) 09:47:30

質問です。

各テーブルごとにテーブルクラスを作成し、

データの受け渡し受け取りには、テーブルクラス.レコードを定義して使用しています。

で、各テーブルごとの違いは、レコードクラスの違いくらいであとの処理は同じなので、

同じ処理を書いて、あまりステップ数を膨らませるのは嫌なのですが、

何かよい方法はないでしょうか？

775 ：仕様書無しさん：2008/04/04(金) 09:55:19

>>774
>質問です。
ｽﾚの選択も満足にできないの？

776 ：774：2008/04/04(金) 10:01:21

SQL文ハードコーディングを嫌がるスレということなので、
↑の質問にも答えてもらえると思ったのですが、ちょっとスレ変えることにします

777 ：仕様書無しさん：2008/04/04(金) 20:33:23

>>774
javaならhibernate使えよ。

778 ：葉猫 ◆Jz.SaKuRaM ：2008/04/04(金) 21:40:57

継承も使えずにクラスを使うとはなかなかやりまつね

779 ：仕様書無しさん：2008/04/04(金) 21:41:56

はずかしげもなくまだ生きてる貴様に比べれば誤差未満だな

780 ：仕様書無しさん：2008/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でやってる人いる？

781 ：仕様書無しさん：2008/04/05(土) 19:57:42

>>780
あー、すごいねー。ほんとにすごいよー。たいしたもんだねー。
ほかにだれもまねできないよー

782 ：仕様書無しさん：2008/04/05(土) 19:59:42

>>780
ポスグレ？オラクルで組めよ。

ちなみに　SQLいんじぇくしょん　ってしってまつか？

783 ：仕様書無しさん：2008/04/05(土) 20:16:48

>>781,782
ほめてもらう or 煽りを期待してるわけじゃない。

よりいい方法を知ってる人がいたら、教えて欲しいだけ。

784 ：780,783：2008/04/05(土) 20:19:52

ここID表示なしか。

ついでに言うと、Oracle、DB2対応済み。
SQLインジェクションとか当たり前のように対応済み。
sprintf ではなく snprintf を使ってることから予想付いた人も多いと思うけど。

785 ：仕様書無しさん：2008/04/05(土) 20:24:01

その関数使うと桁あふれ起こすかも知れんのじゃ？

786 ：仕様書無しさん：2008/04/05(土) 20:24:56

こんなエサに俺様がクマー（AA略

787 ：780,783：2008/04/05(土) 20:31:01

>>785
いいつっこみ。ありー。
セキュリティも兼ねてSQL文に文字列制限入れてる。

最近のオープンソースのDBはほとんどSQLの長さ制限はなくなってきたから、
そろそろこのAPIの長さ制限も取り払った方がいいかもしれない。
ただ最近のMySQLに詳しくないから、調べないと・・・。

788 ：仕様書無しさん：2008/04/05(土) 20:31:42

>>784
予想がつくのはエスパーだけだ

789 ：仕様書無しさん：2008/04/05(土) 20:35:27

そのAPIは評判良いの？
俺が使わないといけない立場だったら嫌だなぁ。
俺はストアドで組むのがしょうにあってるわ。

790 ：780,783：2008/04/05(土) 20:38:58

>>789
いろいろ機能つけすぎて、ほとんど自分専用（笑）・・・ orz

もしオープンソースにするとかなったとしたら、
もっとよく使う機能だけに絞ってとかやらないと普及しないんだろうねー。
もしくはよっぽど設計を考えて、スマートに分かりやすくするか。

もっとも今どきCでこんなAPIの需要は少ないか・・・。

791 ：仕様書無しさん：2008/04/05(土) 20:45:13

>>790
そんな部分だけ見せられても
エスパー以外には評価のしようがないがな。

見えてる部分だけだと、それやばくね？・・・ってのが正常な反応と思。

792 ：仕様書無しさん：2008/04/05(土) 20:47:24

>基本的なテーブルのselectややinsertやupdateなら一切SQLを書くことも見ることもない。

「基本的」という言葉の意味が定義されていないので他人には使えない。

793 ：仕様書無しさん：2008/04/05(土) 20:53:55

てか、いきなり使用例出してきてこれAPIって何？せんずり？
Cはともかく日本語で出せ。つか人に見せてないもん普及とか言うな。クズ。

794 ：780,783：2008/04/05(土) 20:54:38

>>791
確かに。けど、ソース公開はどこかに
未発見のセキュリティホールあったらやばいから出来ないし。
すまん。

>>792
比較演算子: OR AND = != < > <= >= like
フィールド型: 文字、数値、日付、時刻など
他: ()

where句の組み立てなんかは、
オープンソースDBのSQL分析のソースを参考にして作ると、
もっと柔軟な検索条件に対応したAPIが出来そうな予感。

しかしそこまで行くと、検索条件をいちいち関数呼び出して登録するより、
直接SQL文を書いた方が早いぜってことにもなりそう。

もっとも拡張性やメンテナンスを考えれば、直接SQLを書くのはナンセンスなんだろうけど。
そこは開発コストと将来のコストのどっちを優先するかって話しになりそう。

795 ：780,783：2008/04/05(土) 21:01:22

比較演算子に OR AND 入ってるのは変だな。

>>793
日本語で説明するにも、面倒すぎて。
すまん、自前APIに関しては、もうスルーしてくれ(--;

796 ：仕様書無しさん：2008/04/05(土) 21:49:27

>>793
よくコード一ステップごとに日本語コメントを書いて提出しろとほざく馬鹿SEPGがいるけど
コードそのものが体を現してるのに何をほざいてるのだと。お前がまさにその典型。
これが理解できない人はさっさと尻まくって引きこもりでもしてなよ。
じゃなきゃ金払うか頭下げて教えを請うんだな。

797 ：仕様書無しさん：2008/04/05(土) 21:54:41

>>796
ほお。じゃこれで
＞insertやupdateなら一切SQLを書くことも見ることもない。
もわかるわけだ。すげぇな。エスパー。

798 ：仕様書無しさん：2008/04/05(土) 22:46:47

>>780が自作APIだって？プププ

799 ：仕様書無しさん：2008/04/05(土) 22:52:51

>>790
自分専用って…
プロジェクトメンバー各人がこんなふうな勝手な実装をしているの？
大丈夫なのか、それ？

800 ：仕様書無しさん：2008/04/05(土) 23:37:16

寝た子は殴るなという言葉があるだろう

801 ：仕様書無しさん：2008/04/05(土) 23:39:43

　　テーブル名を元にDBからテーブル構成引っ張ってきて
　　処理系毎のパディングを考慮した構造体の配列に
　　突っ込む関数

というものは作ったが。
「SQLくらい手前で書けよ。莫迦しかいねぇのかこの会社」
と呪いの言葉を吐きながら。
(尤も、前時代的なSQLなんてもんは個人的には捨てちまいたいんだが)

ま、テーブルの結合だの副問い合わせだのがなけりゃ
新人でも作れるわな。
唐突かつ自慢げにこんなところで語り始める程のもんじゃない。

802 ：仕様書無しさん：2008/04/06(日) 00:28:28

おいそこのバーコード
SQL文ハードコードやめねぇと
てめぇの頭の毛毟るぞ？

っていったら先週から出社拒否ですよ
なんてヘタレなんだよ

803 ：仕様書無しさん：2008/04/06(日) 02:53:22

どうだこのAPIすげーだろ！一切SQLを書くことも見ることもなくてすむんだぜ！

反応 >>8

804 ：仕様書無しさん：2008/04/06(日) 02:58:02

誰かAPIの意味を教えてやれ

805 ：仕様書無しさん：2008/04/06(日) 04:36:51

AんたのPリクラIりません

806 ：仕様書無しさん：2008/04/06(日) 05:51:27

O/Rマッパー使えばいいじゃん。

807 ：仕様書無しさん：2008/04/06(日) 05:54:04

いっさいSQL見せないAPI(?)だったら、最初からSQLのレイヤ使わなきゃいいのに、
内部でへんちくりんなSQLごりごり生成して性能落としたあげく、対応できない
複雑な処理にはSQLが直接使えて便利だぜ！ってのはなんか違うんじゃ。
もともとSQLそのものがオーバヘッド大きいのに、その上にかぶせてもなぁ
いっそクエリを言語仕様にいれちまえ、っつMSの判断はアリだはと思うけど。

808 ：仕様書無しさん：2008/04/06(日) 05:55:31

最近複雑なSQLを書かなくなったな。

JOINとWHEREとORDER BYがすべて入るような
SQLだとインデックスをうまく使いづらいんだよね。

結果的にデータ読み込みの行数が跳ね上がって
逆に遅くなってしまう。

809 ：仕様書無しさん：2008/04/06(日) 06:00:39

これだけはいわせてくれ。

条件の数が可変で、AND とか OR とかそれをつないでいく処理は
文字列結合で作っていくんじゃなく、

配列に入れておいて、最後で join(" AND ", 条件入れた配列) という風にしなさい。

810 ：780,783：2008/04/06(日) 07:14:09

>>799
担当分けしてる。
引き継ぎが大変だろうなと思う今日この頃。

>>801
同じく作った。

>>807
なるほど、今まで考えたこともなかった。
SQLを使わずDBサーバと直接接続する方法のヒント教えてー。調べてみる。

>>808
同意。

>>809
Cにそんな便利な関(ry

811 ：仕様書無しさん：2008/04/06(日) 07:18:43

>>810
> >>809
> Cにそんな便利な関(ry

作れ！

812 ：810：2008/04/06(日) 07:24:52

>>811
ネタに(ry

おそらく >>809 は検索条件は構造体に入れておき、
最後に組み立てろってことを言いたかったんじゃないかと。
ついでに言うと () とかに対応するために、
その構造体はツリー構造にしておいた方がいい。

813 ：仕様書無しさん：2008/04/06(日) 08:07:40

>>802
それ普通に裁判沙汰になるよ
妄想もほどほどに

814 ：仕様書無しさん：2008/04/06(日) 09:02:47

>>812
じゃなくて単にヒープの無駄遣いと文字列コピーのコストを抑えろ、ということだろ>>809は。

815 ：809：2008/04/06(日) 13:55:39

いや、そんなコストとかの話ではなく、

str += "where";
str += "flag=true";
str += "and value=1";

↓

whereflag=trueand value=1

なんて間抜けをやらないですみますよということ。
条件の数が可変で引数によってつけたりはずしたりすると、
where and value=1 とかやってしまうだろ？という話。

joinのようなもので最後にくっつければ、絶対andの前後にスペース入れられるし、
whereのあとにいきなりandがでてきたりなんて事を防げる。

816 ：仕様書無しさん：2008/04/06(日) 16:09:41

おまえはandしか使わんのか？
つか、レベル低すぎだな、この手の話題

817 ：仕様書無しさん：2008/04/06(日) 16:10:07

もっとつまらん理由でしたとさ。

818 ：仕様書無しさん：2008/04/06(日) 16:35:59

この手の詰まらん事を意識できない奴にはいつまでたっても最良のコードは書けないよ。

819 ：仕様書無しさん：2008/04/06(日) 16:38:50

いや、正直>>815のレベルで最適なコードとか言われても…

820 ：仕様書無しさん：2008/04/06(日) 16:52:04

もっとブレークスルーなやつたのむ

821 ：仕様書無しさん：2008/04/06(日) 17:06:28

>>815
そんな低レベルの話だったのかｗ
期待して損したｗ

822 ：仕様書無しさん：2008/04/06(日) 17:16:26

809
m9(^Д^)ﾌﾟｷﾞｬｰ

823 ：仕様書無しさん：2008/04/06(日) 19:58:57

>>809
WHERE 1=1
AND xxx = :xxx
AND yyy = :yyy
AND zzz = :zzz

これで解決じゃね？

824 ：仕様書無しさん：2008/04/06(日) 20:51:10

おいだれか、この中国人をつまみだしてくれ

825 ：仕様書無しさん：2008/04/06(日) 21:06:45

823は、よく使われてるテクニックだよ。
RoRのソースにもあった希ガス。

826 ：仕様書無しさん：2008/04/06(日) 21:08:17

Railsなんて糞に決まってるだろ

827 ：仕様書無しさん：2008/04/06(日) 21:13:45

>>825
その使い方はここの話の本筋とは関係ない。

828 ：仕様書無しさん：2008/04/06(日) 21:25:24

つか普通は823のテク使うだろｗ

829 ：仕様書無しさん：2008/04/07(月) 12:44:36

一年前そのシチュエーションでは文字列結合で作った。
反省はしていない。次回以降は823のやり方にする。

830 ：801：2008/04/07(月) 12:58:44

>>809 がｽﾚのレベルを一気に下げたな。

>>810
>同じく作った。
…>>801 の後段は君に言ってんだけど。

831 ：仕様書無しさん：2008/04/07(月) 20:51:55

ハードコーディングと表現する奴は、
プリコンパイラの仕組みも知らない初心者だな。

832 ：仕様書無しさん：2008/04/07(月) 21:05:19

はあ？？？プリコンパイラなんて何の関係もないだろ・・・

833 ：仕様書無しさん：2008/04/07(月) 21:15:17

>>832
はあ？関係大ありだよ！

834 ：仕様書無しさん：2008/04/07(月) 21:35:39

>>808がよくわからん
インデックスを全て指定するのにその順番で書かない時はどんな時なの？？？

835 ：仕様書無しさん：2008/04/07(月) 22:01:34

複雑なSQLも落ち着いて分解すると
単純なSQL数個に分けられる

836 ：仕様書無しさん：2008/04/07(月) 22:16:40

で、プリコンパイラがどうしたって言うんだ

837 ：仕様書無しさん：2008/04/07(月) 22:24:03

カオスw

838 ：仕様書無しさん：2008/04/07(月) 22:33:53

ソースコードに直接SQL文を書くことを何て言うかなんて、
入門書にも出てくる初歩的な用語なわけで、
ハードコーディングとの違いも分からないようでは情けないな。

839 ：仕様書無しさん：2008/04/07(月) 22:34:16

全文検索になるってことだろ

840 ：仕様書無しさん：2008/04/07(月) 23:59:48

>>838
埋め込みSQLｗ

841 ：仕様書無しさん：2008/04/08(火) 00:14:17

話が滅茶苦茶というか
各人のイメージしているものがそれぞれ違うような気がしてきた

842 ：仕様書無しさん：2008/04/08(火) 00:16:06

ダバダの人
違いを教えてよ

843 ：仕様書無しさん：2008/04/08(火) 00:20:33

ホント2chって、どうでもいいSQL見たいな
素人レベルのことだとスレが伸びるのね。

ここぞって時の質問はスルーなのにねぇ。

844 ：仕様書無しさん：2008/04/08(火) 00:26:29

↓ここぞって時の質問

845 ：仕様書無しさん：2008/04/08(火) 00:28:48

↑矢印厨

846 ：仕様書無しさん：2008/04/08(火) 00:36:53

>>844
なんで俺には彼女が出来ないの？

847 ：仕様書無しさん：2008/04/08(火) 00:37:11

自転車小屋議論ですから。

848 ：仕様書無しさん：2008/04/08(火) 01:43:50

>>843
ここにはｵﾚﾖﾘﾓﾏｲﾗﾊレベルが低いとｵﾏｲﾊ思いたい
と書いてある。

849 ：仕様書無しさん：2008/04/08(火) 07:02:11

プリコンパイラまだ～？

850 ：仕様書無しさん：2008/04/09(水) 00:19:11

>>838
で、なんて言うの？まさか >>840 じゃないよね？

851 ：仕様書無しさん：2008/04/09(水) 01:31:19

基礎知識が無いというのは、
プログラム書く前にマニュアルとか読まずに、
先輩に要点だけ教わって書いてるのかね？

852 ：仕様書無しさん：2008/04/09(水) 06:54:31

シッタカ君がよく使う逃げ口上

853 ：仕様書無しさん：2008/04/09(水) 07:02:03

スレタイが知ったかそのものなわけだがw

854 ：仕様書無しさん：2008/04/09(水) 19:16:38

↓↓というわけで、プリコンパイラさん、どうぞ～ ↓↓

855 ：仕様書無しさん：2008/04/09(水) 20:10:29

恥を書く前に入門書からコツコツ勉強しましょう。

856 ：仕様書無しさん：2008/04/09(水) 20:19:44

ほんと恥かしいよ、プリコンパイラさん。馬鹿まるだし。

857 ：仕様書無しさん：2008/04/09(水) 20:37:51

"ＳＱＬ"と”ハードコーディング”でググってみたことあるかい？
このスレ以外では、間違って使う奴すらいないぞ。

858 ：葉猫 ◆Jz.SaKuRaM ：2008/04/09(水) 21:30:42

このｽﾚが上位をほぼ独占ちててﾜﾛﾀ

859 ：仕様書無しさん：2008/04/10(木) 00:22:08

さっさと死ねよ屑コテ

860 ：仕様書無しさん：2008/04/10(木) 04:11:21

ハードコーディング⊇埋め込み
だろ?

EXEC SQL ～
とかやって、プリコンパイラ(Pro*C とか)で変換するのが埋め込み SQL(ハードコーディングの一種)
それ以外でも直接 SQL をソースに書くのが(埋め込みじゃない)ハードコーディング

何も難しくないだろ。

861 ：仕様書無しさん：2008/04/10(木) 04:23:22

>>860
じゃMSのLINQは言語の一部だからハードコーディングじゃないのか。
もっともあれはSQLじゃないといえばそうだけどさ。

862 ：仕様書無しさん：2008/04/10(木) 05:58:01

>>860
残念ながら、ググっても出てこないのだから、そういう「ハードコーディング」の解釈は一般にはないのだよ。

863 ：仕様書無しさん：2008/04/10(木) 06:52:58

自分の無知を棚に上げてよく言うわ

864 ：860：2008/04/10(木) 07:00:11

>>861
LINQ, SQL の場合に限らず、なにかコードに直接書いたら、
何でもハードコーディングと呼ばないか?
860 もコードに直接書く場合しか書いてない。

865 ：仕様書無しさん：2008/04/10(木) 07:10:49

「ハードコーディング」は実行時の状態も関係してるから、
プリコンパイルの仕組みを理解していれば、
「ハードコーディング」と呼ぶことはないだろう。

866 ：仕様書無しさん：2008/04/10(木) 07:41:45

http://e-words.jp/w/E3838FE383BCE38389E382B3E383BCE38389.html

867 ：仕様書無しさん：2008/04/10(木) 07:48:22

「プリコンパイラ」はコンパイラの前に動くものなのだから、
ハードコーディングとは何かを理解していれば、
「プリコンパイラ」を持ち出すことはないだろう。

868 ：仕様書無しさん：2008/04/10(木) 07:59:39

>>867
それは、プリコンパイルも実行状態も理解してないから、そう思うのだ。

869 ：仕様書無しさん：2008/04/10(木) 09:28:40

でもさ、SQLってそもそも人間がいちいちISAMなんかのアクセスを
ハードコーディングしないように抽象化するために作ったもんだろ？
それをまた関数のパラメータに押し込んで、API(笑)化するのって
全然可読性を上げてることにならないような気がするんだけど。
皆がちゃんとSQLを学べば、テキストでSQL組み上げるような無様な関数
作らなくても全然平気じゃないか？第一、SQLがまともに使えないヤツが
その関数を楽々使えるとも思えないんだけどな。

870 ：仕様書無しさん：2008/04/10(木) 13:23:44

>>869
つか、それを言い出したらO/Rマッパは…ってなるような希ガスｗｗｗ
事実、O/Rマッパなんて要らないけどさ。

871 ：仕様書無しさん：2008/04/10(木) 18:58:47

printf("Hello, World!\n");

これもハードコーディングって言うんだろうなぁ

872 ：仕様書無しさん：2008/04/10(木) 19:41:12

if (flag & 3) ...
これもハードコーディングと言うんだろうね。

873 ：仕様書無しさん：2008/04/10(木) 22:43:49

>>869
勉強もせず自分で勝手に想像して、「ちゃんとSQLを学べ」は自分だろw

874 ：仕様書無しさん：2008/04/10(木) 23:13:19

プリコンパイラが最適化してくれるとも思ってるのか、このバカちんは

875 ：仕様書無しさん：2008/04/10(木) 23:16:26

SQL文そのものなんてソース内で見ないまま扱えるようにクラス作りゃいいんだけど
でもねぇ

876 ：仕様書無しさん：2008/04/10(木) 23:19:44

>>871
それは明らかにハードコーディングだ
i18nって知ってる？

877 ：仕様書無しさん：2008/04/10(木) 23:22:31

物質の表面改質の為に、TiN, TiAlN, TiCN, CrN, DLCなどを
アークイオンプレーティング法などを用いて成膜し、
表面の硬度や耐摩耗性を高める。

878 ：仕様書無しさん：2008/04/10(木) 23:23:12

それはコーティング

879 ：仕様書無しさん：2008/04/10(木) 23:23:59

>>872
それはマジックナンバー

880 ：sage：2008/04/10(木) 23:25:43

それはハードコーティング

881 ：仕様書無しさん：2008/04/10(木) 23:28:07

>>874
さて、プリコンパイラは何をしてるのでしょうか？
それが分かれば、 >>871 や >>872 との違いも分かるでしょう。

882 ：仕様書無しさん：2008/04/10(木) 23:30:25

降参です答えを教えてください

と言えばこういう人は確実に逃げる

883 ：仕様書無しさん：2008/04/10(木) 23:33:04

>>882
オマエみたいに偉そうなバカに教えるわけがありません。

884 ：仕様書無しさん：2008/04/10(木) 23:33:39

頭の中で何となく理解しているつもりの事柄を
他人にしっかり説明しようと文章を書き始めてみる。

そのときに初めて、自分の知識がいかに曖昧で
本当は殆ど何もわかっていないということに気付く。

885 ：仕様書無しさん：2008/04/10(木) 23:35:50

>>884
自分で考えるのではなく、マニュアルを読め。

886 ：仕様書無しさん：2008/04/10(木) 23:36:37

まさかプリコンパイルされた後のソースを、コンパイルする前に
手で修正できるから、元ソースはハードコーディングじゃねーとか
わけわけめなこと言うんじゃねーだろうな、ウンコ野郎

887 ：仕様書無しさん：2008/04/10(木) 23:37:19

まともな RDBMS なら内部にクエリキャッシュを持っているので
実行時に SQL 文字列を毎回パーズして実行するなんていう馬鹿な処理にはならない。
そんなことは誰でも知っている常識

それとハードコーディングの問題は無関係

888 ：仕様書無しさん：2008/04/10(木) 23:39:31

ソフトコーディングもあるのかな

889 ：仕様書無しさん：2008/04/10(木) 23:44:25

でプリコンパイラは何をするのかな？もう逃げたか？

890 ：仕様書無しさん：2008/04/10(木) 23:53:14

>>886
やっぱり、プリコンパイルが何するか分かってないね。
自分で勝手に考えずに、マニュアル読めよ。

891 ：仕様書無しさん：2008/04/11(金) 00:00:32

埋め込みSQLを展開してるだけだろ
埋め込んだSQL文が勝手に最適化されるわけじゃないし
ハードコーディングじゃないということとは関係ないじゃん。

892 ：仕様書無しさん：2008/04/11(金) 00:06:03

知ったかぶりで上から目線で煽って、相手に文章を書かせる。
それによって自分が勉強する。技術系板の典型的厨房

893 ：仕様書無しさん：2008/04/11(金) 00:06:38

>>891
想像で書くな。マニュアル読め。

894 ：仕様書無しさん：2008/04/11(金) 00:09:18

なんだよ結局逃げかよ
具体的に説明してくれよ、プリコンパイラがこうするから
ハードコーディングじゃないよねって

895 ：仕様書無しさん：2008/04/11(金) 00:12:41

そもそもプリコンパイラって時点で具体的なDB製品に依存してるし…
顧客の予算やスケールに応じて組み合わせるDBを変更するとか
想像もつかないんだろうなこの人は

896 ：仕様書無しさん：2008/04/11(金) 00:14:39

>>894
それ教えちゃったら、面白くないでしょwww

897 ：仕様書無しさん：2008/04/11(金) 00:16:17

SELECT命令以外実行する権限が与えられていないのだ・・・

898 ：仕様書無しさん：2008/04/11(金) 00:17:25

http://en.wikipedia.org/wiki/Hard_coding

899 ：仕様書無しさん：2008/04/11(金) 00:18:41

ぐぐってもPro*Cしか出てこない。Oracle限定の話?

900 ：仕様書無しさん：2008/04/11(金) 00:19:58

>>896
同意。教えたら「なんだそんなことか、付き合って損した放置放置」で終わっちゃうよね

901 ：仕様書無しさん：2008/04/11(金) 00:20:36

少なくとも、このスレ以外ではSQL文をソースに書くことをハードコーディングとは
呼んでいないという現実を真摯に受け止めて、一から勉強することだな。

902 ：仕様書無しさん：2008/04/11(金) 00:21:49

esqlも知らんのか

903 ：仕様書無しさん：2008/04/11(金) 00:21:57

なんでスレが900に行こうというときに用語の定義でもめ始めるんだよwww。
その時点で普通のプロジェクトならデスマーチになってる。

904 ：仕様書無しさん：2008/04/11(金) 00:21:58

>>899
他の製品でもあるけど
基本的に埋め込みSQLをライブラリ・コールに変換するだけ
埋め込んだSQLが変化するわけではない。

905 ：仕様書無しさん：2008/04/11(金) 00:23:22

そりゃあプログラミングの観点から言えば
ハードコードされるのは文字列だからなあ。

ハードコードされる文字列の中身がSQLだってだけ。

で、何か？

906 ：仕様書無しさん：2008/04/11(金) 00:23:22

>>876
へー、ハードコーディングって言うんだ

907 ：仕様書無しさん：2008/04/11(金) 00:24:03

いいから逃げないで答え言えよ

908 ：仕様書無しさん：2008/04/11(金) 00:26:06

変数使ってるからってことだろ

909 ：仕様書無しさん：2008/04/11(金) 00:27:58

sql = "select * from emp where empno = ?";
これもハードコーディング？

910 ：仕様書無しさん：2008/04/11(金) 00:28:40

>>903
実際のプロジェクトでもよくあるだろ
途中から変なのが登場して最初から全部説明させられて挙句ひっくり返される

911 ：仕様書無しさん：2008/04/11(金) 00:29:39

>>872
マジックナンバーじゃない？

912 ：仕様書無しさん：2008/04/11(金) 00:31:31

O/Rマッパーでも、静的に事前に解析する奴は、ハードコーディングじゃねーの？

913 ：仕様書無しさん：2008/04/11(金) 00:33:00

resultset.column(0) ←ハードコーディング
resultset.column("id") ←ハードコーディング

914 ：仕様書無しさん：2008/04/11(金) 00:33:51

customers.id ←ハードコーディング

ハードコーディングじゃない奴ってどんなんだｗ

915 ：仕様書無しさん：2008/04/11(金) 00:34:58

static final ID = "id";
...

resultset.column(property.get(ID));←ハードコーディング？

916 ：仕様書無しさん：2008/04/11(金) 00:35:10

要するに、真性包茎はハードコーティング
仮性包茎は動的コーティング

917 ：仕様書無しさん：2008/04/11(金) 00:35:50

スレ流し読みしたが、prepared statement使えばハードコーディングじゃないって奴もいるみたいだな

918 ：仕様書無しさん：2008/04/11(金) 00:37:16

DB変わっても、テーブルレイアウト変わっても、ちゃんと動くのがソフトコーディング

919 ：仕様書無しさん：2008/04/11(金) 00:37:18

まずは、ハードコーディングの定義を何回も読むことだな。

920 ：仕様書無しさん：2008/04/11(金) 00:37:34

設定ファイルに書けばハードコーディングじゃないってのも意味不明

921 ：仕様書無しさん：2008/04/11(金) 00:40:25

テキストファイルに、
0:select * from emp
1:select * from emp where empno=?
2:select * from emp where empno=? and sex=?
とか書いて、それ読んで実行しろよｗ

922 ：仕様書無しさん：2008/04/11(金) 00:41:23

sql = GetSQLStatement(1) ← ハードコーディング

923 ：仕様書無しさん：2008/04/11(金) 00:41:24

場合によってはアリかもしれぬ・・・

924 ：仕様書無しさん：2008/04/11(金) 00:44:52

ハードコーディングするかどうかは本質じゃないってことだな

925 ：仕様書無しさん：2008/04/11(金) 00:45:10

Railsみないなやつも、コード生成が自動ってだけで、ハードコーディングだよね

926 ：仕様書無しさん：2008/04/11(金) 00:47:18

こりゃもうDDLから動的に生成する必要があるな

927 ：仕様書無しさん：2008/04/11(金) 00:47:24

このスレを見ている人はこんなスレも見ています。(ver 0.20)
【DI】Java Spring Framewoｒｋを語るスレ 2.0 [プログラム]

これウケる。このスレから得るもんなんてねーぞｗｗ

928 ：仕様書無しさん：2008/04/11(金) 08:40:12

バカばっか

929 ：仕様書無しさん：2008/04/11(金) 11:21:56

>>919
>ハードコーディングの定義
not well defined

930 ：仕様書無しさん：2008/04/11(金) 19:52:02

結局プリコンパイラ君は説明できないんだね。にわかってこれだから困るんだよ。

931 ：仕様書無しさん：2008/04/11(金) 21:20:14

>>929
それじゃ、具体的にオマエの思うハードコーディングしたSQL文とハードコーディングしてないSQL文の例を
挙げてくれれば、オマエ流のハードコーディングの定義が分かる。

932 ：仕様書無しさん：2008/04/12(土) 00:38:08

もう見飽きたよ
待ちガイル　vs　待ちガイル

933 ：仕様書無しさん：2008/04/12(土) 00:58:35

>>932
たとえベタ

934 ：仕様書無しさん：2008/04/12(土) 01:08:58

>>933
示すものが判れば構わないさ
上手なお手本の一つも持ち合わせているんだろうね。楽しみにしておくよ。

935 ：仕様書無しさん：2008/04/12(土) 01:10:52

>>934
意味不明

936 ：仕様書無しさん：2008/04/13(日) 21:46:37

ＳＱＬをデータベースに格納しとけばいいんじゃない？

937 ：仕様書無しさん：2008/04/13(日) 22:09:44

場合によってはアリかもしれぬ・・・

938 ：仕様書無しさん：2008/04/13(日) 22:55:59

>>936
天才現る

939 ：仕様書無しさん：2008/04/13(日) 23:23:35

意外とアリな気がしてきた

940 ：仕様書無しさん：2008/04/13(日) 23:45:20

SQLじゃなくて、プリコンパイルした結果をRDBに格納すればいいんだよ。

941 ：仕様書無しさん：2008/04/14(月) 00:02:28

>>940
それじゃ、人間が保守できないだろ。

>>936
ちなみにクエリの一部をDBに保存と言うのは俺の受け持ってる案件でもよくやってるよ。
RDBMSの種類やデータ量によってコストが変動する部分のクエリはロジックを変更せず
かつ動的に置き換え可能にしたかったからな。
まぁ、O/Rマッパーに依存してたらなかなか使いにくい手法だと思うが。

942 ：仕様書無しさん：2008/04/14(月) 04:30:45

SQLをRDBに格納ってオブジェクト指向だしな

943 ：仕様書無しさん：2008/04/14(月) 07:06:28

>>936
> ＳＱＬをデータベースに格納しとけばいいんじゃない？

>>670-675

>>942
> SQLをRDBに格納ってオブジェクト指向だしな

え? 解説希望。

944 ：仕様書無しさん：2008/04/14(月) 08:04:11

>>936
糞仕様以外のなにものでもない

945 ：仕様書無しさん：2008/04/14(月) 15:32:31

>>941
もちろんソースはソースでちゃんと管理するんだろ。

946 ：仕様書無しさん：2008/04/14(月) 16:33:38

ソースもDB格納

947 ：仕様書無しさん：2008/04/14(月) 21:59:31

>>946
天才現るｗｗ

948 ：仕様書無しさん：2008/04/14(月) 22:09:32

リポジトリ≒DB

繋がった。

949 ：仕様書無しさん：2008/04/14(月) 23:31:34

バイナリが格納できることを考えれば理論上なんでも出来る・・・・んだよねぇ

950 ：仕様書無しさん：2008/04/15(火) 00:27:18

というか、ファイルシステムって一種の DB だよね。
だからって、RDB に SQL 格納ってのがいいとは言わんが。

951 ：仕様書無しさん：2008/04/15(火) 01:06:03

>>949
マジで？空も飛べるの？

952 ：仕様書無しさん：2008/04/15(火) 01:18:17

>>950
http://opentechpress.jp/developer/08/02/21/0051246.shtml
ファイルシステムをDBに保存するというのを思い出した。

953 ：仕様書無しさん：2008/04/15(火) 11:33:04

>>951
Oracleはよく空を飛ぶ

954 ：仕様書無しさん：2008/04/15(火) 19:36:45

>>952
そういえば、Windows Vistaも一時そんなことをやろうとして挫折したよな。

955 ：仕様書無しさん：2008/04/15(火) 20:49:52

WinFSという幻のことかい？

956 ：仕様書無しさん：2008/04/15(火) 23:47:24

>>952
>>954-955
不思議なんだけど、OSが起動するファイルシステムとDBに保存されたファイルシステムは別物なの？
WinFSは起動ファイルシステム＝DBのファイルシステムかなと思ってたんだけど。

957 ：仕様書無しさん：2008/04/15(火) 23:49:48

とりあえずぐぐってみるといいと思うよ

958 ：仕様書無しさん：2008/04/17(木) 05:48:23

そもそもRDBもよく分かってないから、スレタイみたいな発想になるんだろうな。

959 ：仕様書無しさん：2008/04/18(金) 19:23:13

WinFSはファイルの種別やタグをDBに放り込んで、ファイルの検索を容易にする物じゃなかったっけ？
たとえば「エロデータ」を検索すればエロ小説のテキストやエロ画像、エロ動画が抽出できるとか。

960 ：仕様書無しさん：2008/04/18(金) 19:40:46

>>959
そのエロデータ検索方式をぜひGoogleに追加してくれ！

961 ：仕様書無しさん：2008/04/18(金) 23:49:34

>>959
その程度じゃspotlightと大差ないよーな。
もっと画期的な物になるはずだったにちまいない。

962 ：仕様書無しさん：2008/04/20(日) 21:55:05

正直データアクセスがちゃんと局所化、集約化されていれば外部ファイル化されていようがソースコード直だろうがどっちでもいい。

963 ：仕様書無しさん：2008/04/25(金) 00:20:04

カラムを追加すると検索結果のカラムの並びが変わるからダメだと言い張る協力会社さんをどうやって説得したものやら．
いいよなぁ，マスタテーブルのカラム構成に変更があるたびに検索している箇所を全て修正して金を要求できるんだから．

964 ：仕様書無しさん：2008/04/25(金) 00:23:16

つ　View

965 ：963：2008/04/25(金) 00:28:37

>>964
説明が足りずにすまん．
そんな高度なレベルじゃなくて"select * "な人であるのが問題なんです｡･ﾟ･(ﾉД`)･ﾟ･｡

966 ：仕様書無しさん：2008/04/25(金) 00:49:43

>>965
select *でもそんなに困らないだろ。困るのはinsertでカラム指定してない場合な。

稼動しているシステムだとテーブルをドロップできないから、後ろに追加になって
いって横着できなくなる。

967 ：仕様書無しさん：2008/04/25(金) 01:25:13

そうそう、selectにしろinsertにしろスキーマが変わることを考慮していない奴が多い。
トランザクションの保証になんてたどり着くのはいつの日やら。

968 ：仕様書無しさん：2008/04/25(金) 21:08:25

SELECT * が許されるのはEXISTSを使うときくらいだなぁ。

969 ：仕様書無しさん：2008/04/26(土) 01:35:50

>>963
おまえこそがダメだ　でいんじゃねの？　

970 ：仕様書無しさん：2008/04/26(土) 09:17:31

>>967
わかる奴から辞めていくからね orz

971 ：仕様書無しさん：2008/04/27(日) 16:41:46

カラム追加がダメとか、SELECT * がダメとか、レベル低すぎだろ。

972 ：仕様書無しさん：2008/04/27(日) 16:51:30

レベルが低すぎるのは事実だが、
それが日本のデジドカの現実でもある。

973 ：仕様書無しさん：2008/04/27(日) 20:57:00

>>971は意味わかって言ってんの？

974 ：仕様書無しさん：2008/04/30(水) 04:47:48

みんなやめていくからね

975 ：仕様書無しさん：2008/04/30(水) 22:01:14

残るのは人転がしの窓口だけさ

976 ：仕様書無しさん：2008/05/01(木) 07:27:38

SELECT * は使う奴が馬鹿だと
カラム追加にも対応できないクソコードになる。

普通はそうならんように作るもんだと思うがなwww

977 ：仕様書無しさん：2008/05/01(木) 19:34:14

カラムの順番を使わずに、フィールド名でデータ処理すればいいだけだけど、
それも出来ないほど技術力がない会社が日本にはゴロゴロしてるってことか。

978 ：仕様書無しさん：2008/05/01(木) 19:43:39

>>977
回線の無駄。

979 ：仕様書無しさん：2008/05/01(木) 21:13:37

カラム追加なんて起きないように縦持ちするのが普通じゃないの？

980 ：仕様書無しさん：2008/05/02(金) 14:01:52

>>979
異常www

981 ：葉猫 ◆Jz.SaKuRaM ：2008/05/02(金) 21:25:10

ストアドのパラメータを文字列化ちてクエリー実行なんてちてる池沼がいるんでつけど、
どうちたらいいでちょうか (´･ω･`)ｼｮﾎﾞｰﾝ

982 ：仕様書無しさん：2008/05/02(金) 21:36:19

カーソラーの現場に投入された俺は自殺したい

983 ：仕様書無しさん：2008/05/02(金) 23:22:34

>>980
異常じゃないと思う俺は異端なのか？

縦持ちするってのは

購入伝票テーブル
id, 購入日, 商品名1, 商品単価1, 商品名2, 商品単価2, ...,商品名n, 商品単価n

ではなく

購入伝票テーブル
id, 購入日

商品テーブル
id, 伝票id, 商品名, 単価

てな感じにテーブル設計するっていうことだろ？
まぁ、join時の死亡確率も上がるから痛しかゆしといえばそうなんだが、
一般的には後者のアプローチのが正義だよな？

984 ：仕様書無しさん：2008/05/03(土) 01:48:31

>981
ちてちてとかキモイ池沼がいるんでつけど、
どうちたらいいでちょうか (´･ω･`)ｼｮﾎﾞｰﾝ

985 ：仕様書無しさん：2008/05/03(土) 03:03:35

>>983
正規化って知ってるか…
縦持ちって、なにそのへんな用語。ちゃんと本読もうよ。

986 ：仕様書無しさん：2008/05/03(土) 03:08:19

一応、正規化することを指してるんだろうなぁと想像はしてたが
やっぱりそうだったか。

987 ：仕様書無しさん：2008/05/03(土) 03:09:25

DB 縦持ちに一致する日本語のページ約 1,580 件中 1 - 50 件目 (0.15 秒)

988 ：仕様書無しさん：2008/05/03(土) 03:10:22

普通に使われてるだろ。
>>985->>986
新卒ですか？

989 ：仕様書無しさん：2008/05/03(土) 04:16:16

>>988
コボラは横長DBがお好き 3カラム目
http://pc11.2ch.net/test/read.cgi/prog/1205338975/

990 ：仕様書無しさん：2008/05/03(土) 07:53:36

>>983
商品テーブルに伝票idいれんなよｗ　ってのはともかく、

縦持ちって正規化とはちと違って、
id, 項目id, 項目値
みたいにして、
ID01, 商品名, ぬるぽ
ID01, 単価, 1000
ってデータをつっこんでくやり方だと思う。

991 ：仕様書無しさん：2008/05/03(土) 08:24:40

>>990
そうそう。糞プロジェクトでそういうテーブル見たことある。
パフォーマンス落ちまくりなのをDBMSのせいにしてたよ、元請けのアフォSEは。

992 ：仕様書無しさん：2008/05/03(土) 13:55:21

いわゆる環境変数的な使い方ならいいんじゃねーの？
パフォーマンスに影響するほどの用途って思いつかないけど、どんなの？

993 ：仕様書無しさん：2008/05/03(土) 14:16:39

>>992
定数テーブルみたいなのならいいけど。
商品とか売上テーブルを>990みたいにするのは集計なんかのときものすごく
パフォーマンス落ちると思うぞ常考。

994 ：仕様書無しさん：2008/05/03(土) 14:38:09

>>992
普通に、データベースが必要になる程度の規模のデータとアクセス回数なら
縦持ちみたいな糞設計は話にならんだろ。

995 ：仕様書無しさん：2008/05/03(土) 14:41:21

環境設定は縦持ちしてる

996 ：仕様書無しさん：2008/05/03(土) 14:51:56

環境設定を>>990の例のようにするのは、縦持ちじゃなくて単なる正規化だろ。

997 ：仕様書無しさん：2008/05/03(土) 15:09:43

>>996
確かに。ということでこんなクソスレとっとと埋めちまおうぜ。

998 ：仕様書無しさん：2008/05/03(土) 15:55:04

>>997
くやしいのうｗｗｗｗくやしいのうｗｗｗｗ

999 ：仕様書無しさん：2008/05/03(土) 17:40:21

縦持ちってなんですか？
最近標準化された配列型のことですか？

わからないので、よろしくお願いします。

1000 ：仕様書無しさん：2008/05/03(土) 17:43:55

occurs 1000

1001 ：１００１：Over 1000 Thread

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。