2ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

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

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

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

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

3 :仕様書無しさん:2007/02/07(水) 01:54:00
2ゲット

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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


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

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

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


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

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

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

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

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

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

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


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

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

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

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

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

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


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

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

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

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

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

>>35
かなりな。

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

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

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 :2007/02/07(水) 21:31:10
ストアドは1トランザクション中に複数のSQLを投げる必要がある場合なんか効果的だよね。

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

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

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

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

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

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


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

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

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

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

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

やるやるwww

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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



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

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

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


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

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

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

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

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

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


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

>>80-81
禿同

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

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

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

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

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

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

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

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

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








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

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

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

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

 INSERT INTO HOGE VALUES(...

だったらいいけど

 INSERT INTO HOGE(UPDDATE) VALUES(...

ならダメじゃないか?

102 :99:2007/02/09(金) 15:32:10
>>101
いやだから、いままでINSERT INTO HOGE VALUES(...
って書いてたのをO/Rマッピングにすると変えなきゃならんの?、てこと。

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

103 :仕様書無しさん:2007/02/09(金) 15:35:48
>velocityとかのテンプレートエンジン使って自動生成しる。
>複雑なSelect文なんかはO/Rマッピングツールは苦手だから
>そこらへんはビュー作って対応すると幸せ。

やっぱもう無理
面倒すぎ

104 :仕様書無しさん:2007/02/09(金) 18:53:02
逆に直さなくてもよくなるケースもある罠。

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



105 :仕様書無しさん:2007/02/09(金) 19:03:00
>>103
つーかXMLで一カ所にまとまってる方がいいつーの。
XML差し替えだけで他のDBに移行できるんだし

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

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


107 :仕様書無しさん:2007/02/09(金) 19:55:37
>>106
iBatisでは素で出来るし
HibernateもHQLでできるんじゃん?


108 :仕様書無しさん:2007/02/09(金) 19:58:45
>>106
カラムが増えたりするし、SQL文が分散してないから、
大体ハードコーディングするよりらく。開発中も結構らくだし、
IDEとかの機能と絡めれば、全然ORマッピングのほうが開発が
はやいと思うけど。

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

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

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

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

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

112 :仕様書無しさん:2007/02/09(金) 21:14:29
股間を揉んでくれ・・・

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

114 :仕様書無しさん:2007/02/09(金) 22:09:25
保守性や開発効率を考えたら
DBの変更や仕様が変わったときに
XMLファイルとDBとソースの3箇所をいじらなきゃならないORマッパーなんて
ありえないだろw

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

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

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

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

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

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


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

もう尻拭いばっか

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

それだけで糞

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

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

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

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


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

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

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

カコイイ^^

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

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

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


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

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

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

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



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

にする。


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

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

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

DaoにSQL直記入の場合

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

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

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

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

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

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

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

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

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

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


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

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

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


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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

155 :仕様書無しさん:2007/02/10(土) 16:47:31
Visual Studio 2005のDB関連ウィザード類ってお前らから見てどうですか

156 :仕様書無しさん:2007/02/10(土) 17:19:14
なにこれ!?って感じ

157 :仕様書無しさん:2007/02/10(土) 17:26:23
>>155
じゅんってきちゃいました


158 :仕様書無しさん:2007/02/10(土) 17:34:57
つかハイバネなんか使わせるほうがアホだろ

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

160 :69式フリーPG ◆hND3Lufios :2007/02/10(土) 18:11:45
MFCのCRecordsetだってウィザードだけでは使いにくいんだよな。



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

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

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

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


163 :仕様書無しさん:2007/02/10(土) 19:54:56
XMLは、糞

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

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

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

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

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

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



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

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

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

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

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

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

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


>>169

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

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

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

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

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

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

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

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

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


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

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

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


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

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

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

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

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

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

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

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

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


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

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


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

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

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

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


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

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

197 :仕様書無しさん:2007/02/11(日) 12:35:18
java.utilに帰れ。


198 :69式フリーPG ◆hND3Lufios :2007/02/11(日) 14:26:26
猫も尺由美子

199 :仕様書無しさん:2007/02/12(月) 01:15:47
結局、JAVA叩きに落ち着いてますねーーーー

200 :仕様書無しさん:2007/02/12(月) 01:50:26
dbMAGICを触ったことのある俺が来ましたよ。

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


201 :仕様書無しさん:2007/02/12(月) 01:53:22
それはない。w

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

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

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

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

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

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


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


208 :仕様書無しさん:2007/02/13(火) 11:33:22
仕事のための仕事

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

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


211 :仕様書無しさん:2007/02/13(火) 13:03:25
結合も関数も普通に使えますが・・・

212 :仕様書無しさん:2007/02/13(火) 19:07:28
>211
SQLを書かなくていいはずのO/Rマッピングで、なぜか用意されているcreateSQLQuely()を使ってって事か?
それとも誰も見向きもしない独自仕様の、HQLを駆使してって事かな?


213 :仕様書無しさん:2007/02/13(火) 20:48:21
JDBCで何か問題が?

214 :仕様書無しさん:2007/02/13(火) 21:23:02
単純に解析や翻訳のオーバーヘッド減らして性能上げたいだけだろ?
今のサーバ性能じゃ仕方ない気がするが

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

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

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

おいおい、、、

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

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


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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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


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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

245 :仕様書無しさん:2007/02/14(水) 13:57:01
いつのまにやらXMLHttpRequestなんてのがJSに組み込まれてんのな

246 :仕様書無しさん:2007/02/14(水) 19:31:03
>216
じゃ結合と関数と一括削除のやり方を教えてくれよ。マジで。ビューとバッチ使った方法以外で。
Hibernate詳しいって自分で言ってる奴はよくいるんだが、一括削除の方法を聞くと消える奴ばかりで、
いまだに一括削除のやり方が分からん。


247 :仕様書無しさん:2007/02/14(水) 19:35:20
>>246
つーかiBatisは無視ですか、そうですか。

248 :69式フリーPG ◆hND3Lufios :2007/02/14(水) 20:36:01
福岡の那の津埠頭にはSOLってラブホがありますが、あれがSQLに見えたときは
休んだほうがいいとオモタ。

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


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

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

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

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

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

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


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

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

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

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

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

258 :仕様書無しさん:2007/02/15(木) 08:48:14
ハイバ使っても
String hqlDelete = "delete Customer c where c.name = :oldName";
みたいなこと書くんだ

へー




259 :仕様書無しさん:2007/02/15(木) 21:24:40
>>253

XMLで作れるんじゃね?

<?xml ?>
<select>
    <table><t/able>
    <colmuns><<olmuns>
    <where>
      <item></item>
      <type></type>
      <value></value>
    </where>
</select>

sql.select.setColmuns("*");
sql.select.setTable("テーブル");
sql.select.setWhere.setiIem("firstname")
sql.select.setWhere.setType("=")
sql.select.setWhere.setValue("hamada")




260 :仕様書無しさん:2007/02/15(木) 21:30:13
>>259

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

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

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


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

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

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

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

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

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

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

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


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

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

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


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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ベタでいいじゃん

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

さてメシ食ってこよう

312 :仕様書無しさん:2007/02/20(火) 12:41:23
自己主張が強いな。

313 :仕様書無しさん:2007/02/20(火) 13:48:07
iBatisみたいにSQL外に出てると、後のSQLレベルの
チューニングがDBエンジニアだけでできて楽ちん。

314 :仕様書無しさん:2007/02/20(火) 15:30:41
それはiBatis使わないとできないのか?

315 :仕様書無しさん:2007/02/20(火) 16:19:48
>>311
>>308はベタ書きじゃなくて、ベタな(一般的な)手法という意味じゃなかろうか。

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

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


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

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

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

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

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

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

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

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

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

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

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


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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 こ
  と

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

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

344 :仕様書無しさん:2007/02/22(木) 12:15:22
>>343
SQLやVBのコードを相談するんじゃなくて、

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

とかを相談すればいい。

345 :仕様書無しさん:2007/02/22(木) 13:00:26
>>344
おれは客の時は
そんなん、最初の時に全部しっかり言質とって設計確認してあるし
しかも、やってますっていってソースレビューさせてくんなかったよな!
って毎回言ってやってる。

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


346 :仕様書無しさん:2007/02/22(木) 16:08:39
>>345
納品物にソースが入っていればそういうことは言えなくなるし
実際に工数がかかるわけだから、イヤなら他に言ってください、で交渉決裂ってだけだね。


347 :仕様書無しさん:2007/02/22(木) 16:23:51
>>346
まぁ、うち社長が経済ヤクザだからなw

348 :仕様書無しさん:2007/02/22(木) 16:27:19
>>347
俗に言う「不良顧客」ってやつだな。
金払いが悪いなら用はないな。

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

371 :仕様書無しさん:2007/02/24(土) 00:04:02
何のDBか忘れちゃったけどさ、
CとかC++のソースに直にSQL書いて
独自のプリプロセッサで変換するやつがあったな。

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

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


372 :仕様書無しさん:2007/02/24(土) 00:11:12
Pro*Cには似てないな

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


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

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

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

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

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

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


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

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

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

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

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


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

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

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

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

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

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

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


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

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

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

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

あれ?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

78 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.02.02 2014/06/23 Mango Mangüé ★
FOX ★ DSO(Dynamic Shared Object)