[表示 : 全て 最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 901- 2chのread.cgiへ]
Update time : 12/16 17:55 / Filesize : 176 KB / Number-of Response : 928
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

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



1 名前:仕様書無しさん [2007/02/07(水) 01:32:56 ]
って思う

2 名前:専門卒(英語科)  田崎 [2007/02/07(水) 01:53:41 ]

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

3 名前:仕様書無しさん mailto:sage [2007/02/07(水) 01:54:00 ]
2ゲット

4 名前:仕様書無しさん mailto:sage [2007/02/07(水) 01:55:11 ]
あらゆるSQLはテキストにするプロジェクトに関わったことがある。
はっきりって何もいいことがない。

5 名前:仕様書無しさん [2007/02/07(水) 01:59:35 ]
ハードコーディングすると保守性さがんじゃん
何もいいことないとかバカじゃね?

6 名前:仕様書無しさん mailto:sage [2007/02/07(水) 02:02:26 ]
デバッグしづらいだけだろ。

7 名前:仕様書無しさん mailto:sage [2007/02/07(水) 02:05:46 ]
所詮プログラムと一対一になるものをわける意味がわからん。

8 名前:仕様書無しさん mailto:sage [2007/02/07(水) 02:06:33 ]
300行位使ってSQL成形するやつ見た事ある

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

9 名前:仕様書無しさん mailto:sage [2007/02/07(水) 02:09:13 ]
>>7
君この業界諦めた方がいいよ

10 名前:仕様書無しさん mailto:sage [2007/02/07(水) 02:15:39 ]
>>5
UIしかやったことのない厨房はひっこんでろ。



11 名前:仕様書無しさん mailto:sage [2007/02/07(水) 02:16:25 ]
>>8
3000行というやつもいたぞ。

12 名前:仕様書無しさん mailto:sage [2007/02/07(水) 02:18:48 ]
むしろ早くLINQみたいなのが出てくれと思ってる

13 名前:仕様書無しさん mailto:sage [2007/02/07(水) 02:19:13 ]
RDBをいじるプロジェクトには3回参加した。
C++の中にSQL文字列が埋まってるのは確かにちと無様だが、
未だにどうやるのがいいのか分からん。
ハードコーディングじゃない、ってのはどうやるんだ?

14 名前:仕様書無しさん mailto:sage [2007/02/07(水) 02:25:43 ]
SQL文を書かなくていい程度ですむプロジェクトにしか関わってないなら幸せだな
>>2,5 に同意

15 名前:仕様書無しさん mailto:sage [2007/02/07(水) 02:27:32 ]
>>13
リソースに突っ込んだり、
暗号化した独自の形式の何かに入れておいてそれを使うとかじゃねーの?
どこで何を使っているか等の管理が面倒になって工数が増すという利点がある。

16 名前:仕様書無しさん mailto:sage [2007/02/07(水) 02:30:15 ]
>>13
俺もわからん。

17 名前:仕様書無しさん mailto:sage [2007/02/07(水) 02:31:10 ]
>>14
ちょwwwどっちだ?

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

18 名前:仕様書無しさん mailto:sage [2007/02/07(水) 02:38:53 ]
DAOとかO/Rマッパーとかそういうのを意図していると思った > スレタイ

19 名前:仕様書無しさん mailto:sage [2007/02/07(水) 03:33:25 ]
>>18
そういう話題の方が意義があるよな。
SQLをプログラムから別にするだけで保守性が増すなんて猿以下のアイデアとしか思えん。
土台のモデルが腐っていればスパゲティ度がむしろ増加する。

20 名前:仕様書無しさん [2007/02/07(水) 08:38:43 ]
直書きするか否かというのはプログラマの裁量でなく、プロジェクト上の実装方針に依るのでマを責めてはいけない。
実装方針決定者はSQLの書き方に多様なアプローチがあることを知るべき。

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




21 名前:仕様書無しさん mailto:sage [2007/02/07(水) 08:40:52 ]
また変な宗教はやらせないでくれよ


22 名前:1 [2007/02/07(水) 08:41:11 ]
>>18
そういうこと

23 名前:仕様書無しさん mailto:sage [2007/02/07(水) 08:56:53 ]
引き継いで弄ってたソースがSQLべた書きだったんだが、
タダのべた書きではなく、プレースホルダすら使ってねぇ
べた書きだった。文字列連結しまくり。

まぁ、いろんな意味で
この会社辞めようと思ったソースコード#15
pc10.2ch.net/test/read.cgi/prog/1167117526/
向けだったな。実際会社辞めることにした原因の一つだし。


24 名前:仕様書無しさん [2007/02/07(水) 09:31:13 ]
センスがある奴と無い奴では目の付け所が違うんだよね。

>1さんなんか、もうセンスなさげな匂いがぷんぷんする。

25 名前:仕様書無しさん [2007/02/07(水) 10:34:34 ]
>>24
お前がセンス、ム板だったら、お前が言ってることはただしいが、
ここはマ板なので、むしろセンスないほうがセンスがいい。

26 名前:仕様書無しさん mailto:sage [2007/02/07(水) 10:55:26 ]
SQLを分離して、本体はビジネスロジックに集中ですね

27 名前:仕様書無しさん [2007/02/07(水) 12:04:57 ]
でたービジネスロジック厨w

28 名前:1 mailto:sage [2007/02/07(水) 12:05:32 ]
>>23
クラックされた某サイトが正にそれで、
プレースホルダを使ってない上に値をエスケープしてないがためにSQLインジェクションできまくりな
悲惨なソースコードだった

29 名前:14 mailto:sage [2007/02/07(水) 13:05:22 ]
>>17
ごめん >>2,10 に同意だった...orz


30 名前:仕様書無しさん mailto:sage [2007/02/07(水) 18:35:20 ]
SQLをごちゃごちゃする部分は極力ストアドにして、
プログラム側ではもっぱらそれを呼び出すことに専念
する方向でコーディングした俺は正解なんだろうか。



31 名前:仕様書無しさん mailto:sage [2007/02/07(水) 18:45:00 ]
ストアドはいくない

32 名前:仕様書無しさん [2007/02/07(水) 20:16:42 ]
ストアドか
それも選択の1つだけど
開発が面倒じゃない?
管理も

33 名前:仕様書無しさん mailto:sage [2007/02/07(水) 20:26:06 ]
一回組んだらそうそう変えないようなのは楽だしパフォーマンスもあがるし、
SQLも分離できてウマー。

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

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


34 名前:仕様書無しさん mailto:sage [2007/02/07(水) 20:27:07 ]
ハードコーディング無しで、DB使うアプリ書ける?そんなの無理でそ。
パラメータ受け取ってSQL文を生成するライブラリを書いてお茶を濁す
のが精一杯。
パフォーマンスの問題で、どうしてもDBMS固有の方言使っちゃうから、
DBMSの切り替えが発生した場合は、ライブラリの書き替えは避けられない。

35 名前:仕様書無しさん mailto:sage [2007/02/07(水) 20:29:54 ]
ストアドって長くすると、デバッグが大変のような。

36 名前:仕様書無しさん mailto:sage [2007/02/07(水) 20:31:17 ]
>>34
リソースとか別ファイルにしておくってことだろ? ハードコーディングしないって。

37 名前:仕様書無しさん mailto:sage [2007/02/07(水) 20:35:57 ]
>>34
そうそう。それでEJBは失敗した。

38 名前:仕様書無しさん mailto:sage [2007/02/07(水) 20:49:18 ]
>>36
そういうことなんだが、組みにくいわ、別ファイルの管理は面倒だわ、
ファイルIO発生しまくりだわ、欠点も多いのだよ。

>>35
かなりな。

39 名前:仕様書無しさん mailto:sage [2007/02/07(水) 20:53:59 ]
結局、SQLを変えたらコードも変えてコンパイルしなきゃなんない。
だったら、コードに直接埋め込まれていたほうが保守性がいい。

40 名前:仕様書無しさん [2007/02/07(水) 21:03:09 ]
>>39
同感。

1は、取ってきたデータどうするの? って素朴な疑問。
ひょっとして、配列? それとも可変な何かすごい仕組み?

わたしゃ、大抵、テーブルと対になるデータ用のクラス用意するよ。
この状況でSQLを外に出すとなると、条件を変えるくらいしかやりようがない。

条件をちろっと変えたければ明示的にオプションにするし。

まあ、外に出してもいいけど、どっちでも良いと思うよ。
そんなこと本質じゃないし。
文字列連結とかは禁止したいけど。フォーマットで当てはめするなら
ハードコーディングでも外から読み込んでもどっちも変わらない。

1は「データベース設計ツール使え」と言ってるのかもしれないけど、
だとしたらそもそもハードコーディングとか言い出さないだろうしなあ。




41 名前:仕様書無しさん [2007/02/07(水) 21:05:39 ]
iBatisつかってるやつはいないの?

42 名前:仕様書無しさん [2007/02/07(水) 21:07:15 ]
SQLの内容次第じゃないか?
コンパイルに時間がかかるSQLならPL/SQLにしとくべき。
いわゆる初回はやたら時間かかるけど二回目以降は早いSQL。

43 名前:40 [2007/02/07(水) 21:21:30 ]

おっと。

1は18に対して「そう」って言ってるの今気づいた。

そういうの使える環境ばかりじゃないんだがなあ。
恵まれてるのか、経験が少ないのか、勉強しているだけなのか・・・。

ストアドはデバッグし辛いので、パフォーマンスが要求されるところだけにしているオレ。


44 名前:69式フリーPG ◆hND3Lufios mailto:sage [2007/02/07(水) 21:31:10 ]
ストアドは1トランザクション中に複数のSQLを投げる必要がある場合なんか効果的だよね。

45 名前:仕様書無しさん mailto:sage [2007/02/07(水) 22:11:37 ]
ストアドは再現性の無いバグ(本人が気付けないだけ?)に悩まされそうで怖い。
ソースに埋め込んだ方が、トランザクションの一貫性の検証がしやすいし、
トレースも楽でいいよ。
再コンパイルを避けるためだけにSQL文を外に追いやるってのはどうなの?って感じ。

46 名前:仕様書無しさん mailto:sage [2007/02/07(水) 22:19:10 ]
Delete文を動的SQLで生成するルーチン作ったらwhere句の手前にいつも’\0’が入ってたwwwww
ちょwwwwCOMMIT発行すんのまwwwwwwwqwせdrftgyふじこ

47 名前:仕様書無しさん mailto:sage [2007/02/07(水) 22:23:07 ]
>>46
お前、出禁な。

48 名前:仕様書無しさん mailto:sage [2007/02/07(水) 22:28:02 ]
>>46
俺はUPDATEで同じことやらかしたけど、
消えたわけじゃないから罪は軽いよね(´・ω・`)

49 名前:仕様書無しさん mailto:sage [2007/02/07(水) 22:30:33 ]
>>48
出禁40日。>>46は無期限!

50 名前:仕様書無しさん mailto:sage [2007/02/07(水) 22:53:28 ]
データ取るためのSQLと受け取り側のアプリは密な結合だもんなあ。
分割しても結局どちらも修正入ることが殆どだし。




51 名前:仕様書無しさん mailto:sage [2007/02/07(水) 22:53:37 ]
SELECT文はXMLからロード&更新系は動的生成
これで完璧に動いてますが

52 名前:仕様書無しさん mailto:sage [2007/02/07(水) 22:58:12 ]
おじいちゃん、またそんなオナニーコード書いて。。

53 名前:仕様書無しさん mailto:sage [2007/02/07(水) 22:58:34 ]
>>40
そこでDataSetですよ

54 名前:仕様書無しさん mailto:sage [2007/02/07(水) 23:00:06 ]
またXMLかよ
いい加減にしる!

55 名前:仕様書無しさん mailto:sage [2007/02/07(水) 23:03:51 ]
>>40
> データ用のクラス用意

やるやるwww

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

56 名前:仕様書無しさん mailto:sage [2007/02/07(水) 23:04:41 ]
>>46-49
ワロタwwwww

57 名前:69式フリーPG ◆hND3Lufios mailto:sage [2007/02/07(水) 23:13:44 ]
ストアドのいいところはシステムを止めずにロジック変更が出来ることもあるな。

58 名前:仕様書無しさん mailto:sage [2007/02/07(水) 23:18:29 ]
>>57
気づかなかった

59 名前:仕様書無しさん mailto:sage [2007/02/07(水) 23:25:56 ]
だからといって、1行インサートするだけのオナニーストプロ書くのは止めてください。先輩。

60 名前:仕様書無しさん mailto:sage [2007/02/07(水) 23:32:36 ]
>>37
おまえ、Seasarの人間?EJB批判すんのもいいけど、考え無し過ぎる独自仕様もどうかと思うぜ。



61 名前:仕様書無しさん mailto:sage [2007/02/08(木) 00:10:38 ]
これからの時代ORMでしょ。SQLを生で使うのダサいよ。
Java厨ならHibernateを使え。キャッシュをうまく使えばSQLの直書きより性能いいゾ。

62 名前:仕様書無しさん mailto:sage [2007/02/08(木) 00:13:18 ]
常識的に考えて、このスレはJava屋限定にすべきだろ。
>>40とか、何しに入ってきてるんだよ。。

63 名前:仕様書無しさん [2007/02/08(木) 00:14:47 ]
Java厨ってさ、SQL書くのが下手な奴多くね?実行計画の見方も知らない見たいだし。

64 名前:仕様書無しさん mailto:sage [2007/02/08(木) 00:22:19 ]
DBといえばOracleオンリーな、柔軟性の無い奴もよくいるな。

65 名前:仕様書無しさん mailto:sage [2007/02/08(木) 00:35:46 ]
SQLの書き方次第でパフォーマンスに大きな違いがでる間は、ハードコーディング
せざるをえない。

66 名前:仕様書無しさん [2007/02/08(木) 00:42:42 ]
toruqueを使えばSQLなんて書かなくていいよ。あほじゃん?

67 名前:仕様書無しさん mailto:sage [2007/02/08(木) 00:43:10 ]
そんな微妙なチューニングが必要になる場合って、大抵テーブル設計が
糞だけどな。

68 名前:仕様書無しさん mailto:sage [2007/02/08(木) 02:14:30 ]
ORマッピングなんて作り手の自慰行為じゃねーか
EJBと同じ匂いがするぜ

69 名前:仕様書無しさん mailto:sage [2007/02/08(木) 07:10:53 ]
>>66
パフォーマンス無視だけどなw

70 名前:仕様書無しさん mailto:sage [2007/02/08(木) 07:54:17 ]
>>61
ハイバネはまだまだバギーすぎて、本腰入れて使うのは厳しくない?
DBとの相性もあるかもしれないけど。



71 名前:仕様書無しさん [2007/02/08(木) 08:31:29 ]
この手の話は
酒のつまみにはなるけど
飯の種にはならんな

72 名前:仕様書無しさん mailto:sage [2007/02/08(木) 08:32:04 ]
EJBで性能でなくて生SQLに全部書き換えしたプロジェクト知ってる。



73 名前:仕様書無しさん mailto:sage [2007/02/08(木) 08:41:05 ]
そいへばテーブルのvarchar項目にSQL断片を入れておいて
SELECTで組み上げてからそれをまた実行する変な仕事を
こないだしたな。そのクエリ結果の中にまたSQL文が入ってる(w)

74 名前:仕様書無しさん mailto:sage [2007/02/08(木) 08:46:19 ]
>>73
wwwww

75 名前:仕様書無しさん mailto:sage [2007/02/08(木) 09:36:08 ]
>>70
たぶんOracleのJDBCドライバが腐ってるせいだと思う。
Hibernateは悪くない。

76 名前:仕様書無しさん mailto:sage [2007/02/08(木) 09:38:36 ]
ADO.NETが一番よくできてる

77 名前:仕様書無しさん mailto:sage [2007/02/08(木) 10:18:44 ]
ADO.NET使える環境なら、それ使うにあたって議論は無いはず。
C/C++環境ならORM自作しなきゃいけないが、そんなことは誰もやらないはず。

78 名前:仕様書無しさん [2007/02/08(木) 11:44:37 ]
PL/SQLを書く香具師の方が死んで欲しい。


79 名前:仕様書無しさん [2007/02/08(木) 12:13:54 ]
一番氏んで欲しいのは、AccessがないとDB触れない奴

80 名前:仕様書無しさん [2007/02/08(木) 12:19:43 ]
UNIXでPro*Cとかだと、ストアドの方が文法的にも簡単で楽チン。



81 名前:仕様書無しさん [2007/02/08(木) 12:21:11 ]
Pro*Cのソースは見れたもんじゃない

82 名前:仕様書無しさん [2007/02/08(木) 12:31:21 ]
ORマッピングってやったことないんだけど、どーなのよ。
使いにくいんか?

83 名前:仕様書無しさん mailto:sage [2007/02/08(木) 13:29:21 ]
>>82
かなり便利だが性能は出しにくいし たまに融通が利かない

84 名前:仕様書無しさん [2007/02/08(木) 14:11:36 ]
>>83

iBatisだったら全然そんなことないぜ。
hibernateは理念にこだわり過ぎて美しいけど遅い。
SQL文レベルのチューニングだったら全然やりやすいし。

85 名前:仕様書無しさん [2007/02/08(木) 14:39:46 ]
ORマッピングツール使えば
DBの表にあわせてクラスを生成しなくていいの?

86 名前:仕様書無しさん mailto:sage [2007/02/08(木) 15:21:25 ]
ORマッピングの最高峰はWebObjects

87 名前:仕様書無しさん [2007/02/08(木) 15:25:52 ]
>>86
アップル信者死ね。



88 名前:仕様書無しさん mailto:sage [2007/02/08(木) 15:34:34 ]
>>87
アホ
俺は生粋のMS信者

89 名前:仕様書無しさん [2007/02/08(木) 17:44:23 ]
ハードコーディングってなに?

90 名前:仕様書無しさん mailto:sage [2007/02/08(木) 19:52:29 ]
>>89
表面を金属とかで堅く覆うことだろ.




91 名前:仕様書無しさん mailto:sage [2007/02/08(木) 19:54:58 ]
>>89
一生懸命プログラミングすること

92 名前:仕様書無しさん mailto:sage [2007/02/08(木) 21:15:37 ]
ととっとしネ

93 名前:仕様書無しさん mailto:sage [2007/02/08(木) 21:48:10 ]
>>86,88
EOF,っても通じないしなぁ。
Cayenneとかはどーなんでしょ

94 名前:仕様書無しさん mailto:sage [2007/02/08(木) 22:37:25 ]
>73
メタメタですね

95 名前:仕様書無しさん [2007/02/09(金) 00:48:56 ]
>>93
>Cayenne

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


96 名前:仕様書無しさん mailto:sage [2007/02/09(金) 02:36:48 ]
>>79
補助ツールとしては便利だけどね。
アレなしだと触れない奴はちょっとだな。

>>80-81
禿同

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

97 名前:仕様書無しさん [2007/02/09(金) 08:47:24 ]
ORマッピングフレームワークを使わない理由

・興味があって調べたらxmlを書きまくらないとダメなのが分かる
・どういう設定をすればいいのかぱっと分からない
・それで便利になるの?という疑心暗鬼
・スピードは? 融通性は?
・うーん。。。
・(゚听)イラネ

98 名前:仕様書無しさん mailto:sage [2007/02/09(金) 13:54:43 ]
>>97
マジレスすると

オレの場合iBatisと自作のO/Rマッピングツールを使ったことがあるけど

>・興味があって調べたらxmlを書きまくらないとダメなのが分かる
velocityとかのテンプレートエンジン使って自動生成しる。
複雑なSelect文なんかはO/Rマッピングツールは苦手だから
そこらへんはビュー作って対応すると幸せ。

>・どういう設定をすればいいのかぱっと分からない
慣れろ

>・それで便利になるの?という疑心暗鬼
例えばDBのカラム名がクラスのメンバ名になるから配列の3番目がUserNameとか面倒な事を考えなくてもいい。
あとDBのカラムが減ったり名称が変わったときにコンパイルが通らなくなるから
実行時のエラーが減ってバグが減少する。

>・スピードは? 融通性は?
単純な更新系ではそんなに変わらない気がする。
うちではバッチ系とかスピード求める部分にはストアドを採用した。








99 名前:仕様書無しさん [2007/02/09(金) 14:52:55 ]
>あとDBのカラムが減ったり名称が変わったときにコンパイルが通らなくなるから
>実行時のエラーが減ってバグが減少する。

え?
じゃあDBの構成を変えたら、ロジックに関係なくてもソース直さなきゃいかんの?
例えば客先要望で「UPDDATEというのをUPDATE_DATEに変えてもらえますか?」とか言われたら
更新日付なんてINSERT文の中にSYSDATE入れてただけでも直さなきゃいかんの?

100 名前:仕様書無しさん mailto:sage [2007/02/09(金) 15:13:28 ]
クライアント数が多いシステムだときついね。



101 名前:仕様書無しさん [2007/02/09(金) 15:15:02 ]
>>99
INSERT文が

 INSERT INTO HOGE VALUES(...

だったらいいけど

 INSERT INTO HOGE(UPDDATE) VALUES(...

ならダメじゃないか?

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 名前:仕様書無しさん mailto:sage [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 名前:仕様書無しさん mailto:sage [2007/02/09(金) 20:03:31 ]
O/Rマッピングが一括更新に向いてないのは作者達も認めているところで
そこはむしろ、SQLによる更新やストアドプロシジャなどとの併用を勧めている。
全てがオブジェクトで処理できないから使えないという考えは柔軟性に欠ける
のでは? 保守性や開発効率を考えて適材適所で使い分ければいいと思う。

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

110 名前:仕様書無しさん mailto:sage [2007/02/09(金) 20:31:35 ]
文字列連結すんなって.....
じゃあどうやってSQL文を作れば良いんだよ。



111 名前:仕様書無しさん mailto:sage [2007/02/09(金) 20:38:02 ]
行間を読んでくれ・・・

112 名前:仕様書無しさん mailto:sage [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マッパーなんて
ありえないだろw

115 名前:仕様書無しさん mailto:sage [2007/02/09(金) 22:18:13 ]
とりあえずJava系から出てきたものって全部糞

116 名前:仕様書無しさん mailto:sage [2007/02/09(金) 22:26:57 ]
RDB(≒SQL)とオブジェクト指向の相性の悪さはよく言われている。

117 名前:仕様書無しさん mailto:sage [2007/02/09(金) 22:28:07 ]
DBのメタ情報読んでXMLとクラスを自動生成するツールあるけど。

118 名前:仕様書無しさん mailto:sage [2007/02/09(金) 22:30:09 ]
でも普通はXMLを保守して、クラスの生成とDBの更新ってパターンだな。

119 名前:仕様書無しさん mailto:sage [2007/02/09(金) 22:40:50 ]
糞、糞、言うだけで、それがどうして糞なのかの理由を書き込まない奴は脳みそが少し足りないんじゃないかと真剣に思う。

120 名前:仕様書無しさん mailto:sage [2007/02/09(金) 22:46:00 ]
>>117-118
なんかプログラムのためのプログラムやっている気分だな。




121 名前:仕様書無しさん [2007/02/09(金) 22:50:08 ]
ハイバネイト使わせたら
見事削除対象のレコード数分だけselectとdeleteを実行する実装されてたよ…(´・ω・`)

もう尻拭いばっか

122 名前:仕様書無しさん mailto:sage [2007/02/09(金) 22:58:24 ]
プログラミングが楽しくない

それだけで糞

123 名前:仕様書無しさん mailto:sage [2007/02/09(金) 23:00:21 ]
Pro*Cならmakefileにプリコンパイルを書いてリンクするライブラリを追加するだけ。
OCIならプリコンパイルもいらない。

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

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

124 名前:仕様書無しさん mailto:sage [2007/02/09(金) 23:40:13 ]
時々不思議に思うんだけど,ORマッピングツールを導入するメリットで詠われる,
DBを変更したら〜って下り.
DBってそんなに変えるもんなの?
設定ファイルを書き換えるような気楽さで変わるようなもんじゃないと思うんだけど.
最近はOracleやSQLServerも開発用に無償で使えるバージョンも整ってることだし.


125 名前:仕様書無しさん mailto:sage [2007/02/10(土) 00:02:39 ]
>>118
それって、運用段階でどれだけ地獄になるかわかってる?特にDBの更新

126 名前:仕様書無しさん mailto:sage [2007/02/10(土) 00:05:27 ]
んでデグレるんだな。
Pro*Cだってmakefileにプリコンパイルを書いてないバカのおかげで時々あるけどさ。

127 名前:仕様書無しさん [2007/02/10(土) 00:09:13 ]
>見事削除対象のレコード数分だけselectとdeleteを実行する実装されてたよ…

カコイイ^^

128 名前:仕様書無しさん mailto:sage [2007/02/10(土) 00:15:34 ]
>>125
運用段階でDBを変更する事態になったら、どんなやり方しようが影響はあると思うが・・・

129 名前:仕様書無しさん [2007/02/10(土) 00:22:34 ]
うちの会社のPL/SQLプロシージャは
最初にテーブルをことごとくDROPして
CREATEしなおしてから処理しだす

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


130 名前:仕様書無しさん mailto:sage [2007/02/10(土) 03:30:59 ]
ビルド時にSQLとコードを結合するライブラリとかはどうなの



131 名前:仕様書無しさん [2007/02/10(土) 09:20:16 ]
フィールド変更っていうシナリオがそんなに発生しないんだけど、
そういうのが発生したとして
ハードコーディングされたSQL文のフィールド名を探して置換してコンパイルし直すのと、
XMLファイルをいじってorツールでxmlとクラスを自動生成してコンパイルしなおすのと
そんなに変わらない気がする

132 名前:仕様書無しさん mailto:sage [2007/02/10(土) 10:03:19 ]
>>131
例えば、先週実際にあったこういう仕様変更とか、

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



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

にする。


133 名前:仕様書無しさん mailto:sage [2007/02/10(土) 10:24:08 ]
>>132

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

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

DaoにSQL直記入の場合

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

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

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

134 名前:132 mailto:sage [2007/02/10(土) 11:08:55 ]
どうやっても食えない例として挙げてみた。

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

135 名前:仕様書無しさん [2007/02/10(土) 11:17:15 ]
ORマッパだけで済むなら
ORマッパ周りだけの修正で済むけど
現実にはSQL直記入しているんだから
変更部分はORマッパ周りとSQL直記入部分

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

136 名前:仕様書無しさん mailto:sage [2007/02/10(土) 11:34:23 ]
フィールド変更はメンテの想定外なんだよ

137 名前:仕様書無しさん [2007/02/10(土) 12:10:34 ]
ソースとXMLの両方修正するのうぜ。
どっちみちソースは修正しないといけないだろ

138 名前:仕様書無しさん mailto:sage [2007/02/10(土) 12:17:32 ]
XML自体の書きやすさというか保守性も疑問だ?
同じ内容を全部JavaなりC++なりで書いた方が
わかりやすくねぇか?


139 名前:仕様書無しさん mailto:sage [2007/02/10(土) 13:03:11 ]
XMLの保守に疲れたあなたに、一服の清涼剤を・・・
つ Ruby on Rails

140 名前:仕様書無しさん [2007/02/10(土) 13:13:13 ]
それはないww



141 名前:仕様書無しさん mailto:sage [2007/02/10(土) 13:28:22 ]
新規のDB設計なのに、未だに自然キー(特に複合キー)を主キーにしてる仕様書を
よく見るんだけど・・・。頭の固いコボラーかな。
その設計書渡された人の苦労も想像できず、これで一仕事終えた気になってんだろうな。


142 名前:仕様書無しさん mailto:sage [2007/02/10(土) 13:31:32 ]
そろそろ割り切りたいと思っているあなたに、
つ Ruby on Rails

143 名前:仕様書無しさん [2007/02/10(土) 13:33:31 ]
人工キーを主キーとすべきだよね

144 名前:仕様書無しさん mailto:sage [2007/02/10(土) 13:41:24 ]
なんでもかんでも人工キーってのもあれだけど、なんでもかんでも自然キー
ってのは頭悪すぎる。SQLが無駄に長くなりやすいし、ORMには当然向かない。

145 名前:仕様書無しさん mailto:sage [2007/02/10(土) 14:08:07 ]
>>141
むしろ、Coboler の方こそ「採番癖」が強いと思うのだが・・・
自然キーを上手く拾い出せるのならば、それに越したことはない。
(この「ならば」の見極めが難しいのだが)

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


146 名前:仕様書無しさん mailto:sage [2007/02/10(土) 14:21:13 ]
ORMはサービス層を保護するためにやるのが目的
メンテがどうとかいってる奴は頭わるすぎ。

147 名前:仕様書無しさん mailto:sage [2007/02/10(土) 14:22:04 ]
>>145
いつの話してる。そんな時代はとっくに過ぎ去った。

148 名前:仕様書無しさん mailto:sage [2007/02/10(土) 14:24:23 ]
自然キーは読んで字のごとく自然と目の前に提示されている。それを見出し、
キーに設定する能力は別にいばるほどのものではない。
>>145はORマッパーを使ったことないだろ?

149 名前:仕様書無しさん mailto:sage [2007/02/10(土) 14:29:42 ]
テーブルには必ずGUIDカラムを作るのが
一般的だっつーの

150 名前:仕様書無しさん mailto:sage [2007/02/10(土) 15:13:56 ]
それをいうならサロゲートキーだろ
GUIDはその実現方法のひとつ



151 名前:仕様書無しさん [2007/02/10(土) 15:19:19 ]
>>121
HQLでなんとかならんかったのか?

152 名前:仕様書無しさん mailto:sage [2007/02/10(土) 15:54:24 ]
データの寿命は業務より長く、いま一意な自然キーは「たまたまそうなってる」だけだ罠

153 名前:仕様書無しさん mailto:sage [2007/02/10(土) 16:03:00 ]
複合キーの弊害はいろいろあるが、俺が特に面倒臭く思うのは、データリストの
特定のデータを特定したり、htmlのselectのvalue値をどうするかで余計な頭を
つかわされる時だな。

154 名前:仕様書無しさん [2007/02/10(土) 16:27:50 ]
>151
当然HQLを使うべき処理なんだがそれを使っていなかったんだよ…

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

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

155 名前:仕様書無しさん mailto:sage [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 名前:仕様書無しさん mailto:sage [2007/02/10(土) 17:34:57 ]
つかハイバネなんか使わせるほうがアホだろ

159 名前:仕様書無しさん mailto:sage [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 名前:仕様書無しさん mailto:sage [2007/02/10(土) 18:58:46 ]
俺この前マスターメンテの変更画面で主キーが変更可能な仕様書みたよ。
ま、外部キーとして使われてないフィールドだったからよかったけどおっかねぇよ。

162 名前:仕様書無しさん [2007/02/10(土) 19:52:36 ]
>>1

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

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


163 名前:仕様書無しさん mailto:sage [2007/02/10(土) 19:54:56 ]
XMLは、糞

164 名前:仕様書無しさん mailto:sage [2007/02/10(土) 22:33:48 ]
素朴な疑問
ここを読んでるとXML嫌いなやつは多そうなんだが
そういうやつはそれなりに構造を持ったデータを何で記述してるんだ?
構造を持ったデータを記述する統一記法としては
まずまずなんじゃないかと思っているんだが

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

165 名前:仕様書無しさん mailto:sage [2007/02/10(土) 22:35:53 ]
つ YAML

166 名前:仕様書無しさん mailto:sage [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 名前:仕様書無しさん mailto:sage [2007/02/10(土) 22:42:44 ]
>>164

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



168 名前:仕様書無しさん mailto:sage [2007/02/10(土) 22:50:12 ]
>>167 排他もトランザクションも自前で実装すんの?

169 名前:164 mailto:sage [2007/02/10(土) 22:50:40 ]
>>167
言語も環境も閉じてる時はいいけどさ
たとえばWeb Service系だと外とやりとりしないといけないよな
そう言うときはどうする?

170 名前:仕様書無しさん mailto:sage [2007/02/10(土) 22:53:52 ]
データの受け渡しのXMLはいいよ思うよ。



171 名前:仕様書無しさん mailto:sage [2007/02/10(土) 23:00:47 ]
別にXML自体を叩いてるわけじゃないと思うんだが…

172 名前:仕様書無しさん mailto:sage [2007/02/10(土) 23:04:34 ]
>>163

173 名前:仕様書無しさん mailto:sage [2007/02/10(土) 23:04:57 ]
>>168

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


>>169

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

174 名前:仕様書無しさん mailto:sage [2007/02/10(土) 23:05:46 ]
>>168
?言ってる意味がよく分からんな。

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

175 名前:仕様書無しさん mailto:sage [2007/02/10(土) 23:18:45 ]
詳細設計書に決めたれた形式に沿って書くのは大変だったな
vbaのマクロとかで

176 名前:仕様書無しさん mailto:sage [2007/02/10(土) 23:23:39 ]
俺もYAMLに一票

177 名前:仕様書無しさん mailto:sage [2007/02/10(土) 23:28:44 ]
今見てみたけどYAML良いなぁ
これなら、許せるかも

178 名前:仕様書無しさん [2007/02/10(土) 23:59:40 ]
やーむるっていうの?

179 名前:仕様書無しさん mailto:sage [2007/02/11(日) 00:44:52 ]
昔、西城秀樹が歌ってたなぁ

180 名前:仕様書無しさん mailto:sage [2007/02/11(日) 00:53:02 ]
xml 自体はいいです。
既にパーサーあって、自前でつくる必要も、
わけのわからないものを使う必要ない。




181 名前:仕様書無しさん mailto:sage [2007/02/11(日) 00:58:40 ]
>>180
コボラと同じ思考パターンだな

182 名前:168 mailto:sage [2007/02/11(日) 01:03:28 ]
>>173-174
いや俺はてっきり(XML使わない=ORM使わない)のつもりで
いたもんだから・・・
余計なお世話かもしらんけどORM使うと設定でできちゃうもんで。

183 名前:仕様書無しさん mailto:sage [2007/02/11(日) 01:15:55 ]
XML自体は可搬性が高くて優れてはいるが
Parserはどれもこれももうちょっとどうにかならんかな。
XMLの記述がどうとでもなることが災いして、
シンプルなものにはなりづらいのはわかるが、非常に手間だ。


184 名前:仕様書無しさん mailto:sage [2007/02/11(日) 01:46:15 ]
排他はともかく、トランザクションの規約による自動化はORMじゃなくてAOPの範疇じゃね?
ハイバネとかもSpringと組み合わせることによって実現するしさ。

185 名前:仕様書無しさん mailto:sage [2007/02/11(日) 02:16:26 ]
Webサーバのフィルタでもできるべし。

186 名前:仕様書無しさん mailto:sage [2007/02/11(日) 02:25:22 ]
今の世の中いつの間にか猫も尺由美子もXMLだな。

187 名前:仕様書無しさん [2007/02/11(日) 02:26:35 ]
>>185
そのパターンはやるなってのが一般的な見解になりつつない?

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

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

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

188 名前:仕様書無しさん mailto:sage [2007/02/11(日) 02:52:19 ]
でも、Webアプリの場合、HTTPリクエスト≒DBトランザクション じゃね?
リクエストを受けてトラン開始、レスポンス返す前にトラン終了ってパタン。
ORMのセッションをWebサーバのセッションに格納してってパタンもよくサン
プルで見るんだけど。一般的な見解とやらはよくわからんが。

189 名前:仕様書無しさん mailto:sage [2007/02/11(日) 03:28:28 ]
トランザクションがもっと狭くて済むならそっちの方が良いだろ。
まして、データ自体やモデルからは、トランザクションの範囲は決められないだろうに、
>>168のレスが何を意図するのかさっぱりわからんよ。


190 名前:仕様書無しさん mailto:sage [2007/02/11(日) 06:08:20 ]
XMLはぱっと見いい感じに思えるけど
実はいろいろと問題を抱えてる
XMLのスレに行くといい



191 名前:仕様書無しさん [2007/02/11(日) 06:21:13 ]
>>190
つーか、ORマッピングの設定ファイルに使って
SQL文書いておくってレベルではXML自体の問題は発生しないだろ。
DTDとかのおかげで設定エラーも文法レベルのは簡単に見つかるし。


192 名前:仕様書無しさん mailto:sage [2007/02/11(日) 07:38:23 ]
ORマッピングの場合、ソースとXMLとに、
テーブル構造を書くので、非常に無駄。
後、SQLとソースの関係が煩雑になりがち

193 名前:仕様書無しさん mailto:sage [2007/02/11(日) 09:44:01 ]
>>192
ORM使う以上、テーブル構造を意識したソース書いた時点で負け

194 名前:仕様書無しさん mailto:sage [2007/02/11(日) 10:07:18 ]
>>193

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


195 名前:仕様書無しさん mailto:sage [2007/02/11(日) 10:13:15 ]
下手な釣りすんなボケ

196 名前:java.lang.Map様 mailto:sage [2007/02/11(日) 12:09:05 ]
どうやらオレの出番が来たようだな!

197 名前:仕様書無しさん mailto:sage [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 名前:仕様書無しさん mailto:sage [2007/02/12(月) 01:53:22 ]
それはない。w

202 名前:仕様書無しさん mailto:sage [2007/02/12(月) 20:18:13 ]
>>193
どういう意味でテーブル構造という言葉を使ったのか詳しく
カラム名云々言ってる奴は無視して

203 名前:仕様書無しさん mailto:sage [2007/02/12(月) 20:29:11 ]
>>202
DAOより後段は、単なる「オブジェクトの入れ物」と考える。
入れ物の形を気にして、入れるもの(=オブジェクトモデル)の
形が制約されてしまうのは本末転倒。

204 名前:葉猫 ◆Jz.SaKuRaM mailto:sage [2007/02/12(月) 20:31:19 ]
ここはあえてosqlでバッチ処理。

205 名前:仕様書無しさん mailto:sage [2007/02/13(火) 01:04:41 ]
>>204がいいことを言った!!!

206 名前:仕様書無しさん mailto:sage [2007/02/13(火) 04:39:50 ]
>>203

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


207 名前:仕様書無しさん [2007/02/13(火) 09:20:52 ]
結局O/Rマッピングは、データベースの代わりに使う物じゃなくて、オブジェクト永続化のためにある。
問題はその使い道がまったくないと言う事だ。


208 名前:仕様書無しさん mailto:sage [2007/02/13(火) 11:33:22 ]
仕事のための仕事

209 名前:仕様書無しさん mailto:sage [2007/02/13(火) 11:52:40 ]
O/Rマッピングは便利そうなんだが
3テーブル以上の表結合とか簡単なんだろうか

210 名前:仕様書無しさん [2007/02/13(火) 12:59:29 ]
結合も関数も使えないって。一括更新も一括削除も出来ないんだから。
キャラクターデータのセーブにぐらいしか使えないよ。




211 名前:仕様書無しさん mailto:sage [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 名前:仕様書無しさん mailto:sage [2007/02/13(火) 21:23:02 ]
単純に解析や翻訳のオーバーヘッド減らして性能上げたいだけだろ?
今のサーバ性能じゃ仕方ない気がするが

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

215 名前:仕様書無しさん mailto:sage [2007/02/13(火) 21:39:42 ]
>>212
つ one-to-one, many-to-one, many-to-many

216 名前:仕様書無しさん [2007/02/13(火) 21:44:31 ]
>>215

おいおい、、、

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

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


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

217 名前:仕様書無しさん mailto:sage [2007/02/13(火) 21:59:34 ]
爺が多いなー

218 名前:仕様書無しさん mailto:sage [2007/02/13(火) 22:00:14 ]
???

219 名前:仕様書無しさん mailto:sage [2007/02/13(火) 22:08:08 ]
なあ、テクノロジはどんどん進化しているわけだよ。爺さんたちよ。
自分がやっとこさ身につけた技術が過去のものになる悲しさは理解できるけどさ、
この業界はものすごいスピードで進化してるわけだよ。頑張ってついていかなくちゃ、
アルツハイマーになっちゃうよw

220 名前:仕様書無しさん mailto:sage [2007/02/13(火) 22:13:06 ]
個人的にはテーブルという概念がもうね・・・



221 名前:仕様書無しさん mailto:sage [2007/02/13(火) 22:38:19 ]
もうね・・・そうね・・・なんちゅうーか・・・あれだよ・・・あれ・・・それ・・・アレ?

222 名前:仕様書無しさん mailto:sage [2007/02/13(火) 23:06:14 ]
なんつーか、最近技術系のブログを見てて思うのは
若手の単なる思い付きみたいなアイデアがやたらもてはやされて、
「こいつら本当に基礎の技術あってその上でする話はほとんどしてねーよな」
って事だな。

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

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

223 名前:仕様書無しさん [2007/02/13(火) 23:32:57 ]
爺晒しage

224 名前:仕様書無しさん mailto:sage [2007/02/13(火) 23:55:10 ]
もし、この世に「単なる思い付きでないアイデア」
というものがあるならば、是非教えてもらいたい。


225 名前:仕様書無しさん mailto:sage [2007/02/14(水) 00:05:23 ]
アインシュタインの相対性理論とか、そうだろ。
単なる最初は単なる思い付きなんだけど、
そこから磨きこんであそこまで美しい理論になった。

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

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

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

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

226 名前:仕様書無しさん mailto:sage [2007/02/14(水) 00:10:44 ]
>COMやXMLやSOA、Web2.0
どうだめなのか詳らかにしろや。

227 名前:仕様書無しさん mailto:sage [2007/02/14(水) 00:13:35 ]
あと二三年で消える言葉だから黙って見てな。

228 名前:仕様書無しさん mailto:sage [2007/02/14(水) 00:15:22 ]
>>225
・・・お前、10代だろ?(w


229 名前:仕様書無しさん mailto:sage [2007/02/14(水) 00:16:34 ]
猫も尺由美子

230 名前:仕様書無しさん mailto:sage [2007/02/14(水) 00:21:45 ]
XMLも2・3年で無くなるのか。そしたらYAMLに置き換わるかな。



231 名前:仕様書無しさん mailto:sage [2007/02/14(水) 00:23:46 ]
>>230
SXMLに置き換わる。

232 名前:仕様書無しさん mailto:sage [2007/02/14(水) 00:24:01 ]
>>230
S式に置き換わります。


233 名前:仕様書無しさん mailto:sage [2007/02/14(水) 00:28:12 ]
>>209
まずViewを作ろうぜ・・・
亀スマソ

234 名前:仕様書無しさん mailto:sage [2007/02/14(水) 00:44:27 ]
>>233

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

235 名前:仕様書無しさん mailto:sage [2007/02/14(水) 00:54:32 ]
VIEWが遅くて、通常のSELECT文の方が速いというのはどういうアレなん?

236 名前:仕様書無しさん mailto:sage [2007/02/14(水) 01:05:08 ]
>>234
どこで、遅いかにもよると思うが。

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

237 名前:仕様書無しさん mailto:sage [2007/02/14(水) 01:05:29 ]
>>235

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

238 名前:>>234 mailto:sage [2007/02/14(水) 01:15:43 ]
>>236

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

239 名前:仕様書無しさん mailto:sage [2007/02/14(水) 01:16:04 ]
スマートにしようと頑張れば頑張るほど無駄に複雑になっていくのが男の浪漫。

240 名前:仕様書無しさん mailto:sage [2007/02/14(水) 01:23:35 ]
速度狙ってView使うというケースは、
どっちにしろあまりないような気がする。

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



241 名前:仕様書無しさん mailto:sage [2007/02/14(水) 01:43:03 ]
>>228
俺もそう思う。Linuxだかなんだかの「はしか」にかかった時期の。

242 名前:仕様書無しさん mailto:sage [2007/02/14(水) 01:49:39 ]
インデックスとかの前に実行計画チェックしろと

243 名前:仕様書無しさん [2007/02/14(水) 06:20:14 ]
マテビュー使ってスナップショット取れば?

244 名前:仕様書無しさん mailto:sage [2007/02/14(水) 09:41:50 ]
AjaxはNetscapeがJavaアプレットとJavaScript、LiveConnectでやろうとしてたことそのものだと思うが、
アプレットは時代の流れに消えてXMLHttpRequestみたいなブラウザ組み込みのオブジェクトが使われてるだけで

245 名前:仕様書無しさん mailto:sage [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 mailto:sage [2007/02/14(水) 20:36:01 ]
福岡の那の津埠頭にはSOLってラブホがありますが、あれがSQLに見えたときは
休んだほうがいいとオモタ。

249 名前:仕様書無しさん mailto:sage [2007/02/14(水) 21:37:17 ]
タケノコのように生えてる銀色の塔を思い出した。


250 名前:仕様書無しさん mailto:sage [2007/02/14(水) 23:00:32 ]
どーでもいいが、
strSql = strSql + "〜〜〜"
strSql = strSql + "〜〜〜"
strSql = strSql + "〜〜〜"
以下略 な書き方を解消する方法を開発してくれ。
だるいから。



251 名前:仕様書無しさん mailto:sage [2007/02/14(水) 23:04:56 ]
>>250
HibernateTemplate ht = new HibernateTemplate(sessionFactory);
ht.get(Hoge.class, id);

252 名前:仕様書無しさん mailto:sage [2007/02/14(水) 23:07:48 ]
>>251
ぐぐったが、、、
情報すくねー(泣
けどさんく〜

253 名前:仕様書無しさん mailto:sage [2007/02/14(水) 23:20:03 ]
>>250
string sql = String.Format("SELECT {0} FROM {1} WHERE {2}"...);

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

254 名前:仕様書無しさん mailto:sage [2007/02/15(木) 00:18:33 ]
>>253
さすがにそう書くくらいならPreparedStatementニスル。


255 名前:仕様書無しさん [2007/02/15(木) 00:33:24 ]
>>254
そう書かなくてもしろよ!
SQLインジェクションどうすんだよ!

256 名前:仕様書無しさん mailto:sage [2007/02/15(木) 00:48:17 ]
>>253
俺ガイルwww

257 名前:仕様書無しさん [2007/02/15(木) 01:18:58 ]
>>246

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 名前:仕様書無しさん mailto:sage [2007/02/15(木) 21:30:13 ]
>>259

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



261 名前:仕様書無しさん mailto:sage [2007/02/15(木) 21:43:12 ]
冗長大好き<java房

262 名前:仕様書無しさん mailto:sage [2007/02/15(木) 23:01:35 ]
>>261
Java周辺の話って庭の草取りに燃料気化爆弾使うようなのばかりだな。


263 名前:仕様書無しさん mailto:sage [2007/02/15(木) 23:06:48 ]
一応Javaの方でも反省はあるみたいだけどね。POJOとか。
あとC++みたいに言語自体がでかいのと比べると
ドングリの背比べのような気もする。
Rubyとか流行らないかなぁ

264 名前:仕様書無しさん [2007/02/16(金) 00:51:24 ]
C++って言語でかいか?

265 名前:仕様書無しさん mailto:sage [2007/02/16(金) 01:13:37 ]
言語仕様が複雑って意味ででかいと言ってるならでかいだろう

266 名前:仕様書無しさん mailto:sage [2007/02/16(金) 22:20:05 ]
すぐに言語比較に持っていくんだから・・・

267 名前:仕様書無しさん mailto:sage [2007/02/17(土) 02:15:14 ]
SQLとSQLとSQLの比較よろ。

268 名前:仕様書無しさん mailto:sage [2007/02/17(土) 18:32:09 ]
ADO.NET使いはこのスレにいるかい

269 名前:仕様書無しさん mailto:sage [2007/02/17(土) 20:02:37 ]
おジャバ様のすくつにそんな人いません><

270 名前:仕様書無しさん mailto:sage [2007/02/17(土) 20:17:59 ]
>>268


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



271 名前:仕様書無しさん mailto:sage [2007/02/17(土) 21:58:39 ]
>>270
おまいさんはどういうふうに書いて(処理して)るんだい?

272 名前:仕様書無しさん mailto:sage [2007/02/17(土) 23:29:32 ]
>>271
確かに知りたいよなぁ...。素のCでSQLのオンコーディングする時、
うちは
strcpy(acSql,
" SELECT"
 " col_a"
 ",col_b"
" FROM"
 " sample_table"
" WHERE"
・・・
);
てな感じで埋め込んでるが、もっとマシな手段ないかなぁ。


273 名前:仕様書無しさん mailto:sage [2007/02/17(土) 23:35:41 ]
>>272
どんな環境なのか知らんけど、これだとSQLインジェクションし放題じゃない?

274 名前:仕様書無しさん mailto:sage [2007/02/17(土) 23:39:07 ]
>>272
少なくともsprintf的な書き方をした方が・・・。
そうすれば、sql文を別ファイルなり、データベースなり、リソースなり、どこにでも置ける。
strcpyとかstrcatでくっつける、ってのはキツイと思うよ。

275 名前:仕様書無しさん [2007/02/18(日) 00:07:09 ]
ストアドオンリーってのが一番いいのかな

276 名前:仕様書無しさん mailto:sage [2007/02/18(日) 00:12:01 ]
動的に条件が変わる場合のストアドはどう実装すれば……
条件毎にストアドつくる?


277 名前:仕様書無しさん mailto:sage [2007/02/18(日) 00:14:41 ]
>>275
以前はそう思ってたが、今はDBに実装載せるのはどうかと思う

278 名前:仕様書無しさん mailto:sage [2007/02/18(日) 00:16:44 ]
そういえばVBのプログラムで
1.Accessのmdbファイルを一個用意
2.mdbファイルにリンクテーブル作りまくり
3.クエリも作りまくり(パラメータクエリ・更新クエリetc)
4.VBからmdbのクエリ呼ぶ
っていうのを見たことがあったなあ。
クエリでOracleとSQLServerとMySQLを連結したりとか。

279 名前:仕様書無しさん mailto:sage [2007/02/18(日) 00:18:45 ]
>>276
WHERE句とかの話なら、パラメータや引数であかんの?

280 名前:仕様書無しさん mailto:sage [2007/02/18(日) 00:19:47 ]
>>278
一時的なデータ編集用ならありかもしれないけど、
恒常的に使うシステムとしては脆弱すぎ。



281 名前:仕様書無しさん mailto:sage [2007/02/18(日) 00:20:46 ]
>>277
その心は?
いろんな事情があるかもしれないけど、参考にお聞かせ願いたい。

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

282 名前:仕様書無しさん mailto:sage [2007/02/18(日) 00:23:10 ]
SQLの書かれてるファイルなりリソースと
それを実行するソースが分かれてるのも
良くないと思う。

283 名前:仕様書無しさん mailto:sage [2007/02/18(日) 00:25:53 ]
>>280
激しく同意なんだけど病院で使われているという恐ろしい事実

284 名前:仕様書無しさん mailto:sage [2007/02/18(日) 00:29:58 ]
>>282
そうか?
個人的には関数の本体コードとそれを呼び出すコードが別ファイルにあるようなモンだと思うんだけど('A`)

285 名前:284 mailto:sage [2007/02/18(日) 00:34:18 ]
そうでもないような気がして来た

286 名前:仕様書無しさん [2007/02/18(日) 10:11:25 ]
動的にwhere句に現れるフィールドを変更したいって事?

287 名前:仕様書無しさん mailto:sage [2007/02/18(日) 10:34:02 ]
ストアドはデバッグしづらいから
速度がでないなどの問題がない限り使わないで欲しい。

288 名前:仕様書無しさん mailto:sage [2007/02/18(日) 10:51:10 ]
>>287

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

289 名前:仕様書無しさん [2007/02/18(日) 11:16:56 ]
パラメータ使うに決まってるだろうがハゲ学生が

290 名前:仕様書無しさん mailto:sage [2007/02/18(日) 12:16:47 ]
一つのシステムで完結するなら良いけど,
Webシステムでオンラインユーザからの更新と,
クラサバのVB製システムから更新が同時に入ったりする
古くて大規模なシステムだと,
結局ロジック部分をストアドプロシージャでまとめるしか無かったりする.

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



291 名前:仕様書無しさん mailto:sage [2007/02/18(日) 17:58:56 ]
あー
クライアントの種類が1つじゃない場合には有利か

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

292 名前:仕様書無しさん mailto:sage [2007/02/18(日) 21:30:02 ]
>>271
SQLはXMLの中に書いて自動生成させてるだよ。(環境がVB.NET+ADO.NETなもので

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

293 名前:仕様書無しさん mailto:sage [2007/02/18(日) 22:13:48 ]
普通に結合度の高さを判断して高いと思われるほうにくっつけるだよ

294 名前:仕様書無しさん mailto:sage [2007/02/18(日) 22:44:46 ]
あー、用意されてんならそれ使うべきだね

295 名前:仕様書無しさん mailto:sage [2007/02/18(日) 23:31:46 ]
外部結合とかサブクエリのSQL自動生成出来るの?

296 名前:仕様書無しさん mailto:sage [2007/02/19(月) 00:54:28 ]
SQL自体を変えること自体があんまりないような気がするんだが……
ハードコーディングしてもしなくても大差ないんじゃね?

297 名前:仕様書無しさん mailto:sage [2007/02/19(月) 01:10:25 ]
>>295
できるけど、できたらそれ使うか?
そういう問題じゃない気が。。

298 名前:仕様書無しさん mailto:sage [2007/02/19(月) 01:36:52 ]
複雑なSQLが必要な場面って
大抵システムのボトルネックになるから人力で調整が必須なものなんだよね。

299 名前:仕様書無しさん [2007/02/19(月) 07:01:13 ]
SQLで苦労するって
テーブル構成が糞なんじゃないかと

300 名前:仕様書無しさん mailto:sage [2007/02/19(月) 18:03:43 ]
データ取得 → Viewつくって一発
データ更新 → ストアドつくって一発

ベタでいいじゃん



301 名前:仕様書無しさん mailto:sage [2007/02/19(月) 22:31:22 ]
>>300
原則これだよね。

302 名前:仕様書無しさん mailto:sage [2007/02/19(月) 22:52:49 ]
だから、Viewは、遅いと(ry 
ループですな

303 名前:仕様書無しさん [2007/02/19(月) 23:13:44 ]
viewならびゅーっといきそうなもんだが

304 名前:仕様書無しさん mailto:sage [2007/02/19(月) 23:17:09 ]
viewより手組の方が早いと考えるのは素人

305 名前:仕様書無しさん mailto:sage [2007/02/19(月) 23:18:18 ]
>>300
View作って取得すると実際はどのテーブルにどのデータが入ってるのか
ってのが分かりにくいからあんまり好きじゃないんだよなー。

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

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

306 名前:仕様書無しさん mailto:sage [2007/02/19(月) 23:48:37 ]
viewはorder byできないじゃない。

307 名前:仕様書無しさん [2007/02/19(月) 23:50:00 ]
>>306
ウソツケ

308 名前:仕様書無しさん mailto:sage [2007/02/19(月) 23:54:57 ]
>>300
どういう論理展開なんだ?

309 名前:仕様書無しさん mailto:sage [2007/02/20(火) 00:12:27 ]
>>306
SQL自体を勉強しなおしてから出直せ。

310 名前:仕様書無しさん mailto:sage [2007/02/20(火) 08:04:32 ]
>>306
神降臨



311 名前:仕様書無しさん mailto:sage [2007/02/20(火) 11:37:59 ]
>>298
既存のパッケージ品をカスタマイズして使わされる時も複雑になるね。
汎用機時代のファイル構造をそのままRDBに入れ直(ry

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

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

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

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

さてメシ食ってこよう

312 名前:仕様書無しさん mailto:sage [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 名前:仕様書無しさん mailto:sage [2007/02/20(火) 16:19:48 ]
>>311
>>308はベタ書きじゃなくて、ベタな(一般的な)手法という意味じゃなかろうか。

316 名前:仕様書無しさん [2007/02/20(火) 16:44:22 ]
>>313
DBエンジニアがいればいいけどな。。。

317 名前:仕様書無しさん mailto:sage [2007/02/20(火) 18:32:42 ]
社内ルールでストアドはおろかビューも使えません
理由は「俺が知らないから(by上司)」
ORマッピングツールなんて夢のまた夢さ


318 名前:仕様書無しさん [2007/02/20(火) 20:31:32 ]
それは正しい

319 名前:仕様書無しさん mailto:sage [2007/02/20(火) 22:04:29 ]
>>317
ストアドはまだ許す。代替手段があるし、知らん言語は知らんだろうと。
だが、View程度で投げるな。orz...

320 名前:仕様書無しさん mailto:sage [2007/02/20(火) 22:21:35 ]
viewってテーブル構成が糞だと
updateできなかったりなんだりでもうワケワカメじゃん

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



321 名前:仕様書無しさん mailto:sage [2007/02/20(火) 22:31:17 ]
ハードコーディングならハードコーディングで統一してほしかったな、ウチのプロジェクト……
いろんな手法が混ざってんのは最悪だよ。
ハードコーディング派の中でも>>250みたいな書き方する奴とプレースホルダ使う奴と……

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

322 名前:仕様書無しさん mailto:sage [2007/02/20(火) 22:36:54 ]
>>321
俺のかかわったプロジェクトにいたっては、
そのほかに、長文Viewを書く奴と、ストアドでカーソル駆動する奴と、
何を狂ったか、RecordSetを一旦テキストファイルに落として操作する奴が
いたわけだ。

323 名前:仕様書無しさん [2007/02/20(火) 23:19:53 ]
>RecordSetを一旦テキストファイルに落として操作する奴

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

324 名前:仕様書無しさん mailto:sage [2007/02/20(火) 23:35:02 ]
>>323
ワークテーブルならぬワークファイル、しかも固定長だよ。
奴がコボラだったから、テキストファイルを操作するほうが具合よかったそうだ。

325 名前:仕様書無しさん mailto:sage [2007/02/21(水) 05:47:32 ]
どうりでウチのシステムのcronにrm -rf /var/hogehogeとか入ってるわけだ


326 名前:仕様書無しさん mailto:sage [2007/02/21(水) 07:33:17 ]
>>324
おつかれ

327 名前:仕様書無しさん mailto:sage [2007/02/21(水) 11:54:04 ]
>>317
うちも全く同じだったので、上司と血を見るほどの大げんかをしてしまった。
こちらが完全に理論武装してパフォーマンス比較までレビューしたせいか、涙を浮かべて逆ギレされた。
しまいには「その比較実験は完全に捏造だ!」とまで言われ、そのせいで処分まで受けてしまった。


328 名前:仕様書無しさん mailto:sage [2007/02/21(水) 12:10:58 ]
>>327は実にバカだな。

329 名前:仕様書無しさん [2007/02/21(水) 12:25:41 ]
>>327
馬鹿かぁーーー!!
お前かーーーー!!

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

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

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

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

330 名前:仕様書無しさん mailto:sage [2007/02/21(水) 12:28:58 ]
>>327
バカな奴だ。329が正解だよ。



331 名前:仕様書無しさん mailto:sage [2007/02/21(水) 12:49:12 ]
>こちらが完全に理論武装してパフォーマンス比較までレビューしたせいか、
何が嬉しくてここに書き込るのか知らんが、上司の顔を潰すことを目的にプレゼンしたんだろ。
逆切れしてるのは>>327じゃないの?
ここまで空気を読めないヤツよりは、>>322の一番最後のコボラの方がマシな気がする。

332 名前:仕様書無しさん mailto:sage [2007/02/21(水) 14:11:44 ]
ケンカはダメ!みんな仲良くしよ♪

333 名前:仕様書無しさん mailto:sage [2007/02/21(水) 15:05:58 ]
アホ上司は、アホだが上司だからな
理論武装と同じ程度の会社組織を壊す覚悟が必要だったな

334 名前:仕様書無しさん mailto:sage [2007/02/21(水) 15:09:40 ]
こういうやつは客に対しても同じことしそうだ。
購入した備品にけちつけてみたり。

335 名前:仕様書無しさん [2007/02/21(水) 15:53:57 ]
327の能力は評価するが
一緒には仕事したくないタイプ

336 名前:仕様書無しさん mailto:sage [2007/02/21(水) 16:28:25 ]
>327の人気に嫉妬

337 名前:仕様書無しさん [2007/02/21(水) 17:04:57 ]
ひあああああっ……!あああン!もうっ、もうダメぇ……!イっちゃう……!イっちゃ
う、イっちゃう、イっちゃう、イっちゃあひいいいいいいいいッ!イくうっ!そんなにされ
たらすぐイっちゃうよぉーっ!ああああああ!イク、イク、イク、イク、イク、イクッ!あ
っ、熱いい〜ッ!ああああああ!イクうッ!イクイクイクイクっ!イクうううううううううう
う〜!あああああああぁ……!あうっ……ああああ……イクう……あひいいいいいい
いぃ……!はへええええ!イグっ!イグうっ!イグイグイグイグ!イグーッ!あへ!
はへえっ!ひゃひいいいい!に、妊娠しちゃうっ!妊娠しちゃうううゥ〜!気持ちイイ
ぃ〜!妊娠キモチイイよぉ〜!ああああああああ!妊娠しながらイグう!イグっ!イ
グうっ!イグうぅーっ!

338 名前:仕様書無しさん mailto:sage [2007/02/21(水) 17:09:39 ]
こんなところにまで任豚の魔の手が・・・!!
>>327はスレタイはとっとと氏ね

339 名前:仕様書無しさん [2007/02/21(水) 17:23:23 ]
これが世に言う「コミュニケーション能力の欠如」というやつかね。

340 名前:仕様書無しさん mailto:sage [2007/02/21(水) 17:34:07 ]
とっとさんって誰?



341 名前:仕様書無しさん mailto:sage [2007/02/21(水) 18:37:41 ]
まあそれまでにもいろいろあったんだろうよ
そこまで327を叩くなって
もっとまったりいこうぜ

342 名前:仕様書無しさん mailto:sage [2007/02/21(水) 21:44:44 ]
>>341

 こ
  と

343 名前:仕様書無しさん mailto:sage [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 名前:仕様書無しさん mailto:sage [2007/02/22(木) 16:53:43 ]
>>343
漏れの経験上、余程単純なシステムでない限り、
下手に修正を入れると、ドつぼにはまると思ひまふ。


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

350 名前:仕様書無しさん mailto:sage [2007/02/22(木) 17:03:45 ]
技術者としては綺麗さっぱり修正したいが、ワーカーとしてはそんな金にならねえ癖に大変な事はやってる暇ねえと言う現実だ



351 名前:仕様書無しさん mailto:sage [2007/02/22(木) 18:03:31 ]
そういう意味ではハードコードは色々便利だなw

352 名前:仕様書無しさん mailto:sage [2007/02/22(木) 18:08:02 ]
>>351
どういう意味だw

353 名前:仕様書無しさん mailto:sage [2007/02/22(木) 18:56:12 ]
言ってみたかったw

354 名前:仕様書無しさん mailto:sage [2007/02/23(金) 01:23:29 ]
ハードコーディングをSQLServerで
パラメータ部分を ' を '' に変換してたら
SQLインジェクションなんて全然関係ない
ハードコーディング万歳

355 名前:仕様書無しさん [2007/02/23(金) 07:31:33 ]
エスキューエルハードコーディング
相手は死ぬ

356 名前:仕様書無しさん mailto:sage [2007/02/23(金) 07:34:02 ]
ハードコーディング自体を嫌うのは、
コンパイラーが死ぬほど、遅かった時代の爺だけだと思われ。

357 名前:仕様書無しさん mailto:sage [2007/02/23(金) 07:40:07 ]
インデックス張るの忘れてたw
特に何も言われないので、バージョンアップのたびに小出しにしてやろう。

358 名前:仕様書無しさん [2007/02/23(金) 08:18:36 ]
SQL外出しのなにが嬉しいのかさっぱりわかんね。
中出しで十分。

359 名前:仕様書無しさん [2007/02/23(金) 08:56:58 ]
ビジュアル的には外出しの方が萌えね?

360 名前:仕様書無しさん mailto:sage [2007/02/23(金) 11:14:40 ]
中出しの方が自然だろ



361 名前:仕様書無しさん mailto:sage [2007/02/23(金) 14:23:41 ]
>>5
外に出しても大差ないだろ

362 名前:仕様書無しさん mailto:sage [2007/02/23(金) 14:51:17 ]
ちゃんとつけないとな。

363 名前:仕様書無しさん mailto:sage [2007/02/23(金) 15:03:05 ]
いい流れですね

364 名前:仕様書無しさん [2007/02/23(金) 17:26:49 ]
市販のプロテクトを信用してると
穴が開いてることがあるぞ。

365 名前:仕様書無しさん [2007/02/23(金) 17:53:44 ]
お前ら、中出しだの外出しだの穴だのいい加減にしろよ

366 名前:仕様書無しさん mailto:sage [2007/02/23(金) 18:18:35 ]
要するに、>>365はお口に出して欲しい。ということだな?

367 名前:仕様書無しさん mailto:sage [2007/02/23(金) 19:27:58 ]
>>343
これ見て思い出したんだが、昔、とんでもないシステムの改修させられたな。

当時アクセス2000がすでに主流の時代にアクセス2.0だかなんだかで作られた
システム(そのこと自体は別にいいんだが)で、

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

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


368 名前:仕様書無しさん mailto:sage [2007/02/23(金) 21:42:24 ]
>>367
似たようなので、「全ての年は月曜から始まる」って前提のソースがあったw

369 名前:仕様書無しさん [2007/02/23(金) 22:57:33 ]
なんつーか、単なるアホなんじゃなかろうか

370 名前:葉猫 ◆Jz.SaKuRaM mailto:sage [2007/02/23(金) 23:51:53 ]
SQLだと曜日や日にちの計算が楽でいいけど、ここはあえてZellarの公式で曜日を求めてみるテスト



371 名前:仕様書無しさん mailto:sage [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 名前:仕様書無しさん mailto:sage [2007/02/24(土) 00:11:12 ]
Pro*Cには似てないな

373 名前:仕様書無しさん mailto:sage [2007/02/24(土) 10:31:51 ]
何が嫌ってPro*C嫌いだなぁ。


374 名前:仕様書無しさん mailto:sage [2007/02/24(土) 10:37:32 ]
Javaがある今、Pro*Cの存在意義ってないな

375 名前:仕様書無しさん mailto:sage [2007/02/24(土) 14:50:23 ]
>>367
それ、SQL関係なくねw?

376 名前:仕様書無しさん mailto:sage [2007/02/24(土) 16:18:53 ]
Javaさえあれば何もいらない人は思考が停止してるよね

377 名前:仕様書無しさん mailto:sage [2007/02/24(土) 16:23:21 ]
Pro*C/C++ は C に埋め込むにはいいんだが
C++ に埋め込むととたんにがっかりするからな。

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

378 名前:仕様書無しさん mailto:sage [2007/02/24(土) 20:11:46 ]
プロジェクトでハイバネ使おうということになったらしいが、使える人がいないらしい


379 名前:仕様書無しさん mailto:sage [2007/02/24(土) 20:17:17 ]
ハイバネなんて使っていいことないよ

380 名前:仕様書無しさん mailto:sage [2007/02/24(土) 20:21:02 ]
上の方で大絶賛してる奴がいるぞ



381 名前:仕様書無しさん mailto:sage [2007/02/24(土) 20:26:21 ]
メリット・デメリット・向き・不向きをわかって
総合的判断で取り入れるのならいいけどね。>ハイバネ
無条件で大絶賛とか、使える人もいないのにとりあえず使ってみようでは
いいことがあるわけない。

382 名前:仕様書無しさん mailto:sage [2007/02/24(土) 20:36:25 ]
lazyロードとかトランザクションとか
気を使うとこが、かえって増えるから
個人的にはハイバネは、嫌いだな。
PJ内に詳しい人がいれば別なのかもしれんが。

383 名前:仕様書無しさん mailto:sage [2007/02/24(土) 21:46:12 ]
>>382
>PJ内に詳しい人がいれば別なのかもしれんが。
黒船願望キタ━━━━(゚∀゚)━━━━ !!!!!


384 名前:仕様書無しさん mailto:sage [2007/02/24(土) 21:54:05 ]
C/C++ならだまってOCI

385 名前:仕様書無しさん mailto:sage [2007/02/26(月) 21:35:42 ]
データ検索機能を実装するときみんなどうしてるのかな。
データの持ち方にもよるんだろうけど、俺は(というかプロジェクトでは)
SQLを動的に生成して投げてしまう。

386 名前:仕様書無しさん [2007/02/26(月) 21:50:24 ]
それ以外に方法が?

387 名前:仕様書無しさん mailto:sage [2007/02/26(月) 22:25:15 ]
入力された検索条件をテーブルにいったん落として、
それをSelectで拾ってさらにSelect。全検索のログも残って便利。

388 名前:仕様書無しさん mailto:sage [2007/02/26(月) 22:41:56 ]
言語、データ量、やりたい処理にもよるんでないの。

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

389 名前:仕様書無しさん mailto:sage [2007/02/26(月) 22:53:27 ]
先生!
動的な生成はハードコーディングに入りますか?


390 名前:仕様書無しさん [2007/02/26(月) 23:25:43 ]
動的ってダイナミック?
オンザフライ?



391 名前:仕様書無しさん mailto:sage [2007/02/26(月) 23:32:54 ]
動物的

392 名前:仕様書無しさん mailto:sage [2007/02/26(月) 23:58:26 ]
RDB使う以上Javaよりも低レイヤの言語使ってもあんま意味無いよね。
いくら頑張ってもけっきょくDBのボトルネックが問題になるし。

393 名前:仕様書無しさん mailto:sage [2007/02/27(火) 01:16:12 ]
RDB使う以上どんな言語使ってもDBのボトルネックが問題になるし。

あれ?

394 名前:仕様書無しさん mailto:sage [2007/02/27(火) 20:53:19 ]
Java使う以上JavaVMがボトルネックになるよね^^

395 名前:仕様書無しさん mailto:sage [2007/02/27(火) 22:41:30 ]
それいじょうにRDBのボトルネックがでかいって言ってるんじゃねぇの?

396 名前:仕様書無しさん mailto:sage [2007/02/27(火) 22:54:00 ]
いくらがんばってもRDBがボトルネックになるんだったらJava使っても使わなくても変わんないんじゃ・・・

397 名前:仕様書無しさん mailto:sage [2007/02/27(火) 23:28:17 ]
Java言いたいだけかと

398 名前:仕様書無しさん mailto:sage [2007/02/28(水) 00:20:03 ]
つまり、RubyとかPHPとかJavaとか、実行速度が遅い言語でもいいって事じゃね?
Cとか実装に時間がかかる&ナーバスな言語にこだわる必要は無いって事を言いたいんだと思われ。

399 名前:仕様書無しさん mailto:sage [2007/02/28(水) 00:26:48 ]
どうでもいいけどサーバサイドのJavaは全く遅くないどころか、
スケーラビリティとか考えたら現時点では最速だろ。

400 名前:仕様書無しさん mailto:sage [2007/02/28(水) 00:36:24 ]
スケーラビティ考えてSQLハードコード



401 名前:仕様書無しさん mailto:sage [2007/02/28(水) 01:24:06 ]
JVM立ち上がってれば速いよな

402 名前:仕様書無しさん mailto:sage [2007/02/28(水) 01:58:41 ]
>>399
スケールできるだけで最速ではないと思う。
スケールの容易さではLAMPにも迫られてるような気もするし。

403 名前:仕様書無しさん mailto:sage [2007/02/28(水) 02:52:19 ]
このスレは、スケールよりも保守性の方の話題なわけだが

404 名前:仕様書無しさん [2007/02/28(水) 06:41:21 ]
PHPって結構早いような希ガス

405 名前:仕様書無しさん mailto:sage [2007/02/28(水) 08:45:08 ]
>>404
保守性が落ちていくのがな.
マイナーバージョンアップで言語仕様が大幅に変わるのは病めていただきたい.

406 名前:仕様書無しさん mailto:sage [2007/02/28(水) 09:54:22 ]
本当に良いモノってのは、変える必要は無いんだよ。

407 名前:仕様書無しさん [2007/02/28(水) 10:03:58 ]
Java厨に言えよ

408 名前:仕様書無しさん mailto:sage [2007/02/28(水) 19:59:55 ]
確かに単体ではJavaのほうが速い。
しかし、今のところ重厚長大なJavaで作りこんで単体で高速なものを目指すより、
PHPやPerlでさっくり作って、パフォーマンスはロードバランサで稼ぐほうが、
コストも安いし保守も楽。

409 名前:仕様書無しさん mailto:sage [2007/02/28(水) 20:00:38 ]
パフォーマンスもあがる。Javaに勝ち目は無いよ。

410 名前:仕様書無しさん mailto:sage [2007/02/28(水) 20:05:35 ]
保守楽か?



411 名前:仕様書無しさん mailto:sage [2007/02/28(水) 20:47:16 ]
>>408
変態wハケーン

412 名前:仕様書無しさん mailto:sage [2007/02/28(水) 21:52:03 ]
PHPは、知らんがPerlの保守は、地獄の悪寒がするよ。


413 名前:仕様書無しさん mailto:sage [2007/02/28(水) 21:59:15 ]
言語の違いによる保守性の話はスレちがいだということを理解できない輩がいますね

414 名前:仕様書無しさん mailto:sage [2007/02/28(水) 22:01:10 ]
この場合の保守性というのは、少ないJava鯖より大量のPHP/Perl鯖のほうが
再起動などメンテナンスしやすいという意味では

415 名前:仕様書無しさん mailto:sage [2007/02/28(水) 22:02:14 ]
PHPはパッケージを使うとORマッパーぽいことも出来るみたいだけどなー。

416 名前:仕様書無しさん mailto:sage [2007/02/28(水) 22:33:02 ]
PHPがサックリあたりまでは解るが保守楽かぁ?

仕事だとIBMのIDE(WDSc:Eclipesの商用Ver))使ってるけど、
PHPよりもJavaの方があきらかにサックリ作れるぞ。

それに要件が決まっているなら作りこむ量は一緒だろ。

417 名前:仕様書無しさん [2007/02/28(水) 22:36:50 ]
Javaじゃ大量の鯖を導入できないじゃん。WebLogic高くて。

418 名前:仕様書無しさん mailto:sage [2007/02/28(水) 22:40:29 ]
Javaとかどうでもいいんだよ
ハードコーディングすること自体はどうなのよ

419 名前:仕様書無しさん mailto:sage [2007/02/28(水) 22:43:58 ]
んだ。誰かJava vs LAMPのスレ立ててそっちでやれや

420 名前:仕様書無しさん mailto:sage [2007/02/28(水) 22:44:11 ]
ハードコーディングするかしないかは大した問題ではない。



421 名前:仕様書無しさん mailto:sage [2007/02/28(水) 22:45:54 ]
>>420
これは上司の一言スレのネタですね

422 名前:仕様書無しさん mailto:sage [2007/02/28(水) 23:18:52 ]
ハードコーティングが悪か?って言われてもケースバイケースだろ。

たとえば、ホストがOracleでクライアントがAccessの時に
AccessからSQL投げるのと、Oracleでストアドとどっちかマシか?って話なのか?

423 名前:仕様書無しさん mailto:sage [2007/02/28(水) 23:23:34 ]
>>422
それじゃマシも何も、用途が違うじゃねえか

424 名前:仕様書無しさん [2007/02/28(水) 23:45:13 ]
Javascriptの保守の方が大変じゃね?

425 名前:仕様書無しさん [2007/02/28(水) 23:46:14 ]
ストアドのほうが開発者側の意識として緊張感が違うと思うw
感覚的なものだけど

426 名前:仕様書無しさん mailto:sage [2007/03/01(木) 00:02:11 ]
400以上のレスをロールバックw

427 名前:仕様書無しさん mailto:sage [2007/03/01(木) 00:04:03 ]
>>423
いや、この場合だと用途は同じでOracleにあるデータを
集計してAccessに取り込むって目的だが、
AccessからVBA(ADO)でSQL投げて結果を受け取るか、
ADOでストアド呼ぶか?の違いがあるだけだが。

漏れが提案する以前は、Oracleから全明細読み込んで
Accessで集計していた。

SQLを一切使わないOracleで不思議と感動した。w

428 名前:仕様書無しさん mailto:sage [2007/03/01(木) 00:16:17 ]
ケースバイケースは魔法の言葉

429 名前:仕様書無しさん mailto:sage [2007/03/01(木) 01:17:01 ]
>>427
そーゆーショボイ用途で使われてるDB鯖に限ってスッペクを奢ってたりするから不思議。

430 名前:仕様書無しさん [2007/03/01(木) 02:10:00 ]
わかった!!
1は最近、『ハードコーディング』って言葉を覚えたんだな w



431 名前:仕様書無しさん mailto:sage [2007/03/01(木) 06:47:49 ]
>>429
正直Oracleはいらん罠。
まあ、元ネタはCOBOLer上がりのヤツが提案したので、
各所でグダグダな設計だった。

データの更新はSQLを一切使わずにCOBOLとロードモジュール?(謎モジュール)
だけで実現していたので、ある意味ここの>>1が喜びそうなシステムではあるな。

漏れは最悪だと思ったが。w

432 名前:仕様書無しさん mailto:sage [2007/03/01(木) 09:42:01 ]
>>429
毎回全件取得だと高速なディスクと大量のメモリがないと
まともに使えるようなレスポンスが得られないからなwww

433 名前:仕様書無しさん [2007/03/01(木) 10:10:21 ]
ストアド知らんだけだろ

434 名前:仕様書無しさん mailto:sage [2007/03/01(木) 10:59:17 ]
俺のチンコがソフトコーティングされてます

435 名前:仕様書無しさん [2007/03/01(木) 12:32:20 ]
>>434 仕事はいいから包茎手術に逝け。な?

436 名前:仕様書無しさん mailto:sage [2007/03/01(木) 13:47:17 ]
しかし、ストアドを乱用する奴もいるよね。

437 名前:仕様書無しさん [2007/03/01(木) 15:54:39 ]
>>436
マスタで一覧取得とか1件更新すらも、とにかくDBアクセスストアドっていう
ストアダーに出会ったことがある。

俺の中では、集計とか重い処理なんかの時にストアド使っていくもんだと思ってたんだが・・
他の皆の意見はどうなのよ?

438 名前:仕様書無しさん mailto:sage [2007/03/01(木) 16:09:24 ]
重い処理をDBにやらせるのはどうかと思う。

439 名前:仕様書無しさん mailto:sage [2007/03/01(木) 16:10:31 ]
>>437
・WebとWin32クライアントが混在や並行稼働している(別々の言語からアクセスする可能性がある)
・ストアドのドキュメントがきっちり分類されて管理されている
ならば可能な限りストアドにしてしまった方がいい場合がある。と思う。


440 名前:仕様書無しさん mailto:sage [2007/03/01(木) 19:59:59 ]
ストアドもいろいろな効用があるからなぁ。
あからさまに長い時間がかかる処理はストアドだろうし、
かなり複雑な処理もストアドだろうなぁ。

ただ、DB2とかだとテーブルの統計情報を元にアクセスプランを
組み立てるタイプのだとある程度実務をこなしてから
ストアドにしないと、最適化に無駄が出る気がするので、
最初にいきなりストアド作ってほったらかしはアレかもしれん。

いまどきは人間の最適化よりもRDBMSのオプティマイザーの方が賢いし。

COBOLerがCOBOLでコーティングしたり妙なストアド組むよりも
素直なSQLを投げた方がRDBの性能引き出せる場合もある。



441 名前:仕様書無しさん mailto:sage [2007/03/01(木) 20:06:09 ]
>>427
いいなぁ。VPNで運用する要望が出たらリプレースで丸儲けだぜw

442 名前:仕様書無しさん mailto:sage [2007/03/01(木) 20:22:48 ]
無意味に妙に一貫性のある開発スタイルを採用しているものの方が、
機能追加や保守の際にはまることが多い。
トリッキーなコードをさらにトリッキーにすることで維持するくらいなら
掟を破っても良いんじゃないかと思うオレは若すぎますか?

443 名前:仕様書無しさん mailto:sage [2007/03/01(木) 21:44:15 ]
>>442
具体的になんなんだ?

Javaとかでインターフェイスや継承しまくったクラス設計をトリッキーに感じてを保守しにくい、とか
VBで1メソッドを何十行もダラダラと長く記述するのを保守しやすい、とか
言うなら、藻前は若いんじゃなくて爺だと思うけど。

444 名前:仕様書無しさん mailto:sage [2007/03/01(木) 21:50:14 ]
SQL文をハードコーディングするやつはとっとと引越しー

445 名前:仕様書無しさん mailto:sage [2007/03/02(金) 00:37:30 ]
>>437
ストアダーになってみたことはある。
Update系は意外と楽できる。

446 名前:仕様書無しさん mailto:sage [2007/03/02(金) 02:27:54 ]
俺の経験だと、コードに対する名前を他のテーブルから引っ張ってくるような部分も
結構、ストアドにすると良い感じだったな。Joinより見やすいし
外部結合時が必要な時も、パフォーマンスが出たように記憶している。

447 名前:仕様書無しさん mailto:sage [2007/03/02(金) 15:39:11 ]
隊長!Hibernateとかいろいろ使った結果、1周してJDBCに帰ってまいりました。

448 名前:仕様書無しさん mailto:sage [2007/03/02(金) 15:54:15 ]
JSP+Servlet+JDBC最強だよな

449 名前:仕様書無しさん mailto:sage [2007/03/02(金) 16:09:56 ]
>>448
あまりに強すぎて、討ち死に続出。

450 名前:仕様書無しさん [2007/03/02(金) 17:16:12 ]
JSPよりServletの方がいいだろ



451 名前:仕様書無しさん mailto:sage [2007/03/02(金) 20:23:14 ]
詳細テーブルと親テーブルのレコードが1:nの奴にupdateするときとか便利だよね<ストアド

452 名前:仕様書無しさん mailto:sage [2007/03/03(土) 00:05:23 ]
>>448-450
これだからJava厨はきらいなんだ。。。


453 名前:仕様書無しさん mailto:sage [2007/03/03(土) 00:11:30 ]
>>452
ごめんな。。

454 名前:仕様書無しさん mailto:sage [2007/03/03(土) 00:14:58 ]
>>453
あ、いや、こっちこそ。。

455 名前:仕様書無しさん mailto:sage [2007/03/04(日) 00:33:01 ]
ストアドは賛否両論あるとして、
トリガって実務で使ってるか?

俺が趣味でやってる会員制サイト(エロではない)(SQLServer2005)作るときに、
「そういや実務でトリガって使ったこと無いな」と思って、試しに
トリガ使ってみたら便利だった。

退会処理はマスターの該当ID消すだけで、他のテーブルに持ってる
そいつのレコードが全消しとか。


456 名前:仕様書無しさん mailto:sage [2007/03/04(日) 00:41:50 ]
>>455
つ 参照整合性

457 名前:仕様書無しさん mailto:sage [2007/03/04(日) 02:12:14 ]
>>455
使う。便利だ。似たような用途だ。
例えば、新規取引先を登録したときなど。
問題は、あんまり知っている奴が多くないので、メンテで苦労することか。

458 名前:仕様書無しさん mailto:sage [2007/03/04(日) 08:24:09 ]
>>455
別アプリと連携させるときに使うよ。
マスタ情報が更新されたら渡す、みたいな。

削除は削除フラグ立てることが多いな。
場合によるけど。

459 名前:仕様書無しさん mailto:sage [2007/03/04(日) 10:39:24 ]
>>455
俺の経験ではトリガ使わずに、アプリ側で制御するね。
理由は不明。なんでだろうね。

460 名前:仕様書無しさん mailto:sage [2007/03/04(日) 10:57:00 ]
>>459
トリガは便利だが、使い方を間違えると収拾付かなくなるし、
ケースバイ・ケースだろうな。

基本の味付けはアプリでして、調味料的にトリガにすると丁度よい。

しかし、アプリで行うとハードコーディングという問題が発生し、スレタイへ戻る。



461 名前:仕様書無しさん mailto:sage [2007/03/04(日) 12:33:12 ]
トリガからストアドを呼び出してスパゲッティ

462 名前:仕様書無しさん mailto:sage [2007/03/04(日) 18:17:00 ]
極力ルールはアプリ側に置きたいので使わない

463 名前:仕様書無しさん mailto:sage [2007/03/04(日) 19:44:14 ]
ロジックの分離イクナイ

464 名前:仕様書無しさん mailto:sage [2007/03/04(日) 20:32:17 ]
トリガは便利だけど、知っている奴が少ないのが難点だな。

(DB2/400は)テーブルをコピーしてもトリガはコピーされないって点を
忘れると悲劇が待ってるし、仕方ないと思うが更新処理のパフォーマンスが
落ちる場合もあるので、使う時は気をつけている。

ロジックの分離と言うかさりげなくアクセスログを取っているって
使い方が多いな。
「このフィールドを更新したの誰だよ?」って感じで。

465 名前:仕様書無しさん mailto:sage [2007/03/04(日) 21:41:42 ]
SQLのハードコード云々よりも
・ストアド禁止
・ビュー禁止
・トリガー禁止
のルールを徹底させようとするPM/SEのほうが先に氏んでくれと思う。


466 名前:仕様書無しさん mailto:sage [2007/03/04(日) 21:49:15 ]
ビューとトリガーは禁止でいいよ

467 名前:仕様書無しさん mailto:sage [2007/03/04(日) 22:01:33 ]
ビューは、遅くて使い物にならん。

468 名前:仕様書無しさん [2007/03/04(日) 22:01:38 ]
>「このフィールドを更新したの誰だよ?」って感じで。 

あるあるw

馬鹿ユーザが「いじってない!」とか抜かしたときに
本当かどうか調べられるし

469 名前:仕様書無しさん mailto:sage [2007/03/04(日) 22:14:55 ]
テンポラリテーブルはありでつか?

470 名前:仕様書無しさん mailto:sage [2007/03/04(日) 23:39:56 ]
通常SQL部分はクラスでラップするから、ハードコーディングでいいんでは?
場合によってストアドも使うし、トリガは注意して使えば問題ないし、
ビューもテーブル設計の変更ができない時に仕方なく使う分にはいいんじゃない?



471 名前:仕様書無しさん mailto:sage [2007/03/05(月) 00:23:02 ]
>>465
ルールを徹底させるだけマシだとおもう。

好きに使っていいよってプロジェクトの悲惨さに比べたら・・・

472 名前:仕様書無しさん mailto:sage [2007/03/05(月) 00:30:12 ]
そうだな。駄目なら駄目としてくれたほうがすっきりする。

473 名前:仕様書無しさん mailto:sage [2007/03/05(月) 00:56:19 ]
トリガーは微妙なんだが、ストアドやビューを好きに使われると
ナニか困るのか?

逆説っぽくてアレなんだが、困るストアドを作るやつは
ストアド禁止にしても困るコーティングすると思う。
ビューも同様な。

474 名前:仕様書無しさん mailto:sage [2007/03/05(月) 08:17:50 ]
>>467
それはアンタのSQLが悪いだけwww


>>473
同意

475 名前:仕様書無しさん mailto:sage [2007/03/05(月) 08:27:20 ]
駄目な奴は何をやっても駄目.

最低限,SQLをプログラムの各所に散らばらすのは止めて欲しい.
前に見た奴だと,ボタン押下イベントの中でSQL投げてたのを見たことある.

476 名前:仕様書無しさん mailto:sage [2007/03/05(月) 08:42:19 ]
え?普通じゃね?

477 名前:仕様書無しさん mailto:sage [2007/03/05(月) 09:02:29 ]
ボタンを押下した後にDB検索にいくなら、
嫌でもSQL投げないと、何も始まらないよな。

478 名前:仕様書無しさん mailto:sage [2007/03/05(月) 09:03:02 ]
>>473
人単体で見れば確かにそのとおり。

ただ、全体で見たときに非常に美しくなくなるんだよね。
極端な話、マスタ登録はストアド側でマスタ更新はプログラム側ってこともありうるのよ。
同じレイヤーのロジックをストアドで組んだりプログラムで組んだりっていうのは
アーキテクチャとして正しい姿なのか?っていうのは疑問。

>>476
え?
イベントハンドラとロジックはわけようぜ兄弟

479 名前:仕様書無しさん mailto:sage [2007/03/05(月) 09:18:23 ]
VBの簡単な画面でそれやられると萎える

480 名前:仕様書無しさん mailto:sage [2007/03/05(月) 09:18:52 ]
たかがVBだからな



481 名前:仕様書無しさん mailto:sage [2007/03/05(月) 10:47:56 ]
>>475>>479-480
VB入門書にそういう記述をしている本がけっこうあるからなのさ。


482 名前:仕様書無しさん mailto:sage [2007/03/05(月) 11:05:18 ]
VB厨がプログラムを分割しようとすると妙に不自然な形になるからなぁ。
長大なイベントハンドラを許容しておいたほうが無難かもしれん。

483 名前:仕様書無しさん mailto:sage [2007/03/05(月) 11:48:56 ]
>>466
うそを言うな、ウソを。

484 名前:仕様書無しさん mailto:sage [2007/03/05(月) 12:27:10 ]
>>482
モジュールに関数書いて、呼び出すようにしても、クラス化しろよ低脳とか言われちゃうしな

485 名前:仕様書無しさん mailto:sage [2007/03/05(月) 12:31:12 ]
>>474

ビューにインデックスを張れない以上、
ビューの遅さは、どうしようもないと思うけど。


486 名前:仕様書無しさん mailto:sage [2007/03/05(月) 12:36:52 ]
ビューと通常のSELECTだとビューが遅いというのは、どこで遅くなっているんだろうか

487 名前:仕様書無しさん mailto:sage [2007/03/05(月) 12:38:06 ]
>>484
Foo formに1:1で対応するFoo logicクラスを作ってそこに全ての処理を延々書き連ねたコードなら見た。
イベントハンドラでは、そのlogicクラスのインスタンスを生成して、イベントハンドラに対応する長大なひとつのメソッドを呼ぶ。
アホかと。

488 名前:仕様書無しさん mailto:sage [2007/03/05(月) 12:51:19 ]
>>486

出来上がったビューにインデックスが張れないから遅いんだよ。


489 名前:仕様書無しさん mailto:sage [2007/03/05(月) 12:55:59 ]
>>488
別のビュー作ればいいじゃん

490 名前:仕様書無しさん mailto:sage [2007/03/05(月) 13:11:22 ]
>>489
え?



491 名前:仕様書無しさん [2007/03/05(月) 13:12:29 ]
>>488
じゃないけど
ちょっとそれ教えて欲しいと思った
今までDataSetで取り込んだりした後自分でPk設定してたりしてるんで
元々ViewにKeyを埋め込めるのならそうしたい

492 名前:仕様書無しさん mailto:sage [2007/03/05(月) 13:14:29 ]
ビューが実態のあるオブジェクトなDBもあるのか?
普通はテーブルを参照するオブジェクトだと思うが。

参照の仕方をユーザー毎に区切ったりする場合に使うのでは。

493 名前:仕様書無しさん [2007/03/05(月) 13:21:18 ]
ビューの元になるテーブルに適切なインデックスが張られていれば
ビューもそんなに問題にならないと思うけど

もしかしてjoinの代わりにビュー使ってるの?

494 名前:仕様書無しさん mailto:sage [2007/03/05(月) 13:33:06 ]
ビューにインデックス貼るって、用途無視してビュー作ってるだけじゃんw
ビューって言いたいだけだろ

495 名前:仕様書無しさん mailto:sage [2007/03/05(月) 13:54:05 ]
早い遅いはDB板で。

O/Rマッパーマンセーとかそういうレス希望

496 名前:仕様書無しさん mailto:sage [2007/03/05(月) 15:17:42 ]
>>488
実行計画とって、きちんとINDEXが使われるようなVIEWにしろwww
つか、元表にちゃんとINDEX作れwww


>>492
Oracleなんかじゃマテリアライズドビューなんていう
実データを持つVIEWのようなものは存在する。


>>493
正解。


497 名前:仕様書無しさん mailto:sage [2007/03/05(月) 19:41:07 ]
>>478
>極端な話、マスタ登録はストアド側でマスタ更新はプログラム側ってこともありうるのよ。
>同じレイヤーのロジックをストアドで組んだりプログラムで組んだりっていうのは
>アーキテクチャとして正しい姿なのか?っていうのは疑問。

そういう美しさを追求したいのなら、システムを設計する際に
アクセス権を含めてかなりカッキリと設計しておけ、って気がするが。

マスタ更新系に関してはストアドを作成し、そのオブジェクトに管理者のOWNER
権限がないとINSERTできない。とかな。

逆に参照はすべてDBAが用意したビューのみしか利用できないとかか。
素人プログラマにビュー作られてパフォーマンスが出ないとか言うなら
餅は餅屋な感じでプロのDBAのテーブル設計してもらって最適な
KEY,INDEX,VIEW,制約をやってもらう。

498 名前:仕様書無しさん mailto:sage [2007/03/05(月) 21:28:16 ]
>>496

当然元表のINDEXは、使われているが
話にならんぐらい遅いよ。


499 名前:仕様書無しさん mailto:sage [2007/03/05(月) 21:31:19 ]
こういう
ttp://www.geocities.jp/mickindex/database/db_view.html
ページもあるから、Viewは、遅いって言うのも一般的な話だと思う。

500 名前:仕様書無しさん mailto:sage [2007/03/05(月) 21:48:46 ]
>>498
VIEWでなく、普通にSELECTした方が速いのかい?



501 名前:仕様書無しさん mailto:sage [2007/03/05(月) 21:52:21 ]
>>500
絞込み順番で速度が変わるのでViewだと遅くなることが多い。

502 名前:仕様書無しさん mailto:sage [2007/03/05(月) 22:07:54 ]
DB2でJDBC経由で使う分にはVIEWとSELECTとの違いは体感しないけどなー。

マイクロソフトのOSからODBC経由でSQL投げると不思議と遅くなる事が
あるけど、なんなんだろうな。
SQLServer買えtって嫌がらせなんだろうか?って思う事がある。

まあ漏れはSELECTかMQTのどっちかの人だけど。

503 名前:仕様書無しさん mailto:sage [2007/03/05(月) 22:08:52 ]
>>500

インデックスが張ってあるカラムで検索するなら、
圧倒的に実表を使ったほうが早い。

504 名前:仕様書無しさん mailto:sage [2007/03/05(月) 22:12:28 ]
ところで具体的にVIEW使うと遅くなるRDBってナニ?
>>502と同様にDB2だと、テーブルでも、ビューでもマテリアライズでも
どれも同じ速度で結果が返ってくるけど。

505 名前:仕様書無しさん mailto:sage [2007/03/05(月) 22:15:44 ]
>>504

Oracleだよ。

>DB2だと、テーブルでも、ビューでもマテリアライズでも
>どれも同じ速度で結果が返ってくるけど。

ソース希望。


506 名前:仕様書無しさん mailto:sage [2007/03/05(月) 22:22:20 ]
>>505
ソースもなにもやって見れば解る。

適当なテーブルにビューを作成して、ついでにマテリアライズしておくと、
実テーブルとビューでマテリアライズな結果を帰ってくるような設定にしていおけば、
DB2のオプティマイザがマテリアライズの結果を返すので、
どのオブジェクトを参照しても9msくらいの早さで結果が返ってくる。

さすがは商用DBといったトコか。

Oracleに向かってこういう事いうと反論が山ほど返ってくるだろうけど、
Oracleは使う側がOracleを熟知していないとパフォーマンスでないよな。

507 名前:仕様書無しさん mailto:sage [2007/03/05(月) 22:24:27 ]
ハードコードしてそうな人が多そうだから、そっちに話を戻そうか

508 名前:仕様書無しさん mailto:sage [2007/03/05(月) 22:49:33 ]
ま、ストアド作ってもそいつを呼び出すもんはどうするのかってこともあるしね。

509 名前:仕様書無しさん mailto:sage [2007/03/05(月) 22:55:53 ]
Oracleのせいにしたいやつがいるな。


510 名前:仕様書無しさん mailto:sage [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 名前:仕様書無しさん mailto:sage [2007/03/05(月) 23:08:04 ]
>>510
動的生成するにはハードコードだわな。

513 名前:仕様書無しさん mailto:sage [2007/03/05(月) 23:08:22 ]
|| '-' ||

新しい顔文字かと思った

514 名前:仕様書無しさん mailto:sage [2007/03/05(月) 23:19:02 ]
|| '-' ||
(。Y。)

515 名前:仕様書無しさん mailto:sage [2007/03/05(月) 23:20:58 ]
>>514
女神様じゃ〜

516 名前:仕様書無しさん mailto:sage [2007/03/05(月) 23:34:48 ]
|| '-' ||
(。Y。)ノ
  肉

517 名前:仕様書無しさん mailto:sage [2007/03/06(火) 07:57:35 ]
>>506
それ偶然だから。

518 名前:仕様書無しさん [2007/03/06(火) 09:05:33 ]
ハードコーディングの定義って何?

where句の条件が動的に変化して
それ以外のselect句が固定であったとき、
where句以外をソースに書いておくのがハードコーディング?

519 名前:仕様書無しさん mailto:sage [2007/03/06(火) 09:53:21 ]
>>518
ソースコードの中にSQLを直書きすること。


520 名前:仕様書無しさん [2007/03/06(火) 12:31:53 ]
それの何が問題なの?



521 名前:仕様書無しさん mailto:sage [2007/03/06(火) 12:58:47 ]
常に同一のSQLなら生SQLでいいけど、そうでもないのに
プレースホルダも使わずに
"select * from hoge where " + condition + ";"
なんて書いてるこわーいコードが世の中には溢れかえっている。



522 名前:仕様書無しさん mailto:sage [2007/03/06(火) 12:59:04 ]
変更の度にコンパイル

523 名前:仕様書無しさん mailto:sage [2007/03/06(火) 13:42:09 ]
>>521

ハードコーディング以前の問題。

>>522

今時、コンパイルに何時間もかかるわけじゃなし。
問題無いと思うが。

524 名前:仕様書無しさん mailto:sage [2007/03/06(火) 17:39:02 ]
数値のリテラルよりマシ。

525 名前:仕様書無しさん mailto:sage [2007/03/06(火) 21:31:10 ]
>>521見て思ったんだが、上の方で出てるHibernateとかはこの問題は発生しないの?
使ったことないんでよくわからん

526 名前:仕様書無しさん mailto:sage [2007/03/06(火) 21:35:37 ]
>>525
Hibernate関係ねー。よっぽど使い方まちがえたらSQLインジェクション発生する。

527 名前:仕様書無しさん mailto:sage [2007/03/06(火) 22:39:42 ]
>>526
やっぱりそうだよね。ありがとう。

528 名前:仕様書無しさん mailto:sage [2007/03/22(木) 21:09:04 ]
保守


529 名前:仕様書無しさん [2007/03/30(金) 21:52:17 ]
保守

530 名前:仕様書無しさん mailto:sage [2007/03/31(土) 00:10:44 ]
>>524
同じ意味のconstが複数あった時にゃ、リテラルの方がマシと思った



531 名前:仕様書無しさん [2007/04/02(月) 22:12:30 ]
プリペアドステートメントってどうよ

532 名前:仕様書無しさん mailto:age [2007/04/03(火) 12:45:58 ]
O/Rマッパーでも使えというのか?
SQLを書いた方が早い場合もあるんじゃないか?

533 名前:仕様書無しさん mailto:sage [2007/04/03(火) 13:07:08 ]
オラクルはわからんけどSAP R/3は内部でSQLをハードコーディング
してるのをよく見かけるぞ。

534 名前:仕様書無しさん [2007/04/03(火) 16:07:16 ]
SAPだったら別に良いんじゃないかという希ガス

535 名前:仕様書無しさん mailto:sage [2007/06/11(月) 20:42:07 ]
>>1
SQLインジェクションとかそういうことを危惧しての発言なのか、それとも単にリテラル文字列が気に入らないだけ?
後者ならお前はただのアホとしか言いようが無いぞ。

536 名前:仕様書無しさん [2007/06/11(月) 20:43:22 ]
あーハードコーディングとか言ってるから後者だな。
1は馬鹿丸出し。

537 名前:69式フリーPG ◆hND3Lufios mailto:sage [2007/06/11(月) 20:50:53 ]
プレースホルダを埋めた形でハードコーディングしてますが。

設定ファイルとかに外出ししてもさ、コンパイルせずに済むのってORDER BYとか
だけじゃん?

538 名前:仕様書無しさん mailto:sage [2007/06/11(月) 21:01:46 ]
Java界では保守性があがると言うもっぱらの噂ですよ。馬鹿っぽい気もするけどさ。

539 名前:仕様書無しさん mailto:sage [2007/06/11(月) 21:07:25 ]
コードとSQL文の距離が離れることで、可読性が落ち保守性が落ちる。

540 名前:仕様書無しさん mailto:sage [2007/06/11(月) 22:19:02 ]
S2Dao最強でOK



541 名前:仕様書無しさん mailto:sage [2007/06/17(日) 16:09:59 ]
ハードコーディングしたほうがSQLインジェクションには強い

542 名前:仕様書無しさん mailto:sage [2007/06/17(日) 17:38:27 ]
じゃあS2Dao Tigerでいいや

543 名前:仕様書無しさん mailto:sage [2007/06/20(水) 22:09:17 ]
>>541
検索条件を変えられないなら、ハードコーディングしようがしまいが
SQLインジェクションには無敵

544 名前:仕様書無しさん mailto:sage [2007/06/20(水) 23:43:29 ]
それは、ともかくSQLExceptionの変数をsexにしてるソースがあってさ
なんか、楽しいから、やめてほしいなぁと思うわけよ。

545 名前:仕様書無しさん mailto:sage [2007/06/20(水) 23:49:22 ]
ワラタ

546 名前:仕様書無しさん [2007/06/22(金) 22:57:10 ]
SQLインジェクション云々いってるやつって何なの?
それに対策立てた上での議論だろ?

547 名前:仕様書無しさん mailto:sage [2007/06/22(金) 23:09:47 ]
VBのソースって半分以上がSQLだよね

548 名前:仕様書無しさん mailto:sage [2007/06/22(金) 23:23:11 ]
XP的にはハードコーディングだな
困ってから作り直せばいいだろ。どうせ困る前に納期だ。

549 名前:仕様書無しさん mailto:sage [2007/06/22(金) 23:25:11 ]
ハードコーディングじゃない方法ってどんなの?

550 名前:仕様書無しさん mailto:sage [2007/06/23(土) 00:03:22 ]
XPなら重複コード禁止だろ
重複コード無しでSQLハードコーディングは無理だな。不可能。



551 名前:仕様書無しさん mailto:sage [2007/06/23(土) 00:07:08 ]
"SELECT *" を使いまくればSQLなんて楽勝!

552 名前:仕様書無しさん mailto:sage [2007/06/23(土) 00:14:16 ]
コボラ乙

553 名前:仕様書無しさん mailto:sage [2007/06/23(土) 00:17:48 ]
>>550

何処が重複になるのか詳しく説明プリーズ

554 名前:仕様書無しさん mailto:sage [2007/06/23(土) 00:41:05 ]
柔軟性がどうこう言うヤツに限って再利用可能なものをつくらないよなw


555 名前:仕様書無しさん [2007/06/24(日) 12:54:09 ]
SQLはハードコーディングでいい。
外出しにしても再利用などできない。

いやならO/Rマッピング使う。

556 名前:仕様書無しさん mailto:sage [2007/06/24(日) 13:29:24 ]
O/Rマッピングで美しく解決できるのなんて
チューニングの不要なやり逃げ案件だけ

557 名前:仕様書無しさん mailto:sage [2007/06/24(日) 14:36:13 ]
Webアプリの糞つまんねーCRUD部分にだけ適用するのが正解。

558 名前:仕様書無しさん mailto:sage [2007/10/04(木) 20:25:35 ]
hhddf






jfghhgh






tyyrtr






werwerwer





utuytu




559 名前:仕様書無しさん mailto:sage [2007/11/15(木) 01:49:11 ]
SQL が変わる時ってロジックも変わってることが多いんで、
SQL だけ外に出しても意味なくない?
SQL を自動生成してるんなら別だけど。


560 名前:仕様書無しさん mailto:sage [2007/11/16(金) 00:49:22 ]
>>559
それどころか予期せぬ障害を引き起こしたりもする.
ウチのアホSEがSQLを変更するのは設定ファイル変更で,
プログラムの変更は入りませんから,再テストの必要は無いですね,
って言って見事にバグらせたことがある.
っつーか事前検証くらいしろよっていう話なんだけどさ.



561 名前:仕様書無しさん mailto:sage [2007/11/16(金) 23:19:41 ]
htmlをロジックと分離するのは、それがデザインであるという以外に
定数として埋め込む手間とかいろいろあるんだよな。
SQLだと後者のメリットしかないんだけど、俺は外出しがいい。

>>559
Where句だけ変わる事って結構あると思うけど。
特に集計するときとか。

自動生成はまた別の問題を抱えていて、条件によって構文すら異なる。
レアケースでだけ構文エラーを起こしたり、解釈が変わってしまうのがいやになったよ。
まるで、Cのマクロで意図しない式に展開されてるときと同じ感覚。

>>560
それはリファクタリングがなってないだけだよな。
変更前後のSQLを差し引きしたら、どこが違うかなんて一発でわかるのに。


562 名前:仕様書無しさん mailto:sage [2007/12/07(金) 22:17:12 ]
>>561
何が言いたいのか全くわからん

563 名前:仕様書無しさん mailto:sage [2007/12/18(火) 22:31:47 ]
半端な気持ちで外出しするとメンテではまる。
どのプログラムから
どのタイミングでどのテーブルのどのフィールドを
どのSQLを使って参照・更新するのかが、チームで共有されていて
ちゃんと管理されていて、調べやすければメリットがあるけど、
ずさんな場合は依存関係を調べるのに結局ソースにあたるハメに陥り
その上、間接的に読まれるせいでソースをGREPしづらいし、数倍面倒になる。

564 名前:仕様書無しさん mailto:sage [2007/12/19(水) 01:49:10 ]
せっかく分けたのにちょっとした修正時に結局両方直さなければならないのは悲しい事だ

565 名前:仕様書無しさん [2007/12/19(水) 06:52:44 ]
563とか564のスレを読む限り、外出しの推進派と反対派では外出しの方法が違うのでは?と勘ぐってしまう。
564の意見とか的外れもいいとこ。

566 名前:仕様書無しさん [2007/12/19(水) 07:11:14 ]
重複、ここでやれ。
pc11.2ch.net/test/read.cgi/prog/1180118552/l50

567 名前:仕様書無しさん [2007/12/19(水) 09:46:47 ]
>>565
そう勘ぐったのなら、具体的にどう違うと思ったのか指摘すればいいのに。

568 名前:仕様書無しさん mailto:sage [2007/12/19(水) 19:46:57 ]
スレとレスも間違えてるしな

569 名前:葉猫 ◆Jz.SaKuRaM mailto:sage [2007/12/20(木) 21:54:00 ]
1000行レベルのストアドをソースに埋め込む気にはならんな ('A`)マンドクセー

570 名前:仕様書無しさん mailto:sage [2007/12/20(木) 22:31:40 ]
何言ってんだオメー
さっさと氏ねよ



571 名前:仕様書無しさん [2007/12/22(土) 03:15:40 ]
結局、ソースファイルと外出しsqlの両方とも修正しなくといけなくなるだけ。

572 名前:仕様書無しさん [2007/12/22(土) 03:17:33 ]
マ板のスキル低下は著しいなwwwwwww

573 名前:仕様書無しさん [2007/12/22(土) 13:17:03 ]
java向けのスレなのにC++とかのプログラマが来て些細なテクニック論に
なってるなこのスレ

574 名前:仕様書無しさん mailto:sage [2007/12/22(土) 13:43:16 ]
そんな前提>1に書いてないので認めないクマー

575 名前:仕様書無しさん mailto:sage [2007/12/22(土) 16:00:08 ]
>>283
ちょwwそれうちの病院www
クエリはないけど、リンクテーブルだらけのmdbファイルあったわ。
でも処理はVBじゃないっぽい。

独自にデータ集計したりするときに俺もそこからインポートしてるけど。

576 名前:仕様書無しさん [2007/12/22(土) 19:05:06 ]
>>573
++マが全部こんなのだって訳じゃないんだぞといっておく

577 名前:仕様書無しさん mailto:sage [2007/12/22(土) 19:49:43 ]
スレの最初のほうを読んで、それ以降はチラ見してただけだから、Javaスレになってたなんて気ずかなかったよ。

578 名前:仕様書無しさん mailto:sage [2007/12/22(土) 20:07:09 ]


579 名前:仕様書無しさん [2007/12/22(土) 22:09:20 ]
SELECT文とかを変数につっこんでExecuteとかマジやめて欲しいんだけど。
特にWebアプリの場合ね。
ストアドを作ってそれを呼ぶだけにするのば一般的だと思ってたんだけど
そうでもないの?
そういえばカカクコムとか昔攻撃されてたね。

580 名前:仕様書無しさん mailto:sage [2007/12/22(土) 22:15:40 ]
>>579
DB側に処理をおくのは・・・って考え方もあるよ
インジェクション対応して無いなんてのはどうやっても問題外



581 名前:仕様書無しさん mailto:sage [2007/12/22(土) 23:07:37 ]
hibernateってヒントつけられないから馬鹿だよね。
使い物にならん。

582 名前:仕様書無しさん mailto:sage [2007/12/22(土) 23:11:39 ]
> するのば
     ↑
あまり一般的じゃないと思う

583 名前:仕様書無しさん mailto:sage [2007/12/23(日) 00:21:49 ]
Webの開発だったら普通はストアドプロシージャを実行するよ。
LINQなんて論外。

584 名前:仕様書無しさん mailto:sage [2007/12/23(日) 00:26:17 ]
>>583
ストアドはないだろ・・・

585 名前:仕様書無しさん mailto:sage [2007/12/23(日) 00:35:25 ]
>>584
PROCEDUREというやつの事です。
Accessだとクエリだっけ?

586 名前:仕様書無しさん mailto:sage [2007/12/23(日) 00:37:30 ]
SQLをハードコーディングする人って多いのね。

587 名前:仕様書無しさん mailto:sage [2007/12/23(日) 00:49:31 ]
インジェクション対策ならプリペアードクエリでいいだろ

588 名前:仕様書無しさん [2007/12/23(日) 00:55:00 ]
DBへの処理はDB側で行うのかプログラムに書いちゃうかはプロジェクトによって分かれるね。
今のプロジェクトはDBへの処理は必ずストアドを使うように言われてる。
そもそもプログラムを実行するユーザーにはストアドのGRANT権限しか付与してくんない。
まあどっちでも良いや。

589 名前:仕様書無しさん mailto:sage [2007/12/23(日) 00:58:24 ]
DB側に処理もって行ったら不可分散しにくいじゃん

590 名前:葉猫 ◆Jz.SaKuRaM mailto:sage [2007/12/23(日) 09:48:57 ]
一時テーブルを使えないとスピードが遅くなるからDB側でちょ (`・ω・´) シャキーン



591 名前:仕様書無しさん mailto:sage [2007/12/23(日) 11:10:09 ]
お前マジキメェ
さっさと失せろ

592 名前:仕様書無しさん mailto:sage [2007/12/23(日) 17:58:23 ]
どう書くのが推奨なの?
SQL生成用の関数作ってパラメータ放り込むぐらいしか考えつかん


593 名前:仕様書無しさん mailto:sage [2007/12/23(日) 18:07:02 ]
ORマッパ

594 名前:仕様書無しさん mailto:sage [2007/12/23(日) 22:04:21 ]
今時一次テーブルとかスキル無いコテってなんなの?

595 名前:仕様書無しさん mailto:sage [2007/12/23(日) 22:49:36 ]
以前も自らのアホっぷりを晒したレスを論破されて逃走
挙句の果てに火病って糞スレ立てるほどのアホの子ですから

596 名前:仕様書無しさん [2007/12/25(火) 00:23:35 ]
なんでも*つければ
良いってもんじゃねーぞ。

597 名前:仕様書無しさん mailto:sage [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 名前:仕様書無しさん mailto:sage [2007/12/25(火) 02:20:05 ]
GRANT権限ってなんだ

599 名前:仕様書無しさん mailto:sage [2007/12/25(火) 06:22:04 ]
>>598
GRANT文を実行できる権限じゃね?


600 名前:仕様書無しさん mailto:sage [2007/12/25(火) 11:01:49 ]
>>597
名前で検索って、それじゃIDの意味ねーよw
↑どうでもいいことを言ってみる。



601 名前:仕様書無しさん mailto:sage [2007/12/25(火) 23:06:57 ]
>>597
WHEREを画面の入力によって組み立てたりすると
途端に破綻するんだろ?

602 名前:仕様書無しさん mailto:sage [2007/12/26(水) 00:48:48 ]
>>599
中間管理職か...

603 名前:仕様書無しさん mailto:sage [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 名前:仕様書無しさん mailto:sage [2007/12/26(水) 07:04:29 ]
インジェクションされまくるじゃないか、とかは別にして、
結局ハードコーディングした方がいいじゃん、つ流れになりそうな話だなぁ

605 名前:仕様書無しさん mailto:sage [2007/12/26(水) 07:21:19 ]
バカどもがどうしようと構わんが、マ板の質落ちたねぇ・・・

606 名前:仕様書無しさん [2007/12/26(水) 21:49:21 ]
>>605
どうしたら上質だんだよ。

607 名前:仕様書無しさん mailto:sage [2007/12/26(水) 23:16:54 ]
んだんだ

608 名前:仕様書無しさん mailto:sage [2007/12/26(水) 23:35:51 ]
>>606
やっぱブラック、いろんな意味で。


609 名前:仕様書無しさん mailto:sage [2007/12/27(木) 00:15:23 ]
>>603
SQL実行する前に値チェックをプログラムでやればいいだろ

610 名前:仕様書無しさん [2007/12/27(木) 18:18:24 ]
INSERTする前には必ずSELECTして重複チェックしてください。



611 名前:仕様書無しさん mailto:sage [2007/12/27(木) 18:22:31 ]
>>610
それはあまりに間抜けな仕様。

論理的な重複排除はPKかUNIQUE INDEXの一意制約違反で
INSERT時のSQL実行エラーを戻してもらえればいい。
あとはアプリケーションでエラー処理をきちんと実装する。


612 名前:仕様書無しさん mailto:sage [2007/12/27(木) 19:18:27 ]
>>610
SELECTとINSERTの間に他のセッションからINSERTされちゃうことってないの?

613 名前:仕様書無しさん mailto:sage [2007/12/27(木) 19:40:31 ]
>>611
俺らがSELECTされない間に、あいつはINSERTされてるんだよ、畜生。

614 名前:仕様書無しさん mailto:sage [2007/12/27(木) 21:00:42 ]
>>613
俺なんかSELECTされる事が無いまま、そっけなくDELETEされるんだぜ。

615 名前:仕様書無しさん mailto:sage [2007/12/28(金) 00:36:29 ]
>>614
お前は一度でもINSERTしたのか!

616 名前:仕様書無しさん mailto:sage [2007/12/28(金) 10:25:30 ]
ハードコーディングってなんぞ?
JDBCは組込みSQLはハードコーディングに入ってんのか?

617 名前:仕様書無しさん mailto:sage [2007/12/28(金) 12:01:41 ]
SQLを外に出してる奴は、他の言語内言語である正規表現とかも外に出してるのか?

618 名前:仕様書無しさん [2007/12/28(金) 12:03:43 ]
spring framework位使いこなしなよ。おじいさん^^

619 名前:仕様書無しさん mailto:sage [2007/12/28(金) 12:07:49 ]
中出しはらめぇ

620 名前:仕様書無しさん mailto:sage [2007/12/29(土) 06:26:03 ]
springとSQLのハードコーディングは、何の関係も無いと思うが・・・



621 名前:仕様書無しさん [2007/12/29(土) 17:04:29 ]
ハードコーディング自体は悪くないが、
複数のメソッドで部分部分SQL文字列組み立てるのは勘弁してくれ。

622 名前:仕様書無しさん [2007/12/30(日) 12:55:40 ]
昔バカスイーツSE女がいて
ソースが汚いとすぐハードコーディングハードコーディング言ってうるさかった

623 名前:仕様書無しさん mailto:sage [2007/12/30(日) 13:39:39 ]
>>617
SQLと正規表現だと別もんだと思うんだが・・・
正規表現エンジン変えられるようにしてたりしたら外に出すなぁ

624 名前:仕様書無しさん mailto:sage [2007/12/30(日) 20:34:26 ]
ハードコーディング肯定してる奴らってIDE使ってないんじゃないかって気はする


625 名前:仕様書無しさん mailto:sage [2007/12/30(日) 21:55:06 ]
何言ってんだ?

626 名前:仕様書無しさん [2007/12/31(月) 06:18:06 ]
>>610くらいからの流れにクソワロタ

627 名前:仕様書無しさん mailto:sage [2007/12/31(月) 11:01:55 ]
>>623
RDBMS変わりうること前提にした外出しなの?

変わることなんかそうそう無いと思うんだが

628 名前:仕様書無しさん mailto:sage [2007/12/31(月) 12:25:29 ]
ハードコーディング=静的SQL
それ以外=動的SQL
ってこと?

なら静的に書いたほうがオーバーヘッドがない分性能はいいよ

629 名前:仕様書無しさん mailto:sage [2007/12/31(月) 12:26:48 ]
>>628
静的・動的ってどういう意味で使ってる?

俺はORMを使うかどうかという意味だと思っていたのだが。


630 名前:仕様書無しさん mailto:sage [2007/12/31(月) 12:31:14 ]
どういう意味???
静的=コンパイラにSQLのロジックを展開させてLMでは最終的なDBアクセスのロジックは固定
動的=SQLが内部的に変わるのでSQL翻訳後にDBアクセスするのでの余計なオーバーヘッドがかかる

こんな感じ?




631 名前:仕様書無しさん mailto:sage [2007/12/31(月) 12:36:48 ]

ここマ板か
失礼、DB板と勘違いした


632 名前:仕様書無しさん mailto:sage [2007/12/31(月) 13:20:31 ]
O/Rマッパは汎用的なのは良いが
オプティマイザの実行計画が
実は大変なことになってることが多いのが悲しいな。

633 名前:仕様書無しさん mailto:sage [2007/12/31(月) 13:33:38 ]
>>627
正規表現の場合の話がしたいの?SQLの場合の話がしたいの?
SQLと正規表現は別もんって書いてあるよね?

634 名前:仕様書無しさん mailto:sage [2007/12/31(月) 13:35:45 ]
>>632
裏で色々あったんだろうがDBMagazineのTopLinkは奇麗だったな・・・

635 名前:仕様書無しさん mailto:sage [2008/01/01(火) 20:57:02 ]
>>630
SQLの場合はこんな感じかな。DB2限定だが。
静的:実行計画を事前に取得しておく。
動的:実行時に実行計画を取得する。

ORACLEって静的バインド出来ないよね?


636 名前:仕様書無しさん [2008/01/04(金) 16:45:58 ]
1 が言いたいのはたぶん、
同一のテーブルを参照するSQLを
いたるところに書くことに辟易
してるってことを言いたいんだと思う

637 名前:仕様書無しさん mailto:sage [2008/01/04(金) 21:56:46 ]
それは、ハードコーディングだろうが、
外部ファイルに書こうが一緒だ。

638 名前:仕様書無しさん mailto:sage [2008/01/04(金) 22:25:27 ]
レスも空気も読まずにageレスか・・・さすが冬

639 名前:仕様書無しさん [2008/01/05(土) 01:24:58 ]
1が言いたいことはたぶん
プログラム内でSQL文を組み立てて発行することを言ってるんだと思う。
前にVBプログラマが作ったソースを見たら
sql = "SELECT * FROM テーブル"
conn.exec(sql)
みたいなコーディングだったんだけど、こういうのがハードコーディング?
DBにプロシージャとかを作成してアプリ側はそれを呼ぶだけにして欲しいってことじゃないの?

自分は小さい規模(ユーザー数1000人前後)のシステムしか作ったことがないので
普通にDBにプロシージャを作って、C#でDBに接続してプロシージャを実行とかやってる。
上のレスを見たら分散処理のためにハードコーディングするとかあったけど
よく意味がわからなかった(^^;
ヤフーとか2chのようにもの凄い大量のアクセスがあるシステムでは
分散処理とか考えてコーディングしないとヤバイのかな?
もっと勉強しなきゃだな。
うちはWebサーバ1台とDBサーバ1台だけでやってて特に問題無い程度のアクセス数だけど
複数台のサーバで処理を分散とかの勉強もしなきゃなぁ。

640 名前:仕様書無しさん mailto:sage [2008/01/05(土) 02:01:43 ]
>>639
半年ROMれ



641 名前:仕様書無しさん mailto:sage [2008/01/05(土) 02:25:38 ]
>639
あー半年と言わず三年ROMれ

642 名前:仕様書無しさん mailto:sage [2008/01/06(日) 10:32:28 ]
ここの住人って常駐派遣が多そうだな。

643 名前:仕様書無しさん mailto:sage [2008/01/06(日) 11:04:37 ]
客先常駐の請負仕事なだけで派遣じゃないよw

644 名前:仕様書無しさん mailto:sage [2008/01/06(日) 18:46:56 ]
偽装派遣のにおいがするんだが・・・

645 名前:仕様書無しさん mailto:sage [2008/01/06(日) 18:49:37 ]
てゆうかマジで客先常駐なんてありえないよね。
ぶっちゃけ惨めじゃん。
自分の会社じゃないところに行ってさ。
うちにもちっさい会社のエンジニアが沢山常駐してるけどかわいそうだよ。
会社によるだろうけど派遣社員にはネットやメールを使わせないとか
そういうルールもあるし。

646 名前:仕様書無しさん mailto:sage [2008/01/06(日) 23:11:03 ]
常駐させてるのも、そういうルールを作ったのも
お前の会社なんだろ。

647 名前:仕様書無しさん mailto:sage [2008/01/07(月) 22:04:27 ]
思い付きだけで書かれたものを残されるとツライと思う。
でも、OJTだけで教育しようとしてるウチじゃあ無くならないんだろうな。

648 名前:仕様書無しさん mailto:sage [2008/01/08(火) 10:58:26 ]
>>647
詳細設計完了後に思いつきで
仕様変更を連絡して来なきゃ、
そのケースはかなり減ると思うwww

649 名前:仕様書無しさん [2008/01/08(火) 22:05:35 ]
先輩方!お手本ソースを教えて教えて!

650 名前:仕様書無しさん mailto:sage [2008/01/13(日) 22:06:25 ]
M + ijime = Mijime = みじめ = 惨め

いじめられても笑顔で居られる客先常駐って惨めだよね



651 名前:仕様書無しさん mailto:sage [2008/02/06(水) 01:24:00 ]
まだあったのなー。
最近、自宅で趣味でJavaのWEBシステム構築やってんだけど、
ハードコーディングが楽だわ。

SQLインジェクションはバインド変数で解決、
不要なカラムは取得せずSQLもすっきり、I/Oもすっきり。

なんで>>1はハードコーディング嫌ってんの?作業振りしやすいから?
プログラマにDB周りをある程度把握させとかないと問題あったとき、危険だと思うけど。
どっちにしろO/Rマッピングは1から10まで全部一人でやっちゃうプログラマにはあんま美味しくないよ

652 名前:仕様書無しさん mailto:sage [2008/02/06(水) 14:56:30 ]
>>651
あとO/Rマッパはチューニングしにくい罠

653 名前:仕様書無しさん [2008/02/24(日) 17:40:04 ]
ハードコーディングってそもそも何?

654 名前:仕様書無しさん mailto:sage [2008/02/24(日) 18:11:09 ]
俺はiBATISくらいの薄い方が好きだ

655 名前:仕様書無しさん [2008/02/24(日) 19:15:37 ]
SpringJDBCがよい

656 名前:仕様書無しさん [2008/02/24(日) 19:23:02 ]
bbs.cgiboy.com/Guestbook/BBS/07232290/
荒らしならここをつぶすのがいい

へいさにおいこめくずども

657 名前:仕様書無しさん mailto:sage [2008/03/02(日) 22:49:26 ]
SQLをDBに持つとか別テキストに持つだとか構造をXMLにしてもっておくだとか
いろいろなプロジェクトがあったが、結局はSQLを直すときはソースも直す場合が多いよね。
そうなると分けるとよけい保守性が悪くなるよね。

658 名前:仕様書無しさん mailto:sage [2008/03/03(月) 00:31:54 ]
修正の規模による

659 名前:仕様書無しさん [2008/03/03(月) 22:31:21 ]
項目A(3バイト)、項目B(6バイト)

(更新前)
AAA,BBBCCC
AAA,BBXCCC
AAA,BBPCCC

(更新後) ← このようにしたいです。
AAA,BBZCCC
AAA,BBZCCC
AAA,BBZCCC

目的は、項目Bの頭3バイトだけを”BB*”で条件に指定して、
項目Bの頭3バイトを全て”BBZ”に更新したい場合どうすればよいのでしょうか?
項目Bの後3バイトの”CCC”はそのまま残さなくてはいけないため、
どのようなSQL文にすれば良いのかわかりません。

どうしても後3バイトを生かしたままの更新なので。。。。困ってしまします。

お知恵をお貸しください。

660 名前:仕様書無しさん mailto:sage [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
本当にありがとうございます!!
さっそく明日実行してみます。!!
「現場で使えるSQL」って本読んでもうまくSQL文思いつかなくて。。。
本当にありがとうございます!!

662 名前:仕様書無しさん mailto:sage [2008/03/03(月) 23:05:55 ]
設計が悪いようにしか思えん。


663 名前:仕様書無しさん mailto:sage [2008/03/04(火) 00:38:36 ]
これ酷いな

664 名前:仕様書無しさん mailto:sage [2008/03/04(火) 13:13:52 ]
ハードコーディング最強

665 名前:仕様書無しさん mailto:sage [2008/03/04(火) 17:31:29 ]
S2DAOでいいや

666 名前:仕様書無しさん mailto:sage [2008/03/04(火) 22:17:23 ]
>>659 コボラーのにおいがする

667 名前:仕様書無しさん [2008/03/05(水) 00:34:15 ]
ストアドは使わないの?
コンパイル時間がかからないから初回がやたら遅いSQLにいいじゃん。

668 名前:仕様書無しさん mailto:sage [2008/03/05(水) 01:17:28 ]
DBにSQL文いれときゃいいじゃん

669 名前:仕様書無しさん mailto:sage [2008/03/06(木) 09:35:17 ]
>>668
それを取得するSQLはどうするんだ?

670 名前:仕様書無しさん mailto:sage [2008/03/07(金) 00:50:45 ]
Dim SQL As String
SQL=DLookup("SQL","M_SQL管理テーブル","id=xxx")




671 名前:仕様書無しさん mailto:sage [2008/03/07(金) 02:30:25 ]
Accessはポイだポイ。

672 名前:仕様書無しさん mailto:sage [2008/03/11(火) 06:32:38 ]
>>670
Aceess かどうかはともかく、SQL 文を id(多分 数値型のつもりでしょ) で管理するってのは、
関数やら手続きを連番で管理するのと同じにおいがする。
id='xxxマスタ取得' とか id='xxx一覧取得' とかなら、数値管理よりはましかな。



673 名前:仕様書無しさん [2008/03/14(金) 01:36:48 ]
>>672
これやった事ある。
SQLを修正するときは探すのも面倒なので新規にテーブルに
放り込んでたw
ソース側はid変えるだけ。
思ったよりも混乱は生じなかったよ。
DBに2回アクセスするのが欠点だけどw




674 名前:仕様書無しさん mailto:sage [2008/03/14(金) 02:29:54 ]
SQLを別の場所に置いたとして、SQL修正後のテストのために
どのプログラムから、そのSQLが使われてるかとか常に管理してんの?
それとも複数のプログラムからはSQLを共有しない?

675 名前:仕様書無しさん [2008/03/14(金) 02:44:42 ]
>>674
>それとも複数のプログラムからはSQLを共有しない?
その通りまったく同じSQLがたくさんはいっている。
ソース内で同じIDのSQLを呼び出さないルール
ソース側との整合性だけとれてればいいので管理しない。
テスト時に帰ってきたSQLが正しいかだけチェックしてる。
ぶっちゃけると中国人プログラマが勝手にこのルールに
してしまったので皆つきあわされたww


676 名前:仕様書無しさん mailto:sage [2008/03/14(金) 07:59:11 ]
SQLを動的に作る自作API使ってる。1500行。
メリットはどんなSQL DBにも対応可能。
汎用性/柔軟性が高い。開発効率が良い。

デメリットはストアドとかが使えない。

677 名前:仕様書無しさん mailto:sage [2008/03/14(金) 20:24:52 ]
それならS2JDBCでも使えよ。
まぁ、Javaじゃないかもしれんが

678 名前:仕様書無しさん [2008/03/14(金) 22:28:20 ]
SQLを外出しにして管理しても再利用できる汎用的なSQLは
せいぜい全体の2・3割程度で、ほとんどは1箇所でしか使われない。
単純で汎用的なSQLについてはOR-MAPした方が便利だが、
帳票出力、データ集計、条件が複雑に変化するな検索など
ビジネスロジックそのものと言えるSQLはオンコーディングか、
ストアドにしてしまった方がシンプルかと…


679 名前:仕様書無しさん [2008/03/14(金) 23:27:03 ]
おれもストアドだな

680 名前:仕様書無しさん mailto:sage [2008/03/15(土) 00:17:05 ]
ストアド使い出すと、増えすぎて見通しが悪くなるから好かん



681 名前:仕様書無しさん mailto:sage [2008/03/15(土) 00:40:08 ]
ストアドはうざいから俺も好かん

682 名前:仕様書無しさん mailto:sage [2008/03/15(土) 01:03:25 ]
異様に処理時間のかかるアホみたいなのを平気で組むヤツが居るんよな

683 名前:仕様書無しさん mailto:sage [2008/03/15(土) 01:08:04 ]
Oracleマニアみたいな人が作って残していった
バッチ処理で1万行のプロシージャと闘ったときは死ぬかと思った。
単純になるなら歓迎だけど、意地でもストアドみたいなポリシーはやめて欲しい。

684 名前:仕様書無しさん [2008/03/15(土) 12:26:23 ]
>>683
それはストアドにしたから複雑になったんじゃなくて、
SQL一発でできることを無駄にカーソルで処理するから複雑になってるのでは?

685 名前:仕様書無しさん mailto:sage [2008/03/15(土) 12:42:31 ]
>>683
1プロシージャに1万行なんて、そいつがキチガイなだけだろ


686 名前:仕様書無しさん mailto:sage [2008/03/15(土) 21:56:57 ]
「カーソル」が使われているストアドは、COBOLからの書き換え以外認めない。


687 名前:仕様書無しさん mailto:sage [2008/03/16(日) 23:46:20 ]
>686
それはまた極端なw

688 名前:仕様書無しさん [2008/03/22(土) 08:18:00 ]
人間中庸が肝心だ。

689 名前:仕様書無しさん mailto:sage [2008/03/22(土) 22:36:55 ]
PHPでSQLをハードコーディングしてあってびびった。
SQLは切り出せよ。
SQLインジェションされてサニタイズ漏れたら終わりだろがと。

言ったが今でも放置されたまま。

690 名前:仕様書無しさん mailto:sage [2008/03/22(土) 22:54:54 ]
>>689
ハードコードしてあっても
プレースホルダ使うだけでだいぶ変わるがな。

つか「インジェション」ってwww



691 名前:仕様書無しさん mailto:sage [2008/03/23(日) 01:07:26 ]
SQLをハードコーディングすることとSQLインジェクションの問題は直行しているから、>>689の指摘は的外れだったんじゃないかなぁ?

692 名前:仕様書無しさん mailto:sage [2008/03/23(日) 10:07:08 ]
>>691
直行?直交にしてもわからんしな。関係ないってコトじゃないのか。

693 名前:葉猫 ◆Jz.SaKuRaM mailto:sage [2008/03/23(日) 13:15:03 ]
ストアドにちておけば内部で文字列化ちてselectとかexecuteみたいなアホなことちないかぎり
問題ないちな (・∀・)

694 名前:仕様書無しさん [2008/03/23(日) 13:57:07 ]
ストアド簡単なのに作ろうとしない馬鹿が多すぎてこまる。
提案してもメンテできない・わからないで握りつぶされる。
結果ハードコーティングでバグおこしてデスマ。
あほSEは早く欝になって首つってくれ!!!!!

695 名前:仕様書無しさん mailto:sage [2008/03/23(日) 14:08:35 ]
>>694
> 提案してもメンテできない・わからないで握りつぶされる。

ありがちだが、その連中の言い分も分からなくはない。


696 名前:仕様書無しさん mailto:sage [2008/03/23(日) 14:45:01 ]
>>694
ストアドは扱いが難しい。

テーブル設計が完了した段階でデータベースの構造をフリーズして
後はデータの出し入れだけにしたいという方針が普通の感覚だと思うんだが、
プログラムと同じ感覚でストアドを作ると、この方針と衝突する。

データの意味づけが拡張されてストアドの修正が必要になっても、まかりならんって
ことになったりする。
そういう時はしかたないので、プログラム側でストアドに相当するSQLを新しく
発行するようにして、ストアドは呼ばなくなる。

設計段階でストアドの要件もしっかり決めておけってのが正論なんだろうが。
間に合わせ的に使ってしまったりするな。

697 名前:仕様書無しさん mailto:sage [2008/03/23(日) 15:00:25 ]
俺がストアド嫌いな理由は、デバッガが使いにくいから。と
単純なSELECTやINSERTだったら、
ORマッピングツールのほうが良くて
混在すると鬱陶しいから、極力ORマッピングツールを使う。

提案してもメンテできない・わからないっていう、
SEはしんだほうがいいなと俺も思う。

698 名前:愛ちゃん mailto:sage [2008/03/23(日) 17:20:48 ]
ORマッピングとかORマッパってどういうものなんでしょうか?

699 名前:仕様書無しさん mailto:sage [2008/03/23(日) 17:31:52 ]
SQL書かなくてもRDBが使える魔法の箱さ!

700 名前:仕様書無しさん mailto:sage [2008/03/23(日) 17:41:55 ]
ストアドは自動テストに組み込み難いんだよな
デバッグも面倒だし



701 名前:仕様書無しさん mailto:sage [2008/03/23(日) 17:43:21 ]
制約が多すぎで使えねー、
検索系で組み込んだら遅くて使えねー、
マスタメンテ以外につかえねーの三拍子

意地でも使ってやるって人の背中にはデスマオーラが漂ってる

702 名前:仕様書無しさん mailto:sage [2008/03/23(日) 18:16:54 ]
派生開発案件で元が腐ってたとかならともかく、
ストアドなど書かずに済むようにDB設計するのが基本だと思う。

あと、「性能」を理由にすぐにストアドを使いたがるプログラマって
単に手続き的にしか物事を考えられない(まともなSQLの書き方を知らない)
人が多いような。

703 名前:仕様書無しさん mailto:sage [2008/03/23(日) 19:42:09 ]
バージョン管理とかはメンドクサくないの?

704 名前:仕様書無しさん mailto:sage [2008/03/23(日) 21:54:50 ]
ストアドはバージョン管理めんどくさい。
ストアドは、データベースやSQL Serverの外から呼び出すプログラミング環境が
貧しかった時代の亡霊だと思う。昔はストアドで何でもかんでもやってた。

705 名前:仕様書無しさん mailto:sage [2008/03/23(日) 23:37:49 ]
ORマッパについて解説しているサイトをご存じないですか?


706 名前:仕様書無しさん mailto:sage [2008/03/24(月) 00:38:02 ]
今までの意見をまとめると、RDBSは糞ってことで良いか?

707 名前:仕様書無しさん mailto:sage [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 名前:仕様書無しさん mailto:sage [2008/03/26(水) 22:50:37 ]
そりゃそうだ
最近SQLを満足にかけない奴がORまっぱとかほざいてるだけのような気がする

休日は自宅にヒキコモリ。
仕事じゃひとつの言語にヒキコモリ。
ヒキコモリ人生万歳ですか?



711 名前:仕様書無しさん mailto:sage [2008/03/26(水) 22:55:45 ]
>709
別に昔の話ではない。今も通じる。

権限は……面倒くせえからDBAでアクセスしちまえウハハハってのばかり見かけるが

712 名前:仕様書無しさん mailto:sage [2008/03/26(水) 22:56:22 ]
>710
前半と後半の乖離ぐあいにワラタ

713 名前:仕様書無しさん mailto:sage [2008/03/26(水) 23:30:39 ]
>>709
ストアドの方がパフォーマンスがよいって言うのは今でも正しいけど、
テーブル設計とSQLの筋さえよければ今は十分なパフォーマンスが稼げる。
だからクエリをDB側ではなくアプリ側に持っていく事によって得られる
開発パフォーマンスの向上が今は重視されている感じだな。

714 名前:仕様書無しさん mailto:sage [2008/03/26(水) 23:32:59 ]
実行プランを認識してない馬鹿が組むSQLは見てらんない
死ねばいいのに

715 名前:仕様書無しさん mailto:sage [2008/03/26(水) 23:41:11 ]
>>704
OSI7層モデルから勉強しなおせ。

716 名前:仕様書無しさん mailto:sage [2008/03/27(木) 22:28:29 ]
>>715
OSI7層って実行速度より美しい理論モデル作りたがりの産物じゃん
当時の実装は各境界の通信でオーバーヘッド出まくりで
遅くて使い物にならないものが多かった
マシンの性能が上がった今なら実装のしようもあるだろうが
IPにとって代わられちゃったし

717 名前:仕様書無しさん mailto:sage [2008/03/28(金) 01:56:38 ]
>>716
OSIの考え方を用語するつもりはないが、
OSIは政治的に潰されたんだよ。これ豆知識ね。

718 名前:仕様書無しさん mailto:sage [2008/03/28(金) 07:28:36 ]
>>717
OSI モデルの第 8 層って奴だな。
あと、宗教層・経済層ってのを加えるときもある。


719 名前:仕様書無しさん mailto:sage [2008/03/28(金) 09:11:35 ]
>>718
それは、知らなかった。補足ありがとう。

720 名前:仕様書無しさん mailto:sage [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 名前:仕様書無しさん mailto:sage [2008/03/31(月) 08:56:59 ]
>>721
>この程度でIF文はいらん。
そんなこと言うから変なコードが増える。
IF文をけちってなにかいいことでもあるのか。

723 名前:仕様書無しさん [2008/03/31(月) 09:28:34 ]
>>722
ヘタクソやね〜。
母言語とSQLでスパゲッティ作っておいしいか?

724 名前:仕様書無しさん mailto:sage [2008/03/31(月) 10:03:52 ]
スパゲッティ?

725 名前:仕様書無しさん mailto:sage [2008/03/31(月) 20:01:02 ]
>>721ぐらいなら普通IFなんて使わんだろ。

726 名前:仕様書無しさん mailto:sage [2008/03/31(月) 21:21:00 ]
"commit"をハードコーディングする俺の会社orz

727 名前:仕様書無しさん mailto:sage [2008/03/31(月) 21:27:21 ]
>>726
それなんか問題あんの?
どーでもいいじゃん

728 名前:葉猫 ◆Jz.SaKuRaM mailto:sage [2008/03/31(月) 22:08:26 ]
正直、ストアドのwhere句に条件式入れるのと、exeのsql文のwhere句に入れる違いがわからん。

729 名前:仕様書無しさん mailto:sage [2008/04/01(火) 07:24:50 ]
>>728
プランナについて勉強しよう

730 名前:仕様書無しさん mailto:sage [2008/04/01(火) 12:07:32 ]
勉強できるほどの知能があれば、とっくにコテやめてるだろう。



731 名前:仕様書無しさん mailto:sage [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 名前:仕様書無しさん mailto:sage [2008/04/01(火) 21:42:39 ]
>>727や731のコードが汚いことはよくわかった。

宣言的トランザクション使えよ。

734 名前:仕様書無しさん [2008/04/01(火) 21:58:27 ]
>>733はバカ


735 名前:仕様書無しさん mailto:sage [2008/04/01(火) 22:18:44 ]
ORまっぷっぷは、SQLも覚えられないボケが崇拝するお花畑のちょうちょに過ぎないし。
プロシージャはマニア魂を刺激しちゃって、ろくなことにならないときあるし。

やっぱハードコーディングが一番いいよ。
効率的だし、ブレないし、マニアックになり過ぎないし。

736 名前:仕様書無しさん mailto:sage [2008/04/01(火) 22:20:44 ]
でも最近はORマッパで済ませちゃうのがもてはやされる。
Railsとか。

737 名前:仕様書無しさん mailto:sage [2008/04/01(火) 22:25:08 ]
結論から言うと適材適所でしょ
ルールはきちんと作ってだけどね

738 名前:仕様書無しさん mailto:sage [2008/04/01(火) 22:31:39 ]
関係ないけどJOIN禁止のプロジェクトとかまだあんのかなぁ

739 名前:仕様書無しさん mailto:sage [2008/04/01(火) 23:02:24 ]
3年間オラクレばっかやってた。
今度SQL鯖やるんだけどJOINって何だよおしえれorz


740 名前:仕様書無しさん [2008/04/01(火) 23:05:51 ]
グイでグイグイやってたらSQLは勝手に出来る



741 名前:仕様書無しさん [2008/04/01(火) 23:18:16 ]
結局ハードコーディングの方があとで分かりやすいんだよな

742 名前:仕様書無しさん mailto:sage [2008/04/01(火) 23:19:39 ]
Set OraDynaset = Nothing

743 名前:仕様書無しさん mailto:sage [2008/04/01(火) 23:20:27 ]
うん。
別ファイルにしてあると、開くのにマウスこちこちしないといけないからめんどくさいしね。

744 名前:仕様書無しさん mailto:sage [2008/04/01(火) 23:21:49 ]
今日書いたSQLは3年後5年後も通用するが今日使ったO/R mapperは
3年後5年後には誰も使わないレガシーな技術になってると思う

745 名前:仕様書無しさん [2008/04/01(火) 23:43:57 ]
>>739
(+)

746 名前:仕様書無しさん mailto:sage [2008/04/02(水) 00:13:02 ]
unionしてsumしてクロス集計ってアリなの?

747 名前:仕様書無しさん mailto:sage [2008/04/02(水) 09:37:09 ]
ORマッパがいいのなら、素直にオブジェクト指向データベース使えよ。
なぜ、今まで使われなかったのか、考えてみ。

748 名前:仕様書無しさん mailto:sage [2008/04/02(水) 20:32:28 ]
>>745
それはオラクル特有のおまじないじゃん?

749 名前:仕様書無しさん mailto:sage [2008/04/02(水) 22:10:52 ]
今さら (+) なしの生活には戻れないわ・・・
もうすっかりOracleに毒されちゃってるのよ・・・

750 名前:仕様書無しさん mailto:sage [2008/04/02(水) 22:29:39 ]
最近のSQL Serverだと*=や、=*は使えないんだっけ?
つーか、Oracleでも9i以降ならOUTER JOINで書かないか?



751 名前:仕様書無しさん mailto:sage [2008/04/02(水) 22:48:57 ]
ora9iのOUTER JOINはバグが潜んでる

752 名前:仕様書無しさん mailto:sage [2008/04/02(水) 23:55:27 ]
バグは、9.1.4までじゃない?
(+)を書く奴は氏ねとは言わんけど、金取れるプロじゃないわな。

753 名前:仕様書無しさん mailto:sage [2008/04/03(木) 00:45:44 ]
www.google.co.jp/search?q=(%2B)

754 名前:仕様書無しさん mailto:sage [2008/04/03(木) 02:38:01 ]
>>752
何で死ね扱いなんだ?
俺は書きやすいし読みやすいから (+) の方がすきなんだが

755 名前:仕様書無しさん [2008/04/03(木) 07:58:45 ]
*=とかよりはJOINの方が見やすいという人が多い。
自分もそう思います。


756 名前:仕様書無しさん mailto:sage [2008/04/03(木) 09:20:53 ]
>>754
SQLの意味が分かってない。
SQL とは Structured Query Language(構造化問合せ言語)

省略語じゃないとかそんなことはどうでもよいけど、
構造化いうのは、句ごとに役割が決まっているわけ。

WHERE句に結合条件と抽出条件を混在させても違和感を
覚えない時点で、プロとしてのセンスはない。


757 名前:仕様書無しさん mailto:sage [2008/04/03(木) 09:37:48 ]
>>756
あの旧世代の腐れ構文が構造化されているように見えるとは恐れ入った。

758 名前:仕様書無しさん mailto:sage [2008/04/03(木) 09:46:18 ]
xxxx JOIN Table ON
という書き方が冗長というのは、同じ非英語圏の人間だから
わからんではないが、WHERE句に結合条件を書くのは痛い。

759 名前:仕様書無しさん [2008/04/03(木) 10:05:05 ]
>>757
まぁ、あれだ。
マシン語から新世代に近づくほど、
自然言語に近づくもんなんだ。
ループがある方が旧世代なんだな。


760 名前:仕様書無しさん mailto:sage [2008/04/03(木) 11:34:11 ]
>>757
腐っていようが…。
WHERE句に結合条件を書いたら、もっと腐る
ということが分からない時点で終わってる。




761 名前:仕様書無しさん mailto:sage [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 名前:仕様書無しさん mailto:sage [2008/04/03(木) 15:50:26 ]
LEFT JOIN

764 名前:仕様書無しさん mailto:sage [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 は文句言いながら副問合せ書く奴と見たw


765 名前:仕様書無しさん mailto:sage [2008/04/03(木) 17:56:22 ]
>>764
お前は莫迦か。
後者は結合後に抽出してんだろが。

766 名前:仕様書無しさん mailto:sage [2008/04/03(木) 18:21:33 ]
文脈読めよ。
>>761
-- そういやこないだ、
--  JOIN 〜 ON (〜 AND HOGE = 0)
-- なんて記述を見かけた。

に対して >>764 だ。

767 名前:仕様書無しさん mailto:sage [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 名前:仕様書無しさん mailto:sage [2008/04/03(木) 20:33:26 ]
ここで悦に入って何か得られるモノがあるのだろうか・・・

769 名前:仕様書無しさん [2008/04/03(木) 22:56:03 ]
>>732のようなコードのメンテをやらされてると、この仕事辞めたくなるな。
そんなもんの修正はそれに違和感感じない連中だけでやってくれって感じだ。

770 名前:仕様書無しさん mailto:sage [2008/04/04(金) 07:34:06 ]
>>732
なんだこれ・・・
こんなんjavaで書いてきたらソースレビューの時点で突っ返すぜ
もし下請けが書いてきたらくびになっても検収印はおさねえ!



771 名前:仕様書無しさん mailto:sage [2008/04/04(金) 07:37:39 ]
出来ない奴はとっとと氏ね

ってことだな。

772 名前:仕様書無しさん mailto:sage [2008/04/04(金) 09:05:47 ]
>>769
俺は
 sWhere += 〜
 sWhere += 〜
 sWhere += 〜
   :
こういうのが並んでる時点で唾棄。

773 名前:仕様書無しさん mailto:sage [2008/04/04(金) 09:44:07 ]
sprintf( buf, "select %s from %s\n", col, tbl );

774 名前:仕様書無しさん [2008/04/04(金) 09:47:30 ]
質問です。

各テーブルごとにテーブルクラスを作成し、

データの受け渡し受け取りには、テーブルクラス.レコードを定義して使用しています。


で、各テーブルごとの違いは、レコードクラスの違いくらいであとの処理は同じなので、

同じ処理を書いて、あまりステップ数を膨らませるのは嫌なのですが、

何かよい方法はないでしょうか?

775 名前:仕様書無しさん mailto:sage [2008/04/04(金) 09:55:19 ]
>>774
>質問です。
スレの選択も満足にできないの?

776 名前:774 [2008/04/04(金) 10:01:21 ]
SQL文ハードコーディングを嫌がるスレということなので、
↑の質問にも答えてもらえると思ったのですが、ちょっとスレ変えることにします

777 名前:仕様書無しさん mailto:sage [2008/04/04(金) 20:33:23 ]
>>774
javaならhibernate使えよ。

778 名前:葉猫 ◆Jz.SaKuRaM mailto:sage [2008/04/04(金) 21:40:57 ]
継承も使えずにクラスを使うとはなかなかやりまつね

779 名前:仕様書無しさん mailto:sage [2008/04/04(金) 21:41:56 ]
はずかしげもなくまだ生きてる貴様に比べれば誤差未満だな

780 名前:仕様書無しさん mailto:sage [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 名前:仕様書無しさん mailto:sage [2008/04/05(土) 19:57:42 ]
>>780
あー、すごいねー。ほんとにすごいよー。たいしたもんだねー。
ほかにだれもまねできないよー

782 名前:仕様書無しさん mailto:sage [2008/04/05(土) 19:59:42 ]
>>780
ポスグレ?オラクルで組めよ。

ちなみに SQLいんじぇくしょん ってしってまつか?

783 名前:仕様書無しさん mailto:sage [2008/04/05(土) 20:16:48 ]
>>781,782
ほめてもらう or 煽りを期待してるわけじゃない。

よりいい方法を知ってる人がいたら、教えて欲しいだけ。

784 名前:780,783 mailto:sage [2008/04/05(土) 20:19:52 ]
ここID表示なしか。

ついでに言うと、Oracle、DB2対応済み。
SQLインジェクションとか当たり前のように対応済み。
sprintf ではなく snprintf を使ってることから予想付いた人も多いと思うけど。

785 名前:仕様書無しさん mailto:sage [2008/04/05(土) 20:24:01 ]
その関数使うと桁あふれ起こすかも知れんのじゃ?

786 名前:仕様書無しさん mailto:sage [2008/04/05(土) 20:24:56 ]
こんなエサに俺様がクマー(AA略

787 名前:780,783 mailto:sage [2008/04/05(土) 20:31:01 ]
>>785
いいつっこみ。ありー。
セキュリティも兼ねてSQL文に文字列制限入れてる。

最近のオープンソースのDBはほとんどSQLの長さ制限はなくなってきたから、
そろそろこのAPIの長さ制限も取り払った方がいいかもしれない。
ただ最近のMySQLに詳しくないから、調べないと・・・。

788 名前:仕様書無しさん mailto:sage [2008/04/05(土) 20:31:42 ]
>>784
予想がつくのはエスパーだけだ

789 名前:仕様書無しさん [2008/04/05(土) 20:35:27 ]
そのAPIは評判良いの?
俺が使わないといけない立場だったら嫌だなぁ。
俺はストアドで組むのがしょうにあってるわ。

790 名前:780,783 mailto:sage [2008/04/05(土) 20:38:58 ]
>>789
いろいろ機能つけすぎて、ほとんど自分専用(笑)・・・ orz

もしオープンソースにするとかなったとしたら、
もっとよく使う機能だけに絞ってとかやらないと普及しないんだろうねー。
もしくはよっぽど設計を考えて、スマートに分かりやすくするか。

もっとも今どきCでこんなAPIの需要は少ないか・・・。



791 名前:仕様書無しさん mailto:sage [2008/04/05(土) 20:45:13 ]
>>790
そんな部分だけ見せられても
エスパー以外には評価のしようがないがな。

見えてる部分だけだと、それやばくね?・・・ってのが正常な反応と思。

792 名前:仕様書無しさん mailto:sage [2008/04/05(土) 20:47:24 ]
>基本的なテーブルのselectややinsertやupdateなら一切SQLを書くことも見ることもない。

「基本的」という言葉の意味が定義されていないので他人には使えない。


793 名前:仕様書無しさん mailto:sage [2008/04/05(土) 20:53:55 ]
てか、いきなり使用例出してきてこれAPIって何?せんずり?
Cはともかく日本語で出せ。つか人に見せてないもん普及とか言うな。クズ。

794 名前:780,783 mailto:sage [2008/04/05(土) 20:54:38 ]
>>791
確かに。けど、ソース公開はどこかに
未発見のセキュリティホールあったらやばいから出来ないし。
すまん。

>>792
比較演算子: OR AND = != < > <= >= like
フィールド型: 文字、数値、日付、時刻など
他: ()

where句の組み立てなんかは、
オープンソースDBのSQL分析のソースを参考にして作ると、
もっと柔軟な検索条件に対応したAPIが出来そうな予感。

しかしそこまで行くと、検索条件をいちいち関数呼び出して登録するより、
直接SQL文を書いた方が早いぜってことにもなりそう。

もっとも拡張性やメンテナンスを考えれば、直接SQLを書くのはナンセンスなんだろうけど。
そこは開発コストと将来のコストのどっちを優先するかって話しになりそう。

795 名前:780,783 mailto:sage [2008/04/05(土) 21:01:22 ]
比較演算子 に OR AND 入ってるのは変だな。

>>793
日本語で説明するにも、面倒すぎて。
すまん、自前APIに関しては、もうスルーしてくれ(--;

796 名前:仕様書無しさん mailto:sage [2008/04/05(土) 21:49:27 ]
>>793
よくコード一ステップごとに日本語コメントを書いて提出しろとほざく馬鹿SEPGがいるけど
コードそのものが体を現してるのに何をほざいてるのだと。お前がまさにその典型。
これが理解できない人はさっさと尻まくって引きこもりでもしてなよ。
じゃなきゃ金払うか頭下げて教えを請うんだな。

797 名前:仕様書無しさん mailto:sage [2008/04/05(土) 21:54:41 ]
>>796
ほお。じゃこれで
>insertやupdateなら一切SQLを書くことも見ることもない。
もわかるわけだ。すげぇな。エスパー。

798 名前:仕様書無しさん mailto:sage [2008/04/05(土) 22:46:47 ]
>>780が自作APIだって?プププ

799 名前:仕様書無しさん mailto:sage [2008/04/05(土) 22:52:51 ]
>>790
自分専用って…
プロジェクトメンバー各人がこんなふうな勝手な実装をしているの?
大丈夫なのか、それ?

800 名前:仕様書無しさん mailto:sage [2008/04/05(土) 23:37:16 ]
寝た子は殴るなという言葉があるだろう



801 名前:仕様書無しさん mailto:sage [2008/04/05(土) 23:39:43 ]
  テーブル名を元にDBからテーブル構成引っ張ってきて
  処理系毎のパディングを考慮した構造体の配列に
  突っ込む関数

というものは作ったが。
「SQLくらい手前で書けよ。莫迦しかいねぇのかこの会社」
と呪いの言葉を吐きながら。
(尤も、前時代的なSQLなんてもんは個人的には捨てちまいたいんだが)

ま、テーブルの結合だの副問い合わせだのがなけりゃ
新人でも作れるわな。
唐突かつ自慢げにこんなところで語り始める程のもんじゃない。

802 名前:仕様書無しさん mailto:sage [2008/04/06(日) 00:28:28 ]
おいそこのバーコード
SQL文ハードコードやめねぇと
てめぇの頭の毛毟るぞ?

っていったら先週から出社拒否ですよ
なんてヘタレなんだよ


803 名前:仕様書無しさん [2008/04/06(日) 02:53:22 ]
どうだこのAPIすげーだろ!一切SQLを書くことも見ることもなくてすむんだぜ!

反応 >>8

804 名前:仕様書無しさん mailto:sage [2008/04/06(日) 02:58:02 ]
誰かAPIの意味を教えてやれ

805 名前:仕様書無しさん mailto:sage [2008/04/06(日) 04:36:51 ]
AんたのPリクラIりません

806 名前:仕様書無しさん mailto:sage [2008/04/06(日) 05:51:27 ]
O/Rマッパー使えばいいじゃん。

807 名前:仕様書無しさん mailto:sage [2008/04/06(日) 05:54:04 ]
いっさいSQL見せないAPI(?)だったら、最初からSQLのレイヤ使わなきゃいいのに、
内部でへんちくりんなSQLごりごり生成して性能落としたあげく、対応できない
複雑な処理にはSQLが直接使えて便利だぜ!ってのはなんか違うんじゃ。
もともとSQLそのものがオーバヘッド大きいのに、その上にかぶせてもなぁ
いっそクエリを言語仕様にいれちまえ、っつMSの判断はアリだはと思うけど。

808 名前:仕様書無しさん mailto:sage [2008/04/06(日) 05:55:31 ]
最近複雑なSQLを書かなくなったな。

JOINとWHEREとORDER BYがすべて入るような
SQLだとインデックスをうまく使いづらいんだよね。

結果的にデータ読み込みの行数が跳ね上がって
逆に遅くなってしまう。

809 名前:仕様書無しさん mailto:sage [2008/04/06(日) 06:00:39 ]
これだけはいわせてくれ。

条件の数が可変で、AND とか OR とか それをつないでいく処理は
文字列結合で作っていくんじゃなく、

配列に入れておいて、最後で join(" AND ", 条件入れた配列) という風にしなさい。

810 名前:780,783 mailto:sage [2008/04/06(日) 07:14:09 ]
>>799
担当分けしてる。
引き継ぎが大変だろうなと思う今日この頃。

>>801
同じく作った。

>>807
なるほど、今まで考えたこともなかった。
SQLを使わずDBサーバと直接接続する方法のヒント教えてー。調べてみる。

>>808
同意。

>>809
Cにそんな便利な関(ry



811 名前:仕様書無しさん mailto:sage [2008/04/06(日) 07:18:43 ]
>>810
> >>809
> Cにそんな便利な関(ry

作れ!

812 名前:810 mailto:sage [2008/04/06(日) 07:24:52 ]
>>811
ネタに(ry

おそらく >>809 は検索条件は構造体に入れておき、
最後に組み立てろってことを言いたかったんじゃないかと。
ついでに言うと () とかに対応するために、
その構造体はツリー構造にしておいた方がいい。

813 名前:仕様書無しさん mailto:sage [2008/04/06(日) 08:07:40 ]
>>802
それ普通に裁判沙汰になるよ
妄想もほどほどに

814 名前:仕様書無しさん mailto:sage [2008/04/06(日) 09:02:47 ]
>>812
じゃなくて単にヒープの無駄遣いと文字列コピーのコストを抑えろ、ということだろ>>809は。

815 名前:809 mailto:sage [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 名前:仕様書無しさん mailto:sage [2008/04/06(日) 16:09:41 ]
おまえはandしか使わんのか?
つか、レベル低すぎだな、この手の話題

817 名前:仕様書無しさん mailto:sage [2008/04/06(日) 16:10:07 ]
もっとつまらん理由でしたとさ。

818 名前:仕様書無しさん mailto:sage [2008/04/06(日) 16:35:59 ]
この手の詰まらん事を意識できない奴にはいつまでたっても最良のコードは書けないよ。

819 名前:仕様書無しさん mailto:sage [2008/04/06(日) 16:38:50 ]
いや、正直>>815のレベルで最適なコードとか言われても…

820 名前:仕様書無しさん mailto:sage [2008/04/06(日) 16:52:04 ]
もっとブレークスルーなやつたのむ



821 名前:仕様書無しさん mailto:sage [2008/04/06(日) 17:06:28 ]
>>815
そんな低レベルの話だったのかw
期待して損したw

822 名前:仕様書無しさん [2008/04/06(日) 17:16:26 ]
809
m9(^Д^)プギャー

823 名前:仕様書無しさん mailto:sage [2008/04/06(日) 19:58:57 ]
>>809
WHERE 1=1
AND xxx = :xxx
AND yyy = :yyy
AND zzz = :zzz

これで解決じゃね?

824 名前:仕様書無しさん mailto:sage [2008/04/06(日) 20:51:10 ]
おいだれか、この中国人をつまみだしてくれ

825 名前:仕様書無しさん mailto:sage [2008/04/06(日) 21:06:45 ]
823は、よく使われてるテクニックだよ。
RoRのソースにもあった希ガス。

826 名前:仕様書無しさん mailto:sage [2008/04/06(日) 21:08:17 ]
Railsなんて糞に決まってるだろ

827 名前:仕様書無しさん mailto:sage [2008/04/06(日) 21:13:45 ]
>>825
その使い方はここの話の本筋とは関係ない。


828 名前:仕様書無しさん mailto:sage [2008/04/06(日) 21:25:24 ]
つか普通は823のテク使うだろw

829 名前:仕様書無しさん [2008/04/07(月) 12:44:36 ]
一年前そのシチュエーションでは文字列結合で作った。
反省はしていない。次回以降は823のやり方にする。

830 名前:801 mailto:sage [2008/04/07(月) 12:58:44 ]
>>809 がスレのレベルを一気に下げたな。

>>810
>同じく作った。
>>801 の後段は君に言ってんだけど。



831 名前:仕様書無しさん mailto:sage [2008/04/07(月) 20:51:55 ]
ハードコーディングと表現する奴は、
プリコンパイラの仕組みも知らない初心者だな。

832 名前:仕様書無しさん mailto:sage [2008/04/07(月) 21:05:19 ]
はあ???プリコンパイラなんて何の関係もないだろ・・・

833 名前:仕様書無しさん mailto:sage [2008/04/07(月) 21:15:17 ]
>>832
はあ?関係大ありだよ!

834 名前:仕様書無しさん [2008/04/07(月) 21:35:39 ]
>>808がよくわからん
インデックスを全て指定するのにその順番で書かない時はどんな時なの???

835 名前:仕様書無しさん mailto:sage [2008/04/07(月) 22:01:34 ]
複雑なSQLも落ち着いて分解すると
単純なSQL数個に分けられる

836 名前:仕様書無しさん [2008/04/07(月) 22:16:40 ]
で、プリコンパイラがどうしたって言うんだ

837 名前:仕様書無しさん mailto:sage [2008/04/07(月) 22:24:03 ]
カオスw

838 名前:仕様書無しさん mailto:sage [2008/04/07(月) 22:33:53 ]
ソースコードに直接SQL文を書くことを何て言うかなんて、
入門書にも出てくる初歩的な用語なわけで、
ハードコーディングとの違いも分からないようでは情けないな。

839 名前:仕様書無しさん mailto:sage [2008/04/07(月) 22:34:16 ]
全文検索になるってことだろ

840 名前:仕様書無しさん mailto:sage [2008/04/07(月) 23:59:48 ]
>>838
埋め込みSQLw



841 名前:仕様書無しさん mailto:sage [2008/04/08(火) 00:14:17 ]
話が滅茶苦茶というか
各人のイメージしているものがそれぞれ違うような気がしてきた

842 名前:仕様書無しさん [2008/04/08(火) 00:16:06 ]
ダバダの人
違いを教えてよ

843 名前:仕様書無しさん [2008/04/08(火) 00:20:33 ]
ホント2chって、どうでもいいSQL見たいな
素人レベルのことだとスレが伸びるのね。

ここぞって時の質問はスルーなのにねぇ。


844 名前:仕様書無しさん mailto:sage [2008/04/08(火) 00:26:29 ]
↓ここぞって時の質問

845 名前:仕様書無しさん mailto:sage [2008/04/08(火) 00:28:48 ]
↑矢印厨

846 名前:仕様書無しさん mailto:sage [2008/04/08(火) 00:36:53 ]
>>844
なんで俺には彼女が出来ないの?

847 名前:仕様書無しさん mailto:sage [2008/04/08(火) 00:37:11 ]
自転車小屋議論ですから。


848 名前:仕様書無しさん mailto:sage [2008/04/08(火) 01:43:50 ]
>>843
ここにはオレヨリモマイラハレベルが低いとオマイハ思いたい
と書いてある。

849 名前:仕様書無しさん mailto:sage [2008/04/08(火) 07:02:11 ]
プリコンパイラまだ〜?

850 名前:仕様書無しさん mailto:sage [2008/04/09(水) 00:19:11 ]
>>838
で、なんて言うの?まさか >>840 じゃないよね?



851 名前:仕様書無しさん mailto:sage [2008/04/09(水) 01:31:19 ]
基礎知識が無いというのは、
プログラム書く前にマニュアルとか読まずに、
先輩に要点だけ教わって書いてるのかね?

852 名前:仕様書無しさん mailto:sage [2008/04/09(水) 06:54:31 ]
シッタカ君がよく使う逃げ口上

853 名前:仕様書無しさん mailto:sage [2008/04/09(水) 07:02:03 ]
スレタイが知ったかそのものなわけだがw

854 名前:仕様書無しさん mailto:sage [2008/04/09(水) 19:16:38 ]
↓↓というわけで、プリコンパイラさん、どうぞ〜 ↓↓

855 名前:仕様書無しさん mailto:sage [2008/04/09(水) 20:10:29 ]
恥を書く前に入門書からコツコツ勉強しましょう。

856 名前:仕様書無しさん mailto:sage [2008/04/09(水) 20:19:44 ]
ほんと恥かしいよ、プリコンパイラさん。馬鹿まるだし。

857 名前:仕様書無しさん mailto:sage [2008/04/09(水) 20:37:51 ]
"SQL"と”ハードコーディング”でググってみたことあるかい?
このスレ以外では、間違って使う奴すらいないぞ。

858 名前:葉猫 ◆Jz.SaKuRaM mailto:sage [2008/04/09(水) 21:30:42 ]
このスレが上位をほぼ独占ちててワロタ

859 名前:仕様書無しさん mailto:sage [2008/04/10(木) 00:22:08 ]
さっさと死ねよ屑コテ

860 名前:仕様書無しさん mailto:sage [2008/04/10(木) 04:11:21 ]
ハードコーディング⊇埋め込み
だろ?

EXEC SQL 〜
とかやって、プリコンパイラ(Pro*C とか)で変換するのが埋め込み SQL(ハードコーディングの一種)
それ以外でも直接 SQL をソースに書くのが(埋め込みじゃない)ハードコーディング

何も難しくないだろ。




861 名前:仕様書無しさん mailto:sage [2008/04/10(木) 04:23:22 ]
>>860
じゃMSのLINQは言語の一部だからハードコーディングじゃないのか。
もっともあれはSQLじゃないといえばそうだけどさ。

862 名前:仕様書無しさん mailto:sage [2008/04/10(木) 05:58:01 ]
>>860
残念ながら、ググっても出てこないのだから、そういう「ハードコーディング」の解釈は一般にはないのだよ。

863 名前:仕様書無しさん mailto:sage [2008/04/10(木) 06:52:58 ]
自分の無知を棚に上げてよく言うわ

864 名前:860 mailto:sage [2008/04/10(木) 07:00:11 ]
>>861
LINQ, SQL の場合に限らず、なにかコードに直接書いたら、
何でもハードコーディングと呼ばないか?
860 もコードに直接書く場合しか書いてない。


865 名前:仕様書無しさん mailto:sage [2008/04/10(木) 07:10:49 ]
「ハードコーディング」は実行時の状態も関係してるから、
プリコンパイルの仕組みを理解していれば、
「ハードコーディング」と呼ぶことはないだろう。

866 名前:仕様書無しさん mailto:sage [2008/04/10(木) 07:41:45 ]
e-words.jp/w/E3838FE383BCE38389E382B3E383BCE38389.html


867 名前:仕様書無しさん mailto:sage [2008/04/10(木) 07:48:22 ]
「プリコンパイラ」はコンパイラの前に動くものなのだから、
ハードコーディングとは何かを理解していれば、
「プリコンパイラ」を持ち出すことはないだろう。


868 名前:仕様書無しさん [2008/04/10(木) 07:59:39 ]
>>867
それは、プリコンパイルも実行状態も理解してないから、そう思うのだ。

869 名前:仕様書無しさん mailto:sage [2008/04/10(木) 09:28:40 ]
でもさ、SQLってそもそも人間がいちいちISAMなんかのアクセスを
ハードコーディングしないように抽象化するために作ったもんだろ?
それをまた関数のパラメータに押し込んで、API(笑)化するのって
全然可読性を上げてることにならないような気がするんだけど。
皆がちゃんとSQLを学べば、テキストでSQL組み上げるような無様な関数
作らなくても全然平気じゃないか?第一、SQLがまともに使えないヤツが
その関数を楽々使えるとも思えないんだけどな。

870 名前:仕様書無しさん mailto:sage [2008/04/10(木) 13:23:44 ]
>>869
つか、それを言い出したらO/Rマッパは…ってなるような希ガスwww
事実、O/Rマッパなんて要らないけどさ。




871 名前:仕様書無しさん mailto:sage [2008/04/10(木) 18:58:47 ]
printf("Hello, World!\n");

これもハードコーディングって言うんだろうなぁ

872 名前:仕様書無しさん mailto:sage [2008/04/10(木) 19:41:12 ]
if (flag & 3) ...
これもハードコーディングと言うんだろうね。

873 名前:仕様書無しさん mailto:sage [2008/04/10(木) 22:43:49 ]
>>869
勉強もせず自分で勝手に想像して、「ちゃんとSQLを学べ」は自分だろw

874 名前:仕様書無しさん [2008/04/10(木) 23:13:19 ]
プリコンパイラが最適化してくれるとも思ってるのか、このバカちんは

875 名前:仕様書無しさん mailto:sage [2008/04/10(木) 23:16:26 ]
SQL文そのものなんてソース内で見ないまま扱えるようにクラス作りゃいいんだけど
でもねぇ

876 名前:仕様書無しさん mailto:sage [2008/04/10(木) 23:19:44 ]
>>871
それは明らかにハードコーディングだ
i18nって知ってる?

877 名前:仕様書無しさん [2008/04/10(木) 23:22:31 ]
物質の表面改質の為に、TiN, TiAlN, TiCN, CrN, DLCなどを
アークイオンプレーティング法などを用いて成膜し、
表面の硬度や耐摩耗性を高める。

878 名前:仕様書無しさん mailto:sage [2008/04/10(木) 23:23:12 ]
それはコーティング

879 名前:仕様書無しさん mailto:sage [2008/04/10(木) 23:23:59 ]
>>872
それはマジックナンバー

880 名前:sage [2008/04/10(木) 23:25:43 ]
それはハードコーティング



881 名前:仕様書無しさん mailto:sage [2008/04/10(木) 23:28:07 ]
>>874
さて、プリコンパイラは何をしてるのでしょうか?
それが分かれば、 >>871>>872 との違いも分かるでしょう。

882 名前:仕様書無しさん mailto:sage [2008/04/10(木) 23:30:25 ]
降参です答えを教えてください

と言えばこういう人は確実に逃げる

883 名前:仕様書無しさん mailto:sage [2008/04/10(木) 23:33:04 ]
>>882
オマエみたいに偉そうなバカに教えるわけがありません。

884 名前:仕様書無しさん mailto:sage [2008/04/10(木) 23:33:39 ]
頭の中で何となく理解しているつもりの事柄を
他人にしっかり説明しようと文章を書き始めてみる。

そのときに初めて、自分の知識がいかに曖昧で
本当は殆ど何もわかっていないということに気付く。

885 名前:仕様書無しさん mailto:sage [2008/04/10(木) 23:35:50 ]
>>884
自分で考えるのではなく、マニュアルを読め。

886 名前:仕様書無しさん mailto:sage [2008/04/10(木) 23:36:37 ]
まさかプリコンパイルされた後のソースを、コンパイルする前に
手で修正できるから、元ソースはハードコーディングじゃねーとか
わけわけめなこと言うんじゃねーだろうな、ウンコ野郎

887 名前:仕様書無しさん mailto:sage [2008/04/10(木) 23:37:19 ]
まともな RDBMS なら内部にクエリキャッシュを持っているので
実行時に SQL 文字列を毎回パーズして実行するなんていう馬鹿な処理にはならない。
そんなことは誰でも知っている常識

それとハードコーディングの問題は無関係


888 名前:仕様書無しさん mailto:sage [2008/04/10(木) 23:39:31 ]
ソフトコーディングもあるのかな

889 名前:仕様書無しさん mailto:sage [2008/04/10(木) 23:44:25 ]
でプリコンパイラは何をするのかな?もう逃げたか?

890 名前:仕様書無しさん mailto:sage [2008/04/10(木) 23:53:14 ]
>>886
やっぱり、プリコンパイルが何するか分かってないね。
自分で勝手に考えずに、マニュアル読めよ。



891 名前:仕様書無しさん mailto:sage [2008/04/11(金) 00:00:32 ]
埋め込みSQLを展開してるだけだろ
埋め込んだSQL文が勝手に最適化されるわけじゃないし
ハードコーディングじゃないということとは関係ないじゃん。


892 名前:仕様書無しさん mailto:sage [2008/04/11(金) 00:06:03 ]
知ったかぶりで上から目線で煽って、相手に文章を書かせる。
それによって自分が勉強する。技術系板の典型的厨房

893 名前:仕様書無しさん mailto:sage [2008/04/11(金) 00:06:38 ]
>>891
想像で書くな。マニュアル読め。

894 名前:仕様書無しさん mailto:sage [2008/04/11(金) 00:09:18 ]
なんだよ結局逃げかよ
具体的に説明してくれよ、プリコンパイラがこうするから
ハードコーディングじゃないよねって

895 名前:仕様書無しさん mailto:sage [2008/04/11(金) 00:12:41 ]
そもそもプリコンパイラって時点で具体的なDB製品に依存してるし…
顧客の予算やスケールに応じて組み合わせるDBを変更するとか
想像もつかないんだろうなこの人は

896 名前:仕様書無しさん mailto:sage [2008/04/11(金) 00:14:39 ]
>>894
それ教えちゃったら、面白くないでしょwww

897 名前:仕様書無しさん mailto:sage [2008/04/11(金) 00:16:17 ]
SELECT命令以外実行する権限が与えられていないのだ・・・

898 名前:仕様書無しさん mailto:sage [2008/04/11(金) 00:17:25 ]
en.wikipedia.org/wiki/Hard_coding

899 名前:仕様書無しさん mailto:sage [2008/04/11(金) 00:18:41 ]
ぐぐってもPro*Cしか出てこない。Oracle限定の話?

900 名前:仕様書無しさん mailto:sage [2008/04/11(金) 00:19:58 ]
>>896
同意。教えたら「なんだそんなことか、付き合って損した放置放置」で終わっちゃうよね



901 名前:仕様書無しさん mailto:sage [2008/04/11(金) 00:20:36 ]
少なくとも、このスレ以外ではSQL文をソースに書くことをハードコーディングとは
呼んでいないという現実を真摯に受け止めて、一から勉強することだな。

902 名前:仕様書無しさん mailto:sage [2008/04/11(金) 00:21:49 ]
esqlも知らんのか

903 名前:仕様書無しさん mailto:sage [2008/04/11(金) 00:21:57 ]
なんでスレが900に行こうというときに用語の定義でもめ始めるんだよwww。
その時点で普通のプロジェクトならデスマーチになってる。

904 名前:仕様書無しさん mailto:sage [2008/04/11(金) 00:21:58 ]
>>899
他の製品でもあるけど
基本的に埋め込みSQLをライブラリ・コールに変換するだけ
埋め込んだSQLが変化するわけではない。

905 名前:仕様書無しさん mailto:sage [2008/04/11(金) 00:23:22 ]
そりゃあプログラミングの観点から言えば
ハードコードされるのは文字列だからなあ。

ハードコードされる文字列の中身がSQLだってだけ。

で、何か?


906 名前:仕様書無しさん mailto:sage [2008/04/11(金) 00:23:22 ]
>>876
へー、ハードコーディングって言うんだ

907 名前:仕様書無しさん mailto:sage [2008/04/11(金) 00:24:03 ]
いいから逃げないで答え言えよ

908 名前:仕様書無しさん mailto:sage [2008/04/11(金) 00:26:06 ]
変数使ってるからってことだろ

909 名前:仕様書無しさん mailto:sage [2008/04/11(金) 00:27:58 ]
sql = "select * from emp where empno = ?";
これもハードコーディング?

910 名前:仕様書無しさん mailto:sage [2008/04/11(金) 00:28:40 ]
>>903
実際のプロジェクトでもよくあるだろ
途中から変なのが登場して最初から全部説明させられて挙句ひっくり返される



911 名前:仕様書無しさん mailto:sage [2008/04/11(金) 00:29:39 ]
>>872
マジックナンバーじゃない?

912 名前:仕様書無しさん mailto:sage [2008/04/11(金) 00:31:31 ]
O/Rマッパーでも、静的に事前に解析する奴は、ハードコーディングじゃねーの?

913 名前:仕様書無しさん mailto:sage [2008/04/11(金) 00:33:00 ]
resultset.column(0) ←ハードコーディング
resultset.column("id") ←ハードコーディング

914 名前:仕様書無しさん mailto:sage [2008/04/11(金) 00:33:51 ]
customers.id ←ハードコーディング

ハードコーディングじゃない奴ってどんなんだw

915 名前:仕様書無しさん mailto:sage [2008/04/11(金) 00:34:58 ]
static final ID = "id";
...

resultset.column(property.get(ID));←ハードコーディング?

916 名前:仕様書無しさん mailto:sage [2008/04/11(金) 00:35:10 ]
要するに、真性包茎はハードコーティング
仮性包茎は動的コーティング

917 名前:仕様書無しさん mailto:sage [2008/04/11(金) 00:35:50 ]
スレ流し読みしたが、prepared statement使えばハードコーディングじゃないって奴もいるみたいだな

918 名前:仕様書無しさん mailto:sage [2008/04/11(金) 00:37:16 ]
DB変わっても、テーブルレイアウト変わっても、ちゃんと動くのがソフトコーディング

919 名前:仕様書無しさん mailto:sage [2008/04/11(金) 00:37:18 ]
まずは、ハードコーディングの定義を何回も読むことだな。

920 名前:仕様書無しさん mailto:sage [2008/04/11(金) 00:37:34 ]
設定ファイルに書けばハードコーディングじゃないってのも意味不明



921 名前:仕様書無しさん mailto:sage [2008/04/11(金) 00:40:25 ]
テキストファイルに、
0:select * from emp
1:select * from emp where empno=?
2:select * from emp where empno=? and sex=?
とか書いて、それ読んで実行しろよw

922 名前:仕様書無しさん mailto:sage [2008/04/11(金) 00:41:23 ]
sql = GetSQLStatement(1) ← ハードコーディング

923 名前:仕様書無しさん mailto:sage [2008/04/11(金) 00:41:24 ]
場合によってはアリかもしれぬ・・・

924 名前:仕様書無しさん mailto:sage [2008/04/11(金) 00:44:52 ]
ハードコーディングするかどうかは本質じゃないってことだな

925 名前:仕様書無しさん mailto:sage [2008/04/11(金) 00:45:10 ]
Railsみないなやつも、コード生成が自動ってだけで、ハードコーディングだよね

926 名前:仕様書無しさん mailto:sage [2008/04/11(金) 00:47:18 ]
こりゃもうDDLから動的に生成する必要があるな

927 名前:仕様書無しさん mailto:sage [2008/04/11(金) 00:47:24 ]
このスレを見ている人はこんなスレも見ています。(ver 0.20)
【DI】Java Spring Frameworkを語るスレ 2.0 [プログラム]

これウケる。このスレから得るもんなんてねーぞww






[ 新着レスの取得/表示 (agate) ] / [ 携帯版 ]

前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧]( ´∀`)<176KB

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef