アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
身近な人の偉大さは半減する -- あるアレゲ人
SQLは人が手で入力して使うツール (スコア:1)
コードにSQLの断片を埋め込んで、パラメータを文字列連結して、ランタイムでコードがSQLを生成するのは、全面的にやめるべきだと思います。
メンテナンス性の為や手抜きのために複雑な構文解析機を通して検索ロジックを実行時に機械語へビルドしている事になるわけですが、安全なサービスの構築のためにはロジックは静的に用意されているべきだと思います。
上に ORM をのっけて蓋をするのでもいいんですが、SQLという文字列でロジックをDBSに渡すというのは、無駄が多すぎる気がしてなりません。
良い解決策をもっているわけではないのですが…
Re: (スコア:0)
Re:SQLは人が手で入力して使うツール (スコア:1)
意味もわからず、今まで同様SQLを毎回組み立ててる大馬鹿者が。。。。
理解できている人にDB IO部分をまかせて隠ぺいさせるか、O/Rマッパーでも使うのが一番かも
Re:SQLは人が手で入力して使うツール (スコア:3, 参考になる)
余談ですが,暗黙の型変換についても気にしてない(気づいてない?)と思われるコードをよく見かけます。
# ちょっと前に,OpenOLAP を PostgreSQL 8.3系で動作させようとしましたが,修正箇所多くて諦めました・・・。
> 理解できている人にDB IO部分をまかせて隠ぺいさせるか
Oracleであれば,
- まず仕様書からDBインターフェース部分を抜き出し,RefCursorを返すFunctionやUpdateを行うProcedureをPackageでまとめて先に実装する。
- P層,F層プログラマにはそのPackageを提供し,SQL文は一切書かせない。
というのが性能面からも理想的ですが,いわゆる「理解できている人」が少なすぎで,実現した試しがありません。Re: (スコア:0)
DBのアクセスに限らず、「低レベル技術者でも安全に使える共通部品を先行開発」というアイディアを完遂できたプロジェクトって少ない気が。ないことはないんだけど。
でもって個人の独自実装による品質のばらつきが発生し後々の苦労が絶えない。
マネージャーが重要性を解ってないのだろうか…
Re: (スコア:0)
でも、「一時的に完遂」しても気がつくと変なフレームワークになって、
人が移動したら誰も解らなくなって、でもプロジェクトは進んでいって、
個々の拡張でドキュメンテーションは追いつかないとなっていくと。
結局、人の階層や時間軸で見ていくと、「個人の独自実装による品質のばらつきが発生しない」っていうのは、
プロジェクトと名づけられ複数の人間が多岐に渡って関係する場合、「銀の弾丸」に他ならないでしょうね。
>マネージャーが重要性を解って