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

>>317
うちも全く同じだったので､上司と血を見るほどの大げんかをしてしまった。
こちらが完全に理論武装してパフォーマンス比較までレビューしたせいか、涙を浮かべて逆ギレされた。
しまいには「その比較実験は完全に捏造だ！」とまで言われ､そのせいで処分まで受けてしまった｡

>>327は実にバカだな。

>>327
馬鹿かぁーーー！！
お前かーーーー！！

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

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

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

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

>>327
バカな奴だ。329が正解だよ。

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

ケンカはダメ！みんな仲良くしよ♪

アホ上司は、アホだが上司だからな
理論武装と同じ程度の会社組織を壊す覚悟が必要だったな

こういうやつは客に対しても同じことしそうだ。
購入した備品にけちつけてみたり。

327の能力は評価するが
一緒には仕事したくないタイプ

>327の人気に嫉妬

ひあああああっ……！あああン！もうっ、もうダメぇ……！イっちゃう……！イっちゃ
う、イっちゃう、イっちゃう、イっちゃあひいいいいいいいいッ！イくうっ！そんなにされ
たらすぐイっちゃうよぉーっ！ああああああ！イク、イク、イク、イク、イク、イクッ！あ
っ、熱いい〜ッ！ああああああ！イクうッ！イクイクイクイクっ！イクうううううううううう
う〜！あああああああぁ……！あうっ……ああああ……イクう……あひいいいいいい
いぃ……！はへええええ！イグっ！イグうっ！イグイグイグイグ！イグーッ！あへ！
はへえっ！ひゃひいいいい！に、妊娠しちゃうっ！妊娠しちゃうううゥ〜！気持ちイイ
ぃ〜！妊娠キモチイイよぉ〜！ああああああああ！妊娠しながらイグう！イグっ！イ
グうっ！イグうぅーっ！

こんなところにまで任豚の魔の手が・・・！！
>>327はスレタイはとっとと氏ね

これが世に言う「コミュニケーション能力の欠如」というやつかね。

とっとさんって誰？

まあそれまでにもいろいろあったんだろうよ
そこまで327を叩くなって
もっとまったりいこうぜ

>>341
ま
　こ
　　と

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

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

>>343
SQLやVBのコードを相談するんじゃなくて、

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

とかを相談すればいい。

>>344
おれは客の時は
そんなん、最初の時に全部しっかり言質とって設計確認してあるし
しかも、やってますっていってソースレビューさせてくんなかったよな！
って毎回言ってやってる。

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

>>345
納品物にソースが入っていればそういうことは言えなくなるし
実際に工数がかかるわけだから、イヤなら他に言ってください、で交渉決裂ってだけだね。

>>346
まぁ、うち社長が経済ヤクザだからなw

>>347
俗に言う「不良顧客」ってやつだな。
金払いが悪いなら用はないな。

>>343
漏れの経験上、余程単純なシステムでない限り、
下手に修正を入れると、ドつぼにはまると思ひまふ。


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

技術者としては綺麗さっぱり修正したいが、ワーカーとしてはそんな金にならねえ癖に大変な事はやってる暇ねえと言う現実だ

そういう意味ではハードコードは色々便利だなw

>>351
どういう意味だw

言ってみたかったw

ハードコーディングをSQLServerで
パラメータ部分を　'　を　''　に変換してたら
SQLインジェクションなんて全然関係ない
ハードコーディング万歳

エスキューエルハードコーディング
相手は死ぬ

ハードコーディング自体を嫌うのは、
コンパイラーが死ぬほど、遅かった時代の爺だけだと思われ。

インデックス張るの忘れてたw
特に何も言われないので、バージョンアップのたびに小出しにしてやろう。

SQL外出しのなにが嬉しいのかさっぱりわかんね。
中出しで十分。

ビジュアル的には外出しの方が萌えね？

中出しの方が自然だろ

>>5
外に出しても大差ないだろ

ちゃんとつけないとな。

いい流れですね

市販のプロテクトを信用してると
穴が開いてることがあるぞ。

お前ら、中出しだの外出しだの穴だのいい加減にしろよ

要するに、>>365はお口に出して欲しい。ということだな？

>>343
これ見て思い出したんだが、昔、とんでもないシステムの改修させられたな。

当時アクセス２０００がすでに主流の時代にアクセス２．０だかなんだかで作られた
システム（そのこと自体は別にいいんだが）で、

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

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

>>367
似たようなので、「全ての年は月曜から始まる」って前提のソースがあったw

なんつーか、単なるアホなんじゃなかろうか

SQLだと曜日や日にちの計算が楽でいいけど、ここはあえてZellarの公式で曜日を求めてみるテスト

何のDBか忘れちゃったけどさ、
CとかC＋＋のソースに直にSQL書いて
独自のプリプロセッサで変換するやつがあったな。

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

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

Pro*Cには似てないな

何が嫌ってPro*C嫌いだなぁ。

Javaがある今、Pro*Cの存在意義ってないな

>>367
それ、SQL関係なくねw？

Javaさえあれば何もいらない人は思考が停止してるよね

Pro*C/C++ は C に埋め込むにはいいんだが
C++ に埋め込むととたんにがっかりするからな。

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

プロジェクトでﾊｲﾊﾞﾈ使おうということになったらしいが、使える人がいないらしい

ハイバネなんて使っていいことないよ

上の方で大絶賛してる奴がいるぞ

メリット・デメリット・向き・不向きをわかって
総合的判断で取り入れるのならいいけどね。＞ハイバネ
無条件で大絶賛とか、使える人もいないのにとりあえず使ってみようでは
いいことがあるわけない。

lazyロードとかトランザクションとか
気を使うとこが、かえって増えるから
個人的にはハイバネは、嫌いだな。
PJ内に詳しい人がいれば別なのかもしれんが。

>>382
>PJ内に詳しい人がいれば別なのかもしれんが。
黒船願望ｷﾀ━━━━(ﾟ∀ﾟ)━━━━ !!!!!

C/C++ならだまってOCI

データ検索機能を実装するときみんなどうしてるのかな。
データの持ち方にもよるんだろうけど、俺は（というかプロジェクトでは）
SQLを動的に生成して投げてしまう。

それ以外に方法が？

入力された検索条件をテーブルにいったん落として、
それをSelectで拾ってさらにSelect。全検索のログも残って便利。

言語、データ量、やりたい処理にもよるんでないの。

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

先生！
動的な生成はハードコーディングに入りますか？

動的ってダイナミック？
オンザフライ？

動物的

RDB使う以上Javaよりも低レイヤの言語使ってもあんま意味無いよね。
いくら頑張ってもけっきょくDBのボトルネックが問題になるし。

RDB使う以上どんな言語使ってもDBのボトルネックが問題になるし。

あれ？

Java使う以上JavaVMがボトルネックになるよね＾＾

それいじょうにRDBのボトルネックがでかいって言ってるんじゃねぇの？

いくらがんばってもRDBがボトルネックになるんだったらJava使っても使わなくても変わんないんじゃ・・・

Java言いたいだけかと

つまり、RubyとかPHPとかJavaとか、実行速度が遅い言語でもいいって事じゃね？
Cとか実装に時間がかかる＆ナーバスな言語にこだわる必要は無いって事を言いたいんだと思われ。

どうでもいいけどサーバサイドのJavaは全く遅くないどころか、
スケーラビリティとか考えたら現時点では最速だろ。

スケーラビティ考えてSQLハードコード

JVM立ち上がってれば速いよな

>>399
スケールできるだけで最速ではないと思う。
スケールの容易さではLAMPにも迫られてるような気もするし。

このスレは、スケールよりも保守性の方の話題なわけだが

PHPって結構早いような希ガス

>>404
保守性が落ちていくのがな．
マイナーバージョンアップで言語仕様が大幅に変わるのは病めていただきたい．

本当に良いモノってのは、変える必要は無いんだよ。

Java厨に言えよ

確かに単体ではJavaのほうが速い。
しかし、今のところ重厚長大なJavaで作りこんで単体で高速なものを目指すより、
PHPやPerlでさっくり作って、パフォーマンスはロードバランサで稼ぐほうが、
コストも安いし保守も楽。

パフォーマンスもあがる。Javaに勝ち目は無いよ。

保守楽か？

>>408
変態ｗﾊｹｰﾝ

PHPは、知らんがPerlの保守は、地獄の悪寒がするよ。

言語の違いによる保守性の話はスレちがいだということを理解できない輩がいますね

この場合の保守性というのは、少ないJava鯖より大量のPHP/Perl鯖のほうが
再起動などメンテナンスしやすいという意味では

PHPはパッケージを使うとORマッパーぽいことも出来るみたいだけどなー。

PHPがサックリあたりまでは解るが保守楽かぁ？

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

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

Javaじゃ大量の鯖を導入できないじゃん。WebLogic高くて。

Javaとかどうでもいいんだよ
ハードコーディングすること自体はどうなのよ

んだ。誰かJava vs LAMPのスレ立ててそっちでやれや

ハードコーディングするかしないかは大した問題ではない。

>>420
これは上司の一言スレのネタですね

ハードコーティングが悪か？って言われてもケースバイケースだろ。

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

>>422
それじゃマシも何も、用途が違うじゃねえか

Javascriptの保守の方が大変じゃね？

ストアドのほうが開発者側の意識として緊張感が違うと思うｗ
感覚的なものだけど

400以上のレスをロールバックw

>>423
いや、この場合だと用途は同じでOracleにあるデータを
集計してAccessに取り込むって目的だが、
AccessからVBA(ADO)でSQL投げて結果を受け取るか、
ADOでストアド呼ぶか？の違いがあるだけだが。

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

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

ケースバイケースは魔法の言葉

>>427
そーゆーショボイ用途で使われてるDB鯖に限ってスッペクを奢ってたりするから不思議。

わかった！！
１は最近、『ハードコーディング』って言葉を覚えたんだな ｗ

>>429
正直Oracleはいらん罠。
まあ、元ネタはCOBOLer上がりのヤツが提案したので、
各所でグダグダな設計だった。

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

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

>>429
毎回全件取得だと高速なディスクと大量のメモリがないと
まともに使えるようなレスポンスが得られないからなｗｗｗ

ストアド知らんだけだろ

俺のチンコがソフトコーティングされてます

>>434 仕事はいいから包茎手術に逝け。な？

しかし、ストアドを乱用する奴もいるよね。

>>436
マスタで一覧取得とか1件更新すらも、とにかくDBアクセスストアドっていう
ストアダーに出会ったことがある。

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

重い処理をDBにやらせるのはどうかと思う。

>>437
・WebとWin32クライアントが混在や並行稼働している（別々の言語からアクセスする可能性がある）
・ストアドのドキュメントがきっちり分類されて管理されている
ならば可能な限りストアドにしてしまった方がいい場合がある。と思う。

ストアドもいろいろな効用があるからなぁ。
あからさまに長い時間がかかる処理はストアドだろうし、
かなり複雑な処理もストアドだろうなぁ。

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

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

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

>>427
いいなぁ。VPNで運用する要望が出たらリプレースで丸儲けだぜｗ

無意味に妙に一貫性のある開発スタイルを採用しているものの方が、
機能追加や保守の際にはまることが多い。
トリッキーなコードをさらにトリッキーにすることで維持するくらいなら
掟を破っても良いんじゃないかと思うオレは若すぎますか？

>>442
具体的になんなんだ？

Javaとかでｲﾝﾀｰﾌｪｲｽや継承しまくったクラス設計をﾄﾘｯｷｰに感じてを保守しにくい、とか
VBで１メソッドを何十行もダラダラと長く記述するのを保守しやすい、とか
言うなら、藻前は若いんじゃなくて爺だと思うけど。

SQL文をハードコーディングするやつはとっとと引越しー

>>437
ストアダーになってみたことはある。
Update系は意外と楽できる。

俺の経験だと、コードに対する名前を他のテーブルから引っ張ってくるような部分も
結構、ストアドにすると良い感じだったな。Joinより見やすいし
外部結合時が必要な時も、パフォーマンスが出たように記憶している。

隊長！Hibernateとかいろいろ使った結果、1周してJDBCに帰ってまいりました。

JSP+Servlet+JDBC最強だよな

>>448
あまりに強すぎて、討ち死に続出。

JSPよりServletの方がいいだろ

詳細テーブルと親テーブルのレコードが1:nの奴にupdateするときとか便利だよね＜ストアド

>>448-450
これだからJava厨はきらいなんだ。。。

>>452
ごめんな。。

>>453
あ、いや、こっちこそ。。

ストアドは賛否両論あるとして、
トリガって実務で使ってるか？

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

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

>>455
つ 参照整合性

>>455
使う。便利だ。似たような用途だ。
例えば、新規取引先を登録したときなど。
問題は、あんまり知っている奴が多くないので、メンテで苦労することか。

>>455
別アプリと連携させるときに使うよ。
マスタ情報が更新されたら渡す、みたいな。

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

>>455
俺の経験ではトリガ使わずに、アプリ側で制御するね。
理由は不明。なんでだろうね。

>>459
トリガは便利だが、使い方を間違えると収拾付かなくなるし、
ケースバイ・ケースだろうな。

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

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

トリガからストアドを呼び出してスパゲッティ

極力ルールはアプリ側に置きたいので使わない

ロジックの分離イクナイ

トリガは便利だけど、知っている奴が少ないのが難点だな。

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

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

SQLのハードコード云々よりも
・ストアド禁止
・ビュー禁止
・トリガー禁止
のルールを徹底させようとするPM/SEのほうが先に氏んでくれと思う。

ビューとトリガーは禁止でいいよ

ビューは、遅くて使い物にならん。

＞「このフィールドを更新したの誰だよ？」って感じで。 

あるあるｗ

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

テンポラリテーブルはありでつか？

通常SQL部分はクラスでラップするから、ハードコーディングでいいんでは？
場合によってストアドも使うし、トリガは注意して使えば問題ないし、
ビューもテーブル設計の変更ができない時に仕方なく使う分にはいいんじゃない？

>>465
ルールを徹底させるだけマシだとおもう。

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

そうだな。駄目なら駄目としてくれたほうがすっきりする。

トリガーは微妙なんだが、ストアドやビューを好きに使われると
ナニか困るのか？

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

>>467
それはアンタのSQLが悪いだけｗｗｗ


>>473
同意

駄目な奴は何をやっても駄目．

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

え？普通じゃね？

ボタンを押下した後にＤＢ検索にいくなら、
嫌でもSQL投げないと、何も始まらないよな。

>>473
人単体で見れば確かにそのとおり。

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

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

VBの簡単な画面でそれやられると萎える

たかがVBだからな

>>475>>479-480
VB入門書にそういう記述をしている本がけっこうあるからなのさ。

VB厨がプログラムを分割しようとすると妙に不自然な形になるからなぁ。
長大なイベントハンドラを許容しておいたほうが無難かもしれん。

>>466
うそを言うな、ウソを。

>>482
モジュールに関数書いて、呼び出すようにしても、クラス化しろよ低脳とか言われちゃうしな

>>474

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

ビューと通常のSELECTだとビューが遅いというのは、どこで遅くなっているんだろうか

>>484
Foo formに1:1で対応するFoo logicクラスを作ってそこに全ての処理を延々書き連ねたコードなら見た。
イベントハンドラでは、そのlogicクラスのインスタンスを生成して、イベントハンドラに対応する長大なひとつのメソッドを呼ぶ。
アホかと。

>>486

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

>>488
別のビュー作ればいいじゃん

>>489
え？

>>488
じゃないけど
ちょっとそれ教えて欲しいと思った
今までDataSetで取り込んだりした後自分でPk設定してたりしてるんで
元々ViewにKeyを埋め込めるのならそうしたい

ビューが実態のあるオブジェクトなDBもあるのか？
普通はテーブルを参照するオブジェクトだと思うが。

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

ビューの元になるテーブルに適切なインデックスが張られていれば
ビューもそんなに問題にならないと思うけど

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

ビューにインデックス貼るって、用途無視してビュー作ってるだけじゃんw
ビューって言いたいだけだろ

早い遅いはDB板で。

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

>>488
実行計画とって、きちんとINDEXが使われるようなVIEWにしろｗｗｗ
つか、元表にちゃんとINDEX作れｗｗｗ


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


>>493
正解。

>>478
＞極端な話、マスタ登録はストアド側でマスタ更新はプログラム側ってこともありうるのよ。
＞同じレイヤーのロジックをストアドで組んだりプログラムで組んだりっていうのは
＞アーキテクチャとして正しい姿なのか？っていうのは疑問。

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

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

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

>>496

当然元表のＩＮＤＥＸは、使われているが
話にならんぐらい遅いよ。

こういう
ttp://www.geocities.jp/mickindex/database/db_view.html
ページもあるから、Ｖｉｅｗは、遅いって言うのも一般的な話だと思う。

>>498
VIEWでなく、普通にSELECTした方が速いのかい？

>>500
絞込み順番で速度が変わるのでViewだと遅くなることが多い。

DB2でJDBC経由で使う分にはVIEWとSELECTとの違いは体感しないけどなー。

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

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

>>500

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

ところで具体的にVIEW使うと遅くなるRDBってナニ？
>>502と同様にDB2だと、ﾃｰﾌﾞﾙでも、ビューでもﾏﾃﾘｱﾗｲｽﾞでも
どれも同じ速度で結果が返ってくるけど。

>>504

Ｏｒａｃｌｅだよ。

>DB2だと、ﾃｰﾌﾞﾙでも、ビューでもﾏﾃﾘｱﾗｲｽﾞでも
>どれも同じ速度で結果が返ってくるけど。

ソース希望。

>>505
ソースもなにもやって見れば解る。

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

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

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

ハードコードしてそうな人が多そうだから、そっちに話を戻そうか

ま、ストアド作ってもそいつを呼び出すもんはどうするのかってこともあるしね。

Oracleのせいにしたいやつがいるな。

別にハードコートが悪とも思えんけどなぁ。

たとえば以下みたいなSQLを直書きする方が
select DATE(a.yyyy || '-' || a.mm || '-' || a.dd ) from hoge as a, piyo as b
where ここらが動的生成
group by .....
having 動的生成

だとロジックを集中して短く作りこめるし。

そりゃ、select * from hogeみたいなハードコートは市ねとか思うけど。

ビューで集約操作をすれば遅くなる、って言ってるだけじゃん
ビューは遅い、なんて言い切るなよボケ

>>510
動的生成するにはハードコードだわな。

|| '-' ||

新しい顔文字かと思った

|| '-' ||
（。Ｙ。）

>>514
女神様じゃ〜

|| '-' ||
（。Ｙ。）ノ
　　肉

>>506
それ偶然だから。

ハードコーディングの定義って何？

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

>>518
ソースコードの中にSQLを直書きすること。

それの何が問題なの？

常に同一のSQLなら生SQLでいいけど、そうでもないのに
プレースホルダも使わずに
"select * from hoge where " + condition + ";"
なんて書いてるこわーいコードが世の中には溢れかえっている。

変更の度にコンパイル

>>521

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

>>522

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

数値のリテラルよりマシ。

>>521見て思ったんだが、上の方で出てるHibernateとかはこの問題は発生しないの？
使ったことないんでよくわからん

>>525
Hibernate関係ねー。よっぽど使い方まちがえたらSQLインジェクション発生する。

>>526
やっぱりそうだよね。ありがとう。

保守

保守

>>524
同じ意味のconstが複数あった時にゃ、リテラルの方がマシと思った

プリペアドステートメントってどうよ

O/Rマッパーでも使えというのか？
SQLを書いた方が早い場合もあるんじゃないか？

オラクルはわからんけどSAP R/3は内部でSQLをハードコーディング
してるのをよく見かけるぞ。

SAPだったら別に良いんじゃないかという希ガス

>>1
SQLインジェクションとかそういうことを危惧しての発言なのか、それとも単にリテラル文字列が気に入らないだけ？
後者ならお前はただのアホとしか言いようが無いぞ。

あーハードコーディングとか言ってるから後者だな。
１は馬鹿丸出し。

プレースホルダを埋めた形でハードコーディングしてますが。

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

Java界では保守性があがると言うもっぱらの噂ですよ。馬鹿っぽい気もするけどさ。

コードとSQL文の距離が離れることで、可読性が落ち保守性が落ちる。

S2Dao最強でOK

ハードコーディングしたほうがSQLインジェクションには強い

じゃあS2Dao Tigerでいいや

>>541
検索条件を変えられないなら、ハードコーディングしようがしまいが
SQLインジェクションには無敵

それは、ともかくSQLExceptionの変数をsexにしてるソースがあってさ
なんか、楽しいから、やめてほしいなぁと思うわけよ。

ﾜﾗﾀ

SQLインジェクション云々いってるやつって何なの？
それに対策立てた上での議論だろ？

VBのソースって半分以上がSQLだよね

ＸＰ的にはハードコーディングだな
困ってから作り直せばいいだろ。どうせ困る前に納期だ。

ハードコーディングじゃない方法ってどんなの？

XPなら重複コード禁止だろ
重複コード無しでSQLハードコーディングは無理だな。不可能。

"SELECT *" を使いまくればSQLなんて楽勝!

コボラ乙

>>５５０

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

柔軟性がどうこう言うﾔﾂに限って再利用可能なものをつくらないよなｗ

SQLはハードコーディングでいい。
外出しにしても再利用などできない。

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

O/Rマッピングで美しく解決できるのなんて
チューニングの不要なやり逃げ案件だけ

Webアプリの糞つまんねーCRUD部分にだけ適用するのが正解。

hhddf






jfghhgh






tyyrtr






werwerwer





utuytu

SQL が変わる時ってロジックも変わってることが多いんで、
SQL だけ外に出しても意味なくない?
SQL を自動生成してるんなら別だけど。

>>559
それどころか予期せぬ障害を引き起こしたりもする．
ウチのアホSEがSQLを変更するのは設定ファイル変更で，
プログラムの変更は入りませんから，再テストの必要は無いですね，
って言って見事にバグらせたことがある．
っつーか事前検証くらいしろよっていう話なんだけどさ．

htmlをロジックと分離するのは、それがデザインであるという以外に
定数として埋め込む手間とかいろいろあるんだよな。
SQLだと後者のメリットしかないんだけど、俺は外出しがいい。

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

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

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

>>561
何が言いたいのか全くわからん

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

せっかく分けたのにちょっとした修正時に結局両方直さなければならないのは悲しい事だ

563とか564のスレを読む限り、外出しの推進派と反対派では外出しの方法が違うのでは？と勘ぐってしまう。
564の意見とか的外れもいいとこ。

重複、ここでやれ。
http://pc11.2ch.net/test/read.cgi/prog/1180118552/l50

>>565
そう勘ぐったのなら、具体的にどう違うと思ったのか指摘すればいいのに。

スレとレスも間違えてるしな

1000行ﾚﾍﾞﾙのストアドをソースに埋め込む気にはならんな ('A`)ﾏﾝﾄﾞｸｾｰ

何言ってんだオメー
さっさと氏ねよ

結局、ソースファイルと外出しsqlの両方とも修正しなくといけなくなるだけ。

マ板のスキル低下は著しいなｗｗｗｗｗｗｗ

java向けのスレなのにC++とかのプログラマが来て些細なテクニック論に
なってるなこのスレ

そんな前提>1に書いてないので認めないｸﾏｰ

>>283
ちょwwそれうちの病院www
クエリはないけど、リンクテーブルだらけのmdbファイルあったわ。
でも処理はVBじゃないっぽい。

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

>>573
＋＋マが全部こんなのだって訳じゃないんだぞといっておく

スレの最初のほうを読んで、それ以降はチラ見してただけだから、Javaスレになってたなんて気ずかなかったよ。

づ

SELECT文とかを変数につっこんでExecuteとかマジやめて欲しいんだけど。
特にWebアプリの場合ね。
ストアドを作ってそれを呼ぶだけにするのば一般的だと思ってたんだけど
そうでもないの？
そういえばカカクコムとか昔攻撃されてたね。

>>579
DB側に処理をおくのは・・・って考え方もあるよ
インジェクション対応して無いなんてのはどうやっても問題外

hibernateってヒントつけられないから馬鹿だよね。
使い物にならん。

> するのば
　　　　　↑
あまり一般的じゃないと思う

Webの開発だったら普通はストアドプロシージャを実行するよ。
LINQなんて論外。

>>583
ストアドはないだろ・・・

>>584
PROCEDUREというやつの事です。
Accessだとクエリだっけ？

SQLをハードコーディングする人って多いのね。

インジェクション対策ならプリペアードクエリでいいだろ

DBへの処理はDB側で行うのかプログラムに書いちゃうかはプロジェクトによって分かれるね。
今のプロジェクトはDBへの処理は必ずストアドを使うように言われてる。
そもそもプログラムを実行するユーザーにはストアドのGRANT権限しか付与してくんない。
まあどっちでも良いや。

DB側に処理もって行ったら不可分散しにくいじゃん

一時テーブルを使えないとスピードが遅くなるからDB側でちょ (｀･ω･´) ｼｬｷｰﾝ

お前マジキメェ
さっさと失せろ

どう書くのが推奨なの？
SQL生成用の関数作ってパラメータ放り込むぐらいしか考えつかん

ORマッパ

今時一次テーブルとかスキル無いコテってなんなの？

以前も自らのアホっぷりを晒したレスを論破されて逃走
挙句の果てに火病って糞スレ立てるほどのアホの子ですから

なんでも*つければ
良いってもんじゃねーぞ。

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はハードコーディングはコンパイルして再起動してその画面行くのが面倒だし普通にやらんかったわ

GRANT権限ってなんだ

>>598
GRANT文を実行できる権限じゃね？

>>597
名前で検索って、それじゃIDの意味ねーよｗ
↑どうでもいいことを言ってみる。

>>597
WHEREを画面の入力によって組み立てたりすると
途端に破綻するんだろ？

>>599
中間管理職か...

>>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が対応してなかった希瓦斯

インジェクションされまくるじゃないか、とかは別にして、
結局ハードコーディングした方がいいじゃん、つ流れになりそうな話だなぁ

バカどもがどうしようと構わんが、マ板の質落ちたねぇ・・・

>>605
どうしたら上質だんだよ。

んだんだ

>>606
やっぱブラック、いろんな意味で。

>>603
SQL実行する前に値チェックをプログラムでやればいいだろ

INSERTする前には必ずSELECTして重複チェックしてください。

>>610
それはあまりに間抜けな仕様。

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

>>610
SELECTとINSERTの間に他のセッションからINSERTされちゃうことってないの?

>>611
俺らがSELECTされない間に、あいつはINSERTされてるんだよ、畜生。

>>613
俺なんかSELECTされる事が無いまま、そっけなくDELETEされるんだぜ。

>>614
お前は一度でもINSERTしたのか！

ハードコーディングってなんぞ？
JDBCは組込みSQLはハードコーディングに入ってんのか？

SQLを外に出してる奴は、他の言語内言語である正規表現とかも外に出してるのか？

spring framework位使いこなしなよ。おじいさん＾＾

中出しはらめぇ

springとＳＱＬのハードコーディングは、何の関係も無いと思うが・・・

ハードコーディング自体は悪くないが、
複数のメソッドで部分部分ＳＱＬ文字列組み立てるのは勘弁してくれ。

昔バカスイーツＳＥ女がいて
ソースが汚いとすぐハードコーディングハードコーディング言ってうるさかった

>>617
SQLと正規表現だと別もんだと思うんだが・・・
正規表現エンジン変えられるようにしてたりしたら外に出すなぁ

ハードコーディング肯定してる奴らってIDE使ってないんじゃないかって気はする

何言ってんだ？

>>610くらいからの流れにｸｿﾜﾛﾀ

>>623
RDBMS変わりうること前提にした外出しなの?

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

ハードコーディング＝静的ＳＱＬ
それ以外＝動的ＳＱＬ
ってこと？

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

>>628
静的・動的ってどういう意味で使ってる?

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

どういう意味？？？
静的＝コンパイラにＳＱＬのロジックを展開させてＬＭでは最終的なＤＢアクセスのロジックは固定
動的＝ＳＱＬが内部的に変わるのでＳＱＬ翻訳後にＤＢアクセスするのでの余計なオーバーヘッドがかかる

こんな感じ？

あ
ここマ板か
失礼、ＤＢ板と勘違いした

O/Rマッパは汎用的なのは良いが
オプティマイザの実行計画が
実は大変なことになってることが多いのが悲しいな。

>>627
正規表現の場合の話がしたいの？SQLの場合の話がしたいの？
SQLと正規表現は別もんって書いてあるよね？

>>632
裏で色々あったんだろうがDBMagazineのTopLinkは奇麗だったな・・・

>>630
SQLの場合はこんな感じかな。DB2限定だが。
静的：実行計画を事前に取得しておく。
動的：実行時に実行計画を取得する。

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

1 が言いたいのはたぶん、
同一のテーブルを参照するSQLを
いたるところに書くことに辟易
してるってことを言いたいんだと思う

それは、ハードコーディングだろうが、
外部ファイルに書こうが一緒だ。

レスも空気も読まずにageレスか・・・さすが冬

１が言いたいことはたぶん
プログラム内でSQL文を組み立てて発行することを言ってるんだと思う。
前にVBプログラマが作ったソースを見たら
sql = "SELECT * FROM テーブル"
conn.exec(sql)
みたいなコーディングだったんだけど、こういうのがハードコーディング？
DBにプロシージャとかを作成してアプリ側はそれを呼ぶだけにして欲しいってことじゃないの？

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

>>639
半年ROMれ

>639
あー半年と言わず三年ROMれ

ここの住人って常駐派遣が多そうだな。

客先常駐の請負仕事なだけで派遣じゃないよｗ

偽装派遣のにおいがするんだが・・・

てゆうかマジで客先常駐なんてありえないよね。
ぶっちゃけ惨めじゃん。
自分の会社じゃないところに行ってさ。
うちにもちっさい会社のエンジニアが沢山常駐してるけどかわいそうだよ。
会社によるだろうけど派遣社員にはネットやメールを使わせないとか
そういうルールもあるし。

常駐させてるのも、そういうルールを作ったのも
お前の会社なんだろ。

思い付きだけで書かれたものを残されるとツライと思う。
でも、OJTだけで教育しようとしてるウチじゃあ無くならないんだろうな。

>>647
詳細設計完了後に思いつきで
仕様変更を連絡して来なきゃ、
そのケースはかなり減ると思うｗｗｗ

先輩方！お手本ソースを教えて教えて！

M + ijime = Mijime = みじめ = 惨め

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

まだあったのなー。
最近、自宅で趣味でJavaのWEBシステム構築やってんだけど、
ハードコーディングが楽だわ。

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

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

>>651
あとO/Rマッパはチューニングしにくい罠

ハードコーディングってそもそも何？

俺はiBATISくらいの薄い方が好きだ

SpringJDBCがよい

http://bbs.cgiboy.com/Guestbook/BBS/07232290/
荒らしならここをつぶすのがいい

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

SQLをDBに持つとか別テキストに持つだとか構造をXMLにしてもっておくだとか
いろいろなプロジェクトがあったが、結局はSQLを直すときはソースも直す場合が多いよね。
そうなると分けるとよけい保守性が悪くなるよね。

修正の規模による

項目Ａ(3ﾊﾞｲﾄ)、項目Ｂ(6ﾊﾞｲﾄ)

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

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

目的は、項目Ｂの頭３バイトだけを”ＢＢ＊”で条件に指定して、
項目Ｂの頭３バイトを全て”ＢＢＺ”に更新したい場合どうすればよいのでしょうか？
項目Ｂの後３バイトの”ＣＣＣ”はそのまま残さなくてはいけないため、
どのようなＳＱＬ文にすれば良いのかわかりません。

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

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

>>659
concat(concat(substr(B,1,2),'z'),substr(B,4,3))でupdateしたらどうか？

>>660
本当にありがとうございます！！
さっそく明日実行してみます。！！
「現場で使えるＳＱＬ」って本読んでもうまくＳＱＬ文思いつかなくて。。。
本当にありがとうございます！！

設計が悪いようにしか思えん。

これ酷いな

ハードコーディング最強

S2DAOでいいや

>>659 コボラーのにおいがする

ストアドは使わないの？
コンパイル時間がかからないから初回がやたら遅いSQLにいいじゃん。

DBにSQL文いれときゃいいじゃん

>>668
それを取得するSQLはどうするんだ？

Dim SQL As String
SQL=DLookup("SQL","M_SQL管理テーブル","id=xxx")

Accessはポイだポイ。

>>670
Aceess かどうかはともかく、SQL 文を id(多分 数値型のつもりでしょ) で管理するってのは、
関数やら手続きを連番で管理するのと同じにおいがする。
id='xxxマスタ取得' とか id='xxx一覧取得' とかなら、数値管理よりはましかな。

>>672
これやった事ある。
SQLを修正するときは探すのも面倒なので新規にテーブルに
放り込んでたｗ
ソース側はid変えるだけ。
思ったよりも混乱は生じなかったよ。
DBに2回アクセスするのが欠点だけどｗ

SQLを別の場所に置いたとして、SQL修正後のテストのために
どのプログラムから、そのSQLが使われてるかとか常に管理してんの？
それとも複数のプログラムからはSQLを共有しない？

>>674
>それとも複数のプログラムからはSQLを共有しない？
その通りまったく同じSQLがたくさんはいっている。
ソース内で同じIDのSQLを呼び出さないルール
ソース側との整合性だけとれてればいいので管理しない。
テスト時に帰ってきたSQLが正しいかだけチェックしてる。
ぶっちゃけると中国人プログラマが勝手にこのルールに
してしまったので皆つきあわされたｗｗ

SQLを動的に作る自作API使ってる。1500行。
メリットはどんなSQL DBにも対応可能。
汎用性／柔軟性が高い。開発効率が良い。

デメリットはストアドとかが使えない。

それならS2JDBCでも使えよ。
まぁ、Javaじゃないかもしれんが

SQLを外出しにして管理しても再利用できる汎用的なSQLは
せいぜい全体の２・３割程度で、ほとんどは１箇所でしか使われない。
単純で汎用的なSQLについてはOR-MAPした方が便利だが、
帳票出力、データ集計、条件が複雑に変化するな検索など
ビジネスロジックそのものと言えるSQLはオンコーディングか、
ストアドにしてしまった方がシンプルかと…

おれもストアドだな

ストアド使い出すと、増えすぎて見通しが悪くなるから好かん

ストアドはうざいから俺も好かん

異様に処理時間のかかるアホみたいなのを平気で組むヤツが居るんよな

Oracleマニアみたいな人が作って残していった
バッチ処理で1万行のプロシージャと闘ったときは死ぬかと思った。
単純になるなら歓迎だけど、意地でもストアドみたいなポリシーはやめて欲しい。

>>683
それはストアドにしたから複雑になったんじゃなくて、
SQL一発でできることを無駄にカーソルで処理するから複雑になってるのでは？

>>683
１プロシージャに１万行なんて、そいつがキチガイなだけだろ

「カーソル」が使われているストアドは、COBOLからの書き換え以外認めない。

>686
それはまた極端なｗ

人間中庸が肝心だ。

PHPでSQLをハードコーディングしてあってびびった。
SQLは切り出せよ。
SQLインジェションされてサニタイズ漏れたら終わりだろがと。

言ったが今でも放置されたまま。

>>689
ハードコードしてあっても
プレースホルダ使うだけでだいぶ変わるがな。

つか「インジェション」ってｗｗｗ

SQLをハードコーディングすることとSQLインジェクションの問題は直行しているから、>>689の指摘は的外れだったんじゃないかなぁ？

>>691
直行？直交にしてもわからんしな。関係ないってコトじゃないのか。

ストアドにちておけば内部で文字列化ちてselectとかexecuteみたいなｱﾎなことちないかぎり
問題ないちな (･∀･)

ストアド簡単なのに作ろうとしない馬鹿が多すぎてこまる。
提案してもメンテできない・わからないで握りつぶされる。
結果ハードコーティングでバグおこしてデスマ。
あほSEは早く欝になって首つってくれ！！！！！

>>694
> 提案してもメンテできない・わからないで握りつぶされる。

ありがちだが、その連中の言い分も分からなくはない。

>>694
ストアドは扱いが難しい。

テーブル設計が完了した段階でデータベースの構造をフリーズして
後はデータの出し入れだけにしたいという方針が普通の感覚だと思うんだが、
プログラムと同じ感覚でストアドを作ると、この方針と衝突する。

データの意味づけが拡張されてストアドの修正が必要になっても、まかりならんって
ことになったりする。
そういう時はしかたないので、プログラム側でストアドに相当するSQLを新しく
発行するようにして、ストアドは呼ばなくなる。

設計段階でストアドの要件もしっかり決めておけってのが正論なんだろうが。
間に合わせ的に使ってしまったりするな。

俺がストアド嫌いな理由は、デバッガが使いにくいから。と
単純なSELECTやINSERTだったら、
ORマッピングツールのほうが良くて
混在すると鬱陶しいから、極力ORマッピングツールを使う。

提案してもメンテできない・わからないっていう、
SEはしんだほうがいいなと俺も思う。

ORマッピングとかORマッパってどういうものなんでしょうか？

SQL書かなくてもＲＤＢが使える魔法の箱さ！

ストアドは自動テストに組み込み難いんだよな
デバッグも面倒だし

制約が多すぎで使えねー、
検索系で組み込んだら遅くて使えねー、
マスタメンテ以外につかえねーの三拍子

意地でも使ってやるって人の背中にはデスマオーラが漂ってる

派生開発案件で元が腐ってたとかならともかく、
ストアドなど書かずに済むようにDB設計するのが基本だと思う。

あと、「性能」を理由にすぐにストアドを使いたがるプログラマって
単に手続き的にしか物事を考えられない（まともなSQLの書き方を知らない）
人が多いような。

バージョン管理とかはメンドクサくないの？

ストアドはバージョン管理めんどくさい。
ストアドは、データベースやSQL Serverの外から呼び出すプログラミング環境が
貧しかった時代の亡霊だと思う。昔はストアドで何でもかんでもやってた。

ORマッパについて解説しているサイトをご存じないですか？

今までの意見をまとめると、RDBSは糞ってことで良いか？

ハードコーディングってなんだろう

>707
>91

ストアドの方がパフォーマンスが良いとかはもう昔の話？
あと権限についてですが、ハードコーディングだと実行権限付与がめんどくないですか？そんなことないかな。
自分の会社はWebの開発が多いのですが、例えばIISを使っている場合だと
IISの匿名ユーザーにストアドの実行権限を付与してるだけです。
テーブルの書き込み権限とかは一切与えてなく、ストアドの実行権限のみです。
その方が安全とか先輩が言ってました。

そりゃそうだ
最近SQLを満足にかけない奴がORまっぱとかほざいてるだけのような気がする

休日は自宅にヒキコモリ。
仕事じゃひとつの言語にヒキコモリ。
ヒキコモリ人生万歳ですか？

>709
別に昔の話ではない。今も通じる。

権限は……面倒くせえからDBAでアクセスしちまえｳﾊﾊﾊってのばかり見かけるが

>710
前半と後半の乖離ぐあいにﾜﾗﾀ

>>709
ストアドの方がパフォーマンスがよいって言うのは今でも正しいけど、
テーブル設計とSQLの筋さえよければ今は十分なパフォーマンスが稼げる。
だからクエリをDB側ではなくアプリ側に持っていく事によって得られる
開発パフォーマンスの向上が今は重視されている感じだな。

実行プランを認識してない馬鹿が組むSQLは見てらんない
死ねばいいのに

>>704
OSI7層モデルから勉強しなおせ。

>>715
OSI7層って実行速度より美しい理論モデル作りたがりの産物じゃん
当時の実装は各境界の通信でオーバーヘッド出まくりで
遅くて使い物にならないものが多かった
マシンの性能が上がった今なら実装のしようもあるだろうが
IPにとって代わられちゃったし

>>716
OSIの考え方を用語するつもりはないが、
OSIは政治的に潰されたんだよ。これ豆知識ね。

>>717
OSI モデルの第 8 層って奴だな。
あと、宗教層・経済層ってのを加えるときもある。

>>718
それは、知らなかった。補足ありがとう。

一時期 layer8.jp とか取ろうと思ったこともあったが、
やっぱり取られてたぜ。

ハードコーディングとストアドを比べたらストアドの方がよい。
けれどハードコーディングには次のメリットがある。

たとえば、
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にするんだけど、そこまで気を
使っているコーディングを見ることがないな…。

>>721
>この程度でIF文はいらん。
そんなこと言うから変なコードが増える。
IF文をけちってなにかいいことでもあるのか。

>>722
ヘタクソやね〜。
母言語とSQLでスパゲッティ作っておいしいか？

スパゲッティ？

>>721ぐらいなら普通IFなんて使わんだろ。

"commit"をハードコーディングする俺の会社orz

>>726
それなんか問題あんの？
どーでもいいじゃん

正直、ストアドのwhere句に条件式入れるのと、exeのsql文のwhere句に入れる違いがわからん。

>>728
プランナについて勉強しよう

勉強できるほどの知能があれば、とっくにｺﾃやめてるだろう。

commit はハードコーディングじゃないの。
（一ヶ所にまとめるけどね）
少なくとも俺はストアドの中には書かせない。
ネストしたらえらいことだ。

>>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 も、インデックスが
存在して効率的なら使われるんだな。

>>727や731のコードが汚いことはよくわかった。

宣言的トランザクション使えよ。

>>733はバカ

ORまっぷっぷは、SQLも覚えられないボケが崇拝するお花畑のちょうちょに過ぎないし。
プロシージャはマニア魂を刺激しちゃって、ろくなことにならないときあるし。

やっぱハードコーディングが一番いいよ。
効率的だし、ブレないし、マニアックになり過ぎないし。

でも最近はORマッパで済ませちゃうのがもてはやされる。
Railsとか。

結論から言うと適材適所でしょ
ルールはきちんと作ってだけどね

関係ないけどJOIN禁止のプロジェクトとかまだあんのかなぁ

３年間オラクレばっかやってた。
今度SQL鯖やるんだけどJOINって何だよおしえれorz

グイでグイグイやってたらSQLは勝手に出来る

結局ハードコーディングの方があとで分かりやすいんだよな

Set OraDynaset = Nothing

うん。
別ファイルにしてあると、開くのにマウスこちこちしないといけないからめんどくさいしね。

今日書いたSQLは3年後5年後も通用するが今日使ったO/R mapperは
3年後5年後には誰も使わないレガシーな技術になってると思う

>>739
（＋）

unionしてsumしてクロス集計ってアリなの？

ORマッパがいいのなら、素直にオブジェクト指向データベース使えよ。
なぜ、今まで使われなかったのか、考えてみ。

>>745
それはオラクル特有のおまじないじゃん？

今さら (+) なしの生活には戻れないわ・・・
もうすっかりOracleに毒されちゃってるのよ・・・

最近のSQL Serverだと*=や、=*は使えないんだっけ？
つーか、Oracleでも9i以降ならOUTER JOINで書かないか？

ora9iのOUTER JOINはバグが潜んでる

バグは、9.1.4までじゃない？
(+)を書く奴は氏ねとは言わんけど、金取れるプロじゃないわな。

http://www.google.co.jp/search?q=(%2B)

>>752
何で死ね扱いなんだ？
俺は書きやすいし読みやすいから (+) の方がすきなんだが

*=とかよりはJOINの方が見やすいという人が多い。
自分もそう思います。

>>754
SQLの意味が分かってない。
SQL とは Structured Query Language(構造化問合せ言語)

省略語じゃないとかそんなことはどうでもよいけど、
構造化いうのは、句ごとに役割が決まっているわけ。

WHERE句に結合条件と抽出条件を混在させても違和感を
覚えない時点で、プロとしてのセンスはない。

>>756
あの旧世代の腐れ構文が構造化されているように見えるとは恐れ入った。

xxxx JOIN Table ON
という書き方が冗長というのは、同じ非英語圏の人間だから
わからんではないが、WHERE句に結合条件を書くのは痛い。

>>757
まぁ、あれだ。
マシン語から新世代に近づくほど、
自然言語に近づくもんなんだ。
ループがある方が旧世代なんだな。

>>757
腐っていようが…。
WHERE句に結合条件を書いたら、もっと腐る
ということが分からない時点で終わってる。

>>760
>腐っていようが…。
「構造化されてなんかいない腐れ構文」には同意頂けたようで。
…まあ、Oracle の旧書式は直感的だが、もっと腐ってるとは思う。

>WHERE句に結合条件を書いたら
「抽出条件」てのが「1行1項目しかない『定数』との結合条件」と考えれば
両者の間になんの違いもないわけだが。
-- そういやこないだ、
--　　JOIN 〜 ON (〜 AND HOGE = 0)
-- なんて記述を見かけた。

>>761
何が面白いのか解説してよ

LEFT JOIN

まちごうた。

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 は文句言いながら副問合せ書く奴と見たｗ

>>764
お前は莫迦か。
後者は結合後に抽出してんだろが。

文脈読めよ。
>>761の
-- そういやこないだ、
--　　JOIN 〜 ON (〜 AND HOGE = 0)
-- なんて記述を見かけた。

に対して >>764 だ。

FROM
　　table_a a
　　LEFT OUTER JOIN
　　　　(SELECT * FROM table_b WHERE key2 = 0) b
　　　　　ON a.key1 = b.key1

ってインデックス外すバカがいるわな。

ここで悦に入って何か得られるモノがあるのだろうか･･･

>>732のようなコードのメンテをやらされてると、この仕事辞めたくなるな。
そんなもんの修正はそれに違和感感じない連中だけでやってくれって感じだ。

>>732
なんだこれ・・・
こんなんjavaで書いてきたらソースレビューの時点で突っ返すぜ
もし下請けが書いてきたらくびになっても検収印はおさねえ！

出来ない奴はとっとと氏ね

ってことだな。

>>769
俺は
　sWhere += 〜
　sWhere += 〜
　sWhere += 〜
　　　:
こういうのが並んでる時点で唾棄。

sprintf( buf, "select %s from %s\n", col, tbl );

質問です。

各テーブルごとにテーブルクラスを作成し、

データの受け渡し受け取りには、テーブルクラス.レコードを定義して使用しています。


で、各テーブルごとの違いは、レコードクラスの違いくらいであとの処理は同じなので、

同じ処理を書いて、あまりステップ数を膨らませるのは嫌なのですが、

何かよい方法はないでしょうか？

>>774
>質問です。
ｽﾚの選択も満足にできないの？

SQL文ハードコーディングを嫌がるスレということなので、
↑の質問にも答えてもらえると思ったのですが、ちょっとスレ変えることにします

>>774
javaならhibernate使えよ。

継承も使えずにクラスを使うとはなかなかやりまつね

はずかしげもなくまだ生きてる貴様に比べれば誤差未満だな

自作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でやってる人いる？

>>780
あー、すごいねー。ほんとにすごいよー。たいしたもんだねー。
ほかにだれもまねできないよー

>>780
ポスグレ？オラクルで組めよ。

ちなみに　SQLいんじぇくしょん　ってしってまつか？

>>781,782
ほめてもらう or 煽りを期待してるわけじゃない。

よりいい方法を知ってる人がいたら、教えて欲しいだけ。

ここID表示なしか。

ついでに言うと、Oracle、DB2対応済み。
SQLインジェクションとか当たり前のように対応済み。
sprintf ではなく snprintf を使ってることから予想付いた人も多いと思うけど。

その関数使うと桁あふれ起こすかも知れんのじゃ？

こんなエサに俺様がクマー（AA略

>>785
いいつっこみ。ありー。
セキュリティも兼ねてSQL文に文字列制限入れてる。

最近のオープンソースのDBはほとんどSQLの長さ制限はなくなってきたから、
そろそろこのAPIの長さ制限も取り払った方がいいかもしれない。
ただ最近のMySQLに詳しくないから、調べないと・・・。

>>784
予想がつくのはエスパーだけだ

そのAPIは評判良いの？
俺が使わないといけない立場だったら嫌だなぁ。
俺はストアドで組むのがしょうにあってるわ。

>>789
いろいろ機能つけすぎて、ほとんど自分専用（笑）・・・ orz

もしオープンソースにするとかなったとしたら、
もっとよく使う機能だけに絞ってとかやらないと普及しないんだろうねー。
もしくはよっぽど設計を考えて、スマートに分かりやすくするか。

もっとも今どきCでこんなAPIの需要は少ないか・・・。

>>790
そんな部分だけ見せられても
エスパー以外には評価のしようがないがな。

見えてる部分だけだと、それやばくね？・・・ってのが正常な反応と思。

>基本的なテーブルのselectややinsertやupdateなら一切SQLを書くことも見ることもない。

「基本的」という言葉の意味が定義されていないので他人には使えない。

てか、いきなり使用例出してきてこれAPIって何？せんずり？
Cはともかく日本語で出せ。つか人に見せてないもん普及とか言うな。クズ。

>>791
確かに。けど、ソース公開はどこかに
未発見のセキュリティホールあったらやばいから出来ないし。
すまん。

>>792
比較演算子: OR AND = != < > <= >= like
フィールド型: 文字、数値、日付、時刻など
他: ()

where句の組み立てなんかは、
オープンソースDBのSQL分析のソースを参考にして作ると、
もっと柔軟な検索条件に対応したAPIが出来そうな予感。

しかしそこまで行くと、検索条件をいちいち関数呼び出して登録するより、
直接SQL文を書いた方が早いぜってことにもなりそう。

もっとも拡張性やメンテナンスを考えれば、直接SQLを書くのはナンセンスなんだろうけど。
そこは開発コストと将来のコストのどっちを優先するかって話しになりそう。

比較演算子 に OR AND 入ってるのは変だな。

>>793
日本語で説明するにも、面倒すぎて。
すまん、自前APIに関しては、もうスルーしてくれ(--;

>>793
よくコード一ステップごとに日本語コメントを書いて提出しろとほざく馬鹿SEPGがいるけど
コードそのものが体を現してるのに何をほざいてるのだと。お前がまさにその典型。
これが理解できない人はさっさと尻まくって引きこもりでもしてなよ。
じゃなきゃ金払うか頭下げて教えを請うんだな。

>>796
ほお。じゃこれで
＞insertやupdateなら一切SQLを書くことも見ることもない。
もわかるわけだ。すげぇな。エスパー。

>>780が自作APIだって？プププ

>>790
自分専用って…
プロジェクトメンバー各人がこんなふうな勝手な実装をしているの？
大丈夫なのか、それ？

寝た子は殴るなという言葉があるだろう

　　テーブル名を元にDBからテーブル構成引っ張ってきて
　　処理系毎のパディングを考慮した構造体の配列に
　　突っ込む関数

というものは作ったが。
「SQLくらい手前で書けよ。莫迦しかいねぇのかこの会社」
と呪いの言葉を吐きながら。
(尤も、前時代的なSQLなんてもんは個人的には捨てちまいたいんだが)

ま、テーブルの結合だの副問い合わせだのがなけりゃ
新人でも作れるわな。
唐突かつ自慢げにこんなところで語り始める程のもんじゃない。

おいそこのバーコード
SQL文ハードコードやめねぇと
てめぇの頭の毛毟るぞ？

っていったら先週から出社拒否ですよ
なんてヘタレなんだよ

どうだこのAPIすげーだろ！一切SQLを書くことも見ることもなくてすむんだぜ！

反応 >>8

誰かAPIの意味を教えてやれ

AんたのPリクラIりません

O/Rマッパー使えばいいじゃん。

いっさいSQL見せないAPI(?)だったら、最初からSQLのレイヤ使わなきゃいいのに、
内部でへんちくりんなSQLごりごり生成して性能落としたあげく、対応できない
複雑な処理にはSQLが直接使えて便利だぜ！ってのはなんか違うんじゃ。
もともとSQLそのものがオーバヘッド大きいのに、その上にかぶせてもなぁ
いっそクエリを言語仕様にいれちまえ、っつMSの判断はアリだはと思うけど。

最近複雑なSQLを書かなくなったな。

JOINとWHEREとORDER BYがすべて入るような
SQLだとインデックスをうまく使いづらいんだよね。

結果的にデータ読み込みの行数が跳ね上がって
逆に遅くなってしまう。

これだけはいわせてくれ。

条件の数が可変で、AND とか OR とか それをつないでいく処理は
文字列結合で作っていくんじゃなく、

配列に入れておいて、最後で join(" AND ", 条件入れた配列) という風にしなさい。

>>799
担当分けしてる。
引き継ぎが大変だろうなと思う今日この頃。

>>801
同じく作った。

>>807
なるほど、今まで考えたこともなかった。
SQLを使わずDBサーバと直接接続する方法のヒント教えてー。調べてみる。

>>808
同意。

>>809
Cにそんな便利な関(ry

>>810
> >>809
> Cにそんな便利な関(ry

作れ！

>>811
ネタに(ry

おそらく >>809 は検索条件は構造体に入れておき、
最後に組み立てろってことを言いたかったんじゃないかと。
ついでに言うと () とかに対応するために、
その構造体はツリー構造にしておいた方がいい。

>>802
それ普通に裁判沙汰になるよ
妄想もほどほどに

>>812
じゃなくて単にヒープの無駄遣いと文字列コピーのコストを抑えろ、ということだろ>>809は。

いや、そんなコストとかの話ではなく、

str += "where";
str += "flag=true";
str += "and value=1";

↓

whereflag=trueand value=1

なんて間抜けをやらないですみますよということ。
条件の数が可変で引数によってつけたりはずしたりすると、
where and value=1 とかやってしまうだろ？という話。

joinのようなもので最後にくっつければ、絶対andの前後にスペース入れられるし、
whereのあとにいきなりandがでてきたりなんて事を防げる。

おまえはandしか使わんのか？
つか、レベル低すぎだな、この手の話題

もっとつまらん理由でしたとさ。

この手の詰まらん事を意識できない奴にはいつまでたっても最良のコードは書けないよ。

いや、正直>>815のレベルで最適なコードとか言われても…

もっとブレークスルーなやつたのむ

>>815
そんな低レベルの話だったのかｗ
期待して損したｗ

809
m9(^Д^)ﾌﾟｷﾞｬｰ

>>809
WHERE 1=1
AND xxx = :xxx
AND yyy = :yyy
AND zzz = :zzz

これで解決じゃね？

おいだれか、この中国人をつまみだしてくれ

823は、よく使われてるテクニックだよ。
RoRのソースにもあった希ガス。

Railsなんて糞に決まってるだろ

>>825
その使い方はここの話の本筋とは関係ない。

つか普通は823のテク使うだろｗ

一年前そのシチュエーションでは文字列結合で作った。
反省はしていない。次回以降は823のやり方にする。

>>809 がｽﾚのレベルを一気に下げたな。

>>810
>同じく作った。
…>>801 の後段は君に言ってんだけど。

ハードコーディングと表現する奴は、
プリコンパイラの仕組みも知らない初心者だな。

はあ？？？プリコンパイラなんて何の関係もないだろ・・・

>>832
はあ？関係大ありだよ！

>>808がよくわからん
インデックスを全て指定するのにその順番で書かない時はどんな時なの？？？

複雑なSQLも落ち着いて分解すると
単純なSQL数個に分けられる

で、プリコンパイラがどうしたって言うんだ

カオスw

ソースコードに直接SQL文を書くことを何て言うかなんて、
入門書にも出てくる初歩的な用語なわけで、
ハードコーディングとの違いも分からないようでは情けないな。

全文検索になるってことだろ

>>838
埋め込みSQLｗ

話が滅茶苦茶というか
各人のイメージしているものがそれぞれ違うような気がしてきた

ダバダの人
違いを教えてよ

ホント2chって、どうでもいいSQL見たいな
素人レベルのことだとスレが伸びるのね。

ここぞって時の質問はスルーなのにねぇ。

↓ここぞって時の質問

↑矢印厨

>>844
なんで俺には彼女が出来ないの？

自転車小屋議論ですから。

>>843
ここにはｵﾚﾖﾘﾓﾏｲﾗﾊレベルが低いとｵﾏｲﾊ思いたい
と書いてある。

プリコンパイラまだ〜？

>>838
で、なんて言うの？まさか >>840 じゃないよね？

基礎知識が無いというのは、
プログラム書く前にマニュアルとか読まずに、
先輩に要点だけ教わって書いてるのかね？

シッタカ君がよく使う逃げ口上

スレタイが知ったかそのものなわけだがw

↓↓というわけで、プリコンパイラさん、どうぞ〜 ↓↓

恥を書く前に入門書からコツコツ勉強しましょう。

ほんと恥かしいよ、プリコンパイラさん。馬鹿まるだし。

"ＳＱＬ"と”ハードコーディング”でググってみたことあるかい？
このスレ以外では、間違って使う奴すらいないぞ。

このｽﾚが上位をほぼ独占ちててﾜﾛﾀ

さっさと死ねよ屑コテ

ハードコーディング⊇埋め込み
だろ?

EXEC SQL 〜
とかやって、プリコンパイラ(Pro*C とか)で変換するのが埋め込み SQL(ハードコーディングの一種)
それ以外でも直接 SQL をソースに書くのが(埋め込みじゃない)ハードコーディング

何も難しくないだろ。

>>860
じゃMSのLINQは言語の一部だからハードコーディングじゃないのか。
もっともあれはSQLじゃないといえばそうだけどさ。

>>860
残念ながら、ググっても出てこないのだから、そういう「ハードコーディング」の解釈は一般にはないのだよ。

自分の無知を棚に上げてよく言うわ

>>861
LINQ, SQL の場合に限らず、なにかコードに直接書いたら、
何でもハードコーディングと呼ばないか?
860 もコードに直接書く場合しか書いてない。

「ハードコーディング」は実行時の状態も関係してるから、
プリコンパイルの仕組みを理解していれば、
「ハードコーディング」と呼ぶことはないだろう。

http://e-words.jp/w/E3838FE383BCE38389E382B3E383BCE38389.html

「プリコンパイラ」はコンパイラの前に動くものなのだから、
ハードコーディングとは何かを理解していれば、
「プリコンパイラ」を持ち出すことはないだろう。

>>867
それは、プリコンパイルも実行状態も理解してないから、そう思うのだ。

でもさ、SQLってそもそも人間がいちいちISAMなんかのアクセスを
ハードコーディングしないように抽象化するために作ったもんだろ？
それをまた関数のパラメータに押し込んで、API(笑)化するのって
全然可読性を上げてることにならないような気がするんだけど。
皆がちゃんとSQLを学べば、テキストでSQL組み上げるような無様な関数
作らなくても全然平気じゃないか？第一、SQLがまともに使えないヤツが
その関数を楽々使えるとも思えないんだけどな。

>>869
つか、それを言い出したらO/Rマッパは…ってなるような希ガスｗｗｗ
事実、O/Rマッパなんて要らないけどさ。

printf("Hello, World!\n");

これもハードコーディングって言うんだろうなぁ

if (flag & 3) ...
これもハードコーディングと言うんだろうね。

>>869
勉強もせず自分で勝手に想像して、「ちゃんとSQLを学べ」は自分だろw

プリコンパイラが最適化してくれるとも思ってるのか、このバカちんは

SQL文そのものなんてソース内で見ないまま扱えるようにクラス作りゃいいんだけど
でもねぇ

>>871
それは明らかにハードコーディングだ
i18nって知ってる？

物質の表面改質の為に、TiN, TiAlN, TiCN, CrN, DLCなどを
アークイオンプレーティング法などを用いて成膜し、
表面の硬度や耐摩耗性を高める。

それはコーティング

>>872
それはマジックナンバー

それはハードコーティング

>>874
さて、プリコンパイラは何をしてるのでしょうか？
それが分かれば、 >>871 や >>872 との違いも分かるでしょう。

降参です答えを教えてください

と言えばこういう人は確実に逃げる

>>882
オマエみたいに偉そうなバカに教えるわけがありません。

頭の中で何となく理解しているつもりの事柄を
他人にしっかり説明しようと文章を書き始めてみる。

そのときに初めて、自分の知識がいかに曖昧で
本当は殆ど何もわかっていないということに気付く。

>>884
自分で考えるのではなく、マニュアルを読め。

まさかプリコンパイルされた後のソースを、コンパイルする前に
手で修正できるから、元ソースはハードコーディングじゃねーとか
わけわけめなこと言うんじゃねーだろうな、ウンコ野郎

まともな RDBMS なら内部にクエリキャッシュを持っているので
実行時に SQL 文字列を毎回パーズして実行するなんていう馬鹿な処理にはならない。
そんなことは誰でも知っている常識

それとハードコーディングの問題は無関係

ソフトコーディングもあるのかな

でプリコンパイラは何をするのかな？もう逃げたか？

>>886
やっぱり、プリコンパイルが何するか分かってないね。
自分で勝手に考えずに、マニュアル読めよ。

埋め込みSQLを展開してるだけだろ
埋め込んだSQL文が勝手に最適化されるわけじゃないし
ハードコーディングじゃないということとは関係ないじゃん。

知ったかぶりで上から目線で煽って、相手に文章を書かせる。
それによって自分が勉強する。技術系板の典型的厨房

>>891
想像で書くな。マニュアル読め。

なんだよ結局逃げかよ
具体的に説明してくれよ、プリコンパイラがこうするから
ハードコーディングじゃないよねって

そもそもプリコンパイラって時点で具体的なDB製品に依存してるし…
顧客の予算やスケールに応じて組み合わせるDBを変更するとか
想像もつかないんだろうなこの人は

>>894
それ教えちゃったら、面白くないでしょwww

SELECT命令以外実行する権限が与えられていないのだ・・・

http://en.wikipedia.org/wiki/Hard_coding

ぐぐってもPro*Cしか出てこない。Oracle限定の話?

>>896
同意。教えたら「なんだそんなことか、付き合って損した放置放置」で終わっちゃうよね

少なくとも、このスレ以外ではSQL文をソースに書くことをハードコーディングとは
呼んでいないという現実を真摯に受け止めて、一から勉強することだな。

esqlも知らんのか

なんでスレが900に行こうというときに用語の定義でもめ始めるんだよwww。
その時点で普通のプロジェクトならデスマーチになってる。

>>899
他の製品でもあるけど
基本的に埋め込みSQLをライブラリ・コールに変換するだけ
埋め込んだSQLが変化するわけではない。

そりゃあプログラミングの観点から言えば
ハードコードされるのは文字列だからなあ。

ハードコードされる文字列の中身がSQLだってだけ。

で、何か？

>>876
へー、ハードコーディングって言うんだ

いいから逃げないで答え言えよ

変数使ってるからってことだろ

sql = "select * from emp where empno = ?";
これもハードコーディング？

>>903
実際のプロジェクトでもよくあるだろ
途中から変なのが登場して最初から全部説明させられて挙句ひっくり返される

>>872
マジックナンバーじゃない？

O/Rマッパーでも、静的に事前に解析する奴は、ハードコーディングじゃねーの？

resultset.column(0) ←ハードコーディング
resultset.column("id") ←ハードコーディング

customers.id ←ハードコーディング

ハードコーディングじゃない奴ってどんなんだｗ

static final ID = "id";
...

resultset.column(property.get(ID));←ハードコーディング？

要するに、真性包茎はハードコーティング
仮性包茎は動的コーティング

スレ流し読みしたが、prepared statement使えばハードコーディングじゃないって奴もいるみたいだな

DB変わっても、テーブルレイアウト変わっても、ちゃんと動くのがソフトコーディング

まずは、ハードコーディングの定義を何回も読むことだな。

設定ファイルに書けばハードコーディングじゃないってのも意味不明

テキストファイルに、
0:select * from emp
1:select * from emp where empno=?
2:select * from emp where empno=? and sex=?
とか書いて、それ読んで実行しろよｗ

sql = GetSQLStatement(1) ← ハードコーディング

場合によってはアリかもしれぬ・・・

ハードコーディングするかどうかは本質じゃないってことだな

Railsみないなやつも、コード生成が自動ってだけで、ハードコーディングだよね

こりゃもうDDLから動的に生成する必要があるな

このスレを見ている人はこんなスレも見ています。(ver 0.20)
【DI】Java Spring Framewoｒｋを語るスレ 2.0 [プログラム]

これウケる。このスレから得るもんなんてねーぞｗｗ

バカばっか

>>919
>ハードコーディングの定義
not well defined

結局プリコンパイラ君は説明できないんだね。にわかってこれだから困るんだよ。

>>929
それじゃ、具体的にオマエの思うハードコーディングしたSQL文とハードコーディングしてないSQL文の例を
挙げてくれれば、オマエ流のハードコーディングの定義が分かる。

もう見飽きたよ
待ちガイル　vs　待ちガイル

>>932
たとえベタ

>>933
示すものが判れば構わないさ
上手なお手本の一つも持ち合わせているんだろうね。楽しみにしておくよ。

>>934
意味不明

ＳＱＬをデータベースに格納しとけばいいんじゃない？

場合によってはアリかもしれぬ・・・

>>936
天才現る

意外とアリな気がしてきた

SQLじゃなくて、プリコンパイルした結果をRDBに格納すればいいんだよ。

>>940
それじゃ、人間が保守できないだろ。

>>936
ちなみにクエリの一部をDBに保存と言うのは俺の受け持ってる案件でもよくやってるよ。
RDBMSの種類やデータ量によってコストが変動する部分のクエリはロジックを変更せず
かつ動的に置き換え可能にしたかったからな。
まぁ、O/Rマッパーに依存してたらなかなか使いにくい手法だと思うが。

SQLをRDBに格納ってオブジェクト指向だしな

>>936
> ＳＱＬをデータベースに格納しとけばいいんじゃない？

>>670-675

>>942
> SQLをRDBに格納ってオブジェクト指向だしな

え? 解説希望。

>>936
糞仕様以外のなにものでもない

>>941
もちろんソースはソースでちゃんと管理するんだろ。

ソースもDB格納

>>946
天才現るｗｗ

リポジトリ≒DB

繋がった。

バイナリが格納できることを考えれば理論上なんでも出来る・・・・んだよねぇ

というか、ファイルシステムって一種の DB だよね。
だからって、RDB に SQL 格納ってのがいいとは言わんが。

>>949
マジで？空も飛べるの？

>>950
http://opentechpress.jp/developer/08/02/21/0051246.shtml
ファイルシステムをDBに保存するというのを思い出した。

>>951
Oracleはよく空を飛ぶ

>>952
そういえば、Windows Vistaも一時そんなことをやろうとして挫折したよな。

WinFSという幻のことかい？

>>952
>>954-955
不思議なんだけど、OSが起動するファイルシステムとDBに保存されたファイルシステムは別物なの？
WinFSは起動ファイルシステム＝DBのファイルシステムかなと思ってたんだけど。

とりあえずぐぐってみるといいと思うよ

そもそもRDBもよく分かってないから、スレタイみたいな発想になるんだろうな。

WinFSはファイルの種別やタグをDBに放り込んで、ファイルの検索を容易にする物じゃなかったっけ？
たとえば「エロデータ」を検索すればエロ小説のテキストやエロ画像、エロ動画が抽出できるとか。

>>959
そのエロデータ検索方式をぜひGoogleに追加してくれ！

>>959
その程度じゃspotlightと大差ないよーな。
もっと画期的な物になるはずだったにちまいない。

正直データアクセスがちゃんと局所化、集約化されていれば外部ファイル化されていようがソースコード直だろうがどっちでもいい。

カラムを追加すると検索結果のカラムの並びが変わるからダメだと言い張る協力会社さんをどうやって説得したものやら．
いいよなぁ，マスタテーブルのカラム構成に変更があるたびに検索している箇所を全て修正して金を要求できるんだから．

つ　View

>>964
説明が足りずにすまん．
そんな高度なレベルじゃなくて"select * "な人であるのが問題なんです｡･ﾟ･(ﾉД`)･ﾟ･｡

>>965
select *でもそんなに困らないだろ。困るのはinsertでカラム指定してない場合な。

稼動しているシステムだとテーブルをドロップできないから、後ろに追加になって
いって横着できなくなる。

そうそう、selectにしろinsertにしろスキーマが変わることを考慮していない奴が多い。
トランザクションの保証になんてたどり着くのはいつの日やら。

SELECT * が許されるのはEXISTSを使うときくらいだなぁ。

>>963
おまえこそがダメだ　でいんじゃねの？　

>>967
わかる奴から辞めていくからね orz

カラム追加がダメとか、SELECT * がダメとか、レベル低すぎだろ。

レベルが低すぎるのは事実だが、
それが日本のデジドカの現実でもある。

>>971は意味わかって言ってんの？

みんなやめていくからね

残るのは人転がしの窓口だけさ

SELECT * は使う奴が馬鹿だと
カラム追加にも対応できないクソコードになる。

普通はそうならんように作るもんだと思うがなwww

カラムの順番を使わずに、フィールド名でデータ処理すればいいだけだけど、
それも出来ないほど技術力がない会社が日本にはゴロゴロしてるってことか。

>>977
回線の無駄。

カラム追加なんて起きないように縦持ちするのが普通じゃないの？

>>979
異常www

ストアドのパラメータを文字列化ちてクエリー実行なんてちてる池沼がいるんでつけど、
どうちたらいいでちょうか (´･ω･`)ｼｮﾎﾞｰﾝ

カーソラーの現場に投入された俺は自殺したい

>>980
異常じゃないと思う俺は異端なのか？

縦持ちするってのは

購入伝票テーブル
id, 購入日, 商品名1, 商品単価1, 商品名2, 商品単価2, ...,商品名n, 商品単価n

ではなく

購入伝票テーブル
id, 購入日

商品テーブル
id, 伝票id, 商品名, 単価

てな感じにテーブル設計するっていうことだろ？
まぁ、join時の死亡確率も上がるから痛しかゆしといえばそうなんだが、
一般的には後者のアプローチのが正義だよな？

>981
ちてちてとかキモイ池沼がいるんでつけど、
どうちたらいいでちょうか (´･ω･`)ｼｮﾎﾞｰﾝ

>>983
正規化って知ってるか…
縦持ちって、なにそのへんな用語。ちゃんと本読もうよ。

一応、正規化することを指してるんだろうなぁと想像はしてたが
やっぱりそうだったか。

DB 縦持ち に一致する日本語のページ 約 1,580 件中 1 - 50 件目 (0.15 秒)

普通に使われてるだろ。
>>985->>986
新卒ですか？

>>988
コボラは横長DBがお好き 3カラム目
http://pc11.2ch.net/test/read.cgi/prog/1205338975/

>>983
商品テーブルに伝票idいれんなよｗ　ってのはともかく、

縦持ちって正規化とはちと違って、
id, 項目id, 項目値
みたいにして、
ID01, 商品名, ぬるぽ
ID01, 単価, 1000
ってデータをつっこんでくやり方だと思う。

>>990
そうそう。糞プロジェクトでそういうテーブル見たことある。
パフォーマンス落ちまくりなのをDBMSのせいにしてたよ、元請けのアフォSEは。

いわゆる環境変数的な使い方ならいいんじゃねーの？
パフォーマンスに影響するほどの用途って思いつかないけど、どんなの？

>>992
定数テーブルみたいなのならいいけど。
商品とか売上テーブルを>990みたいにするのは集計なんかのときものすごく
パフォーマンス落ちると思うぞ常考。

>>992
普通に、データベースが必要になる程度の規模のデータとアクセス回数なら
縦持ちみたいな糞設計は話にならんだろ。

環境設定は縦持ちしてる

環境設定を>>990の例のようにするのは、縦持ちじゃなくて単なる正規化だろ。

>>996
確かに。ということでこんなクソスレとっとと埋めちまおうぜ。

>>997
くやしいのうｗｗｗｗくやしいのうｗｗｗｗ

縦持ちってなんですか？
最近標準化された配列型のことですか？

わからないので、よろしくお願いします。

occurs 1000

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。