- 1 名前：仕様書無しさん [2007/02/07(水) 01:32:56 ]
- って思う
- 67 名前：仕様書無しさん mailto:sage [2007/02/08(木) 00:43:10 ]
- そんな微妙なチューニングが必要になる場合って、大抵テーブル設計が
糞だけどな。
- 68 名前：仕様書無しさん mailto:sage [2007/02/08(木) 02:14:30 ]
- ORマッピングなんて作り手の自慰行為じゃねーか
EJBと同じ匂いがするぜ
- 69 名前：仕様書無しさん mailto:sage [2007/02/08(木) 07:10:53 ]
- >>66
パフォーマンス無視だけどなｗ
- 70 名前：仕様書無しさん mailto:sage [2007/02/08(木) 07:54:17 ]
- >>61
ハイバネはまだまだバギーすぎて、本腰入れて使うのは厳しくない？
DBとの相性もあるかもしれないけど。
- 71 名前：仕様書無しさん [2007/02/08(木) 08:31:29 ]
- この手の話は
酒のつまみにはなるけど
飯の種にはならんな
- 72 名前：仕様書無しさん mailto:sage [2007/02/08(木) 08:32:04 ]
- EJBで性能でなくて生SQLに全部書き換えしたプロジェクト知ってる。
- 73 名前：仕様書無しさん mailto:sage [2007/02/08(木) 08:41:05 ]
- そいへばテーブルのvarchar項目にSQL断片を入れておいて
SELECTで組み上げてからそれをまた実行する変な仕事を
こないだしたな。そのクエリ結果の中にまたSQL文が入ってる(w)
- 74 名前：仕様書無しさん mailto:sage [2007/02/08(木) 08:46:19 ]
- >>73
ｗｗｗｗｗ
- 75 名前：仕様書無しさん mailto:sage [2007/02/08(木) 09:36:08 ]
- >>70
たぶんOracleのJDBCドライバが腐ってるせいだと思う。
Hibernateは悪くない。
- 76 名前：仕様書無しさん mailto:sage [2007/02/08(木) 09:38:36 ]
- ADO.NETが一番よくできてる
- 77 名前：仕様書無しさん mailto:sage [2007/02/08(木) 10:18:44 ]
- ADO.NET使える環境なら、それ使うにあたって議論は無いはず。
C/C++環境ならORM自作しなきゃいけないが、そんなことは誰もやらないはず。
- 78 名前：仕様書無しさん [2007/02/08(木) 11:44:37 ]
- PL/SQLを書く香具師の方が死んで欲しい。
- 79 名前：仕様書無しさん [2007/02/08(木) 12:13:54 ]
- 一番氏んで欲しいのは、AccessがないとDB触れない奴
- 80 名前：仕様書無しさん [2007/02/08(木) 12:19:43 ]
- UNIXでPro*Cとかだと、ストアドの方が文法的にも簡単で楽チン。
- 81 名前：仕様書無しさん [2007/02/08(木) 12:21:11 ]
- Pro*Cのソースは見れたもんじゃない
- 82 名前：仕様書無しさん [2007/02/08(木) 12:31:21 ]
- ORマッピングってやったことないんだけど、どーなのよ。
使いにくいんか?
- 83 名前：仕様書無しさん mailto:sage [2007/02/08(木) 13:29:21 ]
- >>82
かなり便利だが性能は出しにくいし たまに融通が利かない
- 84 名前：仕様書無しさん [2007/02/08(木) 14:11:36 ]
- >>83
iBatisだったら全然そんなことないぜ。
hibernateは理念にこだわり過ぎて美しいけど遅い。
SQL文レベルのチューニングだったら全然やりやすいし。
- 85 名前：仕様書無しさん [2007/02/08(木) 14:39:46 ]
- ORマッピングツール使えば
DBの表にあわせてクラスを生成しなくていいの？
- 86 名前：仕様書無しさん mailto:sage [2007/02/08(木) 15:21:25 ]
- ORマッピングの最高峰はWebObjects
- 87 名前：仕様書無しさん [2007/02/08(木) 15:25:52 ]
- >>86
アップル信者死ね。
- 88 名前：仕様書無しさん mailto:sage [2007/02/08(木) 15:34:34 ]
- >>87
アホ
俺は生粋のMS信者
- 89 名前：仕様書無しさん [2007/02/08(木) 17:44:23 ]
- ハードコーディングってなに？
- 90 名前：仕様書無しさん mailto:sage [2007/02/08(木) 19:52:29 ]
- >>89
表面を金属とかで堅く覆うことだろ．
- 91 名前：仕様書無しさん mailto:sage [2007/02/08(木) 19:54:58 ]
- >>89
一生懸命プログラミングすること
- 92 名前：仕様書無しさん mailto:sage [2007/02/08(木) 21:15:37 ]
- ととっとしネ
- 93 名前：仕様書無しさん mailto:sage [2007/02/08(木) 21:48:10 ]
- >>86,88
EOF,っても通じないしなぁ。
Cayenneとかはどーなんでしょ
- 94 名前：仕様書無しさん mailto:sage [2007/02/08(木) 22:37:25 ]
- >73
メタメタですね
- 95 名前：仕様書無しさん [2007/02/09(金) 00:48:56 ]
- >>93
>Cayenne
たぶんさ、Cayenneみたいなつくりだと、springとか使っても
service層とdao層きちんと分けないでつくっちゃうやつがプロジェクトに
出そうだから、辞めた方がいいんでは。
- 96 名前：仕様書無しさん mailto:sage [2007/02/09(金) 02:36:48 ]
- >>79
補助ツールとしては便利だけどね。
アレなしだと触れない奴はちょっとだな。
>>80-81
禿同
>>83
ちょkwsk
俺もORマッピング使ったことない。
- 97 名前：仕様書無しさん [2007/02/09(金) 08:47:24 ]
- ORマッピングフレームワークを使わない理由
・興味があって調べたらxmlを書きまくらないとﾀﾞﾒなのが分かる
・どういう設定をすればいいのかぱっと分からない
・それで便利になるの？という疑心暗鬼
・スピードは？ 融通性は？
・うーん。。。
・(ﾟ⊿ﾟ)ｲﾗﾈ
- 98 名前：仕様書無しさん mailto:sage [2007/02/09(金) 13:54:43 ]
- >>97
マジレスすると
オレの場合iBatisと自作のO/Rマッピングツールを使ったことがあるけど
>・興味があって調べたらxmlを書きまくらないとﾀﾞﾒなのが分かる
velocityとかのテンプレートエンジン使って自動生成しる。
複雑なSelect文なんかはO/Rマッピングツールは苦手だから
そこらへんはビュー作って対応すると幸せ。
>・どういう設定をすればいいのかぱっと分からない
慣れろ
>・それで便利になるの？という疑心暗鬼
例えばDBのカラム名がクラスのメンバ名になるから配列の3番目がUserNameとか面倒な事を考えなくてもいい。
あとDBのカラムが減ったり名称が変わったときにコンパイルが通らなくなるから
実行時のエラーが減ってバグが減少する。
>・スピードは？ 融通性は？
単純な更新系ではそんなに変わらない気がする。
うちではバッチ系とかスピード求める部分にはストアドを採用した。
- 99 名前：仕様書無しさん [2007/02/09(金) 14:52:55 ]
- ＞あとDBのカラムが減ったり名称が変わったときにコンパイルが通らなくなるから
＞実行時のエラーが減ってバグが減少する。
え？
じゃあDBの構成を変えたら、ロジックに関係なくてもソース直さなきゃいかんの?
例えば客先要望で「UPDDATEというのをUPDATE_DATEに変えてもらえますか?」とか言われたら
更新日付なんてINSERT文の中にSYSDATE入れてただけでも直さなきゃいかんの？
- 100 名前：仕様書無しさん mailto:sage [2007/02/09(金) 15:13:28 ]
- クライアント数が多いシステムだときついね。
- 101 名前：仕様書無しさん [2007/02/09(金) 15:15:02 ]
- >>99
INSERT文が
INSERT INTO HOGE VALUES(...
だったらいいけど
INSERT INTO HOGE(UPDDATE) VALUES(...
ならダメじゃないか？
- 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 ]
- Ｏ／Ｒマッピングが一括更新に向いてないのは作者達も認めているところで
そこはむしろ、SQLによる更新やストアドプロシジャなどとの併用を勧めている。
全てがオブジェクトで処理できないから使えないという考えは柔軟性に欠ける
のでは？ 保守性や開発効率を考えて適材適所で使い分ければいいと思う。
それと、他のＯ／Ｒマッピングがどうかはしらんが、例えば、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マッパーなんて
ありえないだろｗ
- 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を保守して、クラスの生成とＤＢの更新ってパターンだな。
- 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
運用段階でＤＢを変更する事態になったら、どんなやり方しようが影響はあると思うが・・・
- 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 ]
- それはないｗｗ
- 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 ]
- なんでもかんでも人工キーってのもあれだけど、なんでもかんでも自然キー
ってのは頭悪すぎる。ＳＱＬが無駄に長くなりやすいし、ＯＲＭには当然向かない。
- 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はＯＲマッパーを使ったことないだろ？
- 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のコードだな、
結局コード上に書いて行くのが最良だと思う。
オブジェクト指向のデータとその操作をオブジェクトに
するという面からも正しいし。
|
 |
