- 1 名前：仕様書無しさん [2007/02/07(水) 01:32:56 ]
- って思う
- 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のコードだな、
結局コード上に書いて行くのが最良だと思う。
オブジェクト指向のデータとその操作をオブジェクトに
するという面からも正しいし。
- 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使わない＝ＯＲＭ使わない）のつもりで
いたもんだから・・・
余計なお世話かもしらんけどＯＲＭ使うと設定でできちゃうもんで。
- 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 ]
- 今の世の中いつの間にか猫も尺由美子もＸＭＬだな。
- 187 名前：仕様書無しさん [2007/02/11(日) 02:26:35 ]
- >>185
そのパターンはやるなってのが一般的な見解になりつつない？
論理的にHTTPのリクエスト自体とビジネスロジック、DBトランザクションの
範囲は一致しないし。
なんかどっかに記事あったような。IBMなんかの。
なによりフィルタでやると、ネットワーク系のI/Oの時間がさらにボトルネックとして追加される。
- 188 名前：仕様書無しさん mailto:sage [2007/02/11(日) 02:52:19 ]
- でも、Webアプリの場合、HTTPリクエスト≒ＤＢトランザクション じゃね？
リクエストを受けてトラン開始、レスポンス返す前にトラン終了ってパタン。
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のみでデータを、やりとりするのかよｗｗｗ
また、どんな方法を使うにせよ、テーブル同士のリレーションを考えにいれず
コードが書けるとは思えないのだが
- 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 ]
- それはない。ｗ
- 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とソースの２箇所に２重に構造が書かれているじゃん
もし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 ]
- 単純に解析や翻訳のオーバーヘッド減らして性能上げたいだけだろ？
今のサーバ性能じゃ仕方ない気がするが
マシン性能が１０万倍速くなってから理想を言うべきだと思うYO
まあ、そうなっても小賢しいチューニングは続くんだろうがな
|
 |
