- 1 名前：仕様書無しさん [2007/02/07(水) 01:32:56 ]
- って思う
- 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
これ見て思い出したんだが、昔、とんでもないシステムの改修させられたな。
当時アクセス２０００がすでに主流の時代にアクセス２．０だかなんだかで作られた
システム（そのこと自体は別にいいんだが）で、
なんか日付がずれるっつーからソースを見てみたら、
全ての月が３１日である、という前提でソースが書かれていた。
そりゃお前、１月や３月はいいが、２月や４月になるとズレるわな。
その他いろいろなバグ、バグ、バグ・・・
こんなもんどう考えても修正不可ってんで、結局その改修はウヤムヤになった。
- 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 の存在意義（ｒｙ
- 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
変態ｗﾊｹｰﾝ
- 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 ]
- ストアドのほうが開発者側の意識として緊張感が違うと思うｗ
感覚的なものだけど
- 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で不思議と感動した。ｗ
- 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 ]
- わかった！！
１は最近、『ハードコーディング』って言葉を覚えたんだな ｗ
- 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
毎回全件取得だと高速なディスクと大量のメモリがないと
まともに使えるようなレスポンスが得られないからなｗｗｗ
- 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で運用する要望が出たらリプレースで丸儲けだぜｗ
- 442 名前：仕様書無しさん mailto:sage [2007/03/01(木) 20:22:48 ]
- 無意味に妙に一貫性のある開発スタイルを採用しているものの方が、
機能追加や保守の際にはまることが多い。
トリッキーなコードをさらにトリッキーにすることで維持するくらいなら
掟を破っても良いんじゃないかと思うオレは若すぎますか？
- 443 名前：仕様書無しさん mailto:sage [2007/03/01(木) 21:44:15 ]
- >>442
具体的になんなんだ？
Javaとかでｲﾝﾀｰﾌｪｲｽや継承しまくったクラス設計をﾄﾘｯｷｰに感じてを保守しにくい、とか
VBで１メソッドを何十行もダラダラと長く記述するのを保守しやすい、とか
言うなら、藻前は若いんじゃなくて爺だと思うけど。
- 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に帰ってまいりました。
|
 |
