T-SQL知らなかったメモマン
時間がないからといって API(に限らず)の設計を見切り発車で作成するのは くなかったな、と痛感した今日。
焦ってコンストラクションを行うほうが 結果としてリスクもコストも高くなる悪例でした。
ストアドファンクションでは副作用を伴う処理を行えない
副作用を伴う処理とは、 INSERT
/UPDATE
/DELETE
/EXEC PROCEDURE
など。
(PROCEDUREに関しては、一部の拡張ストアドプロシージャならOKだとか。要調査)
FUNCTION=関数という言葉を、関数型言語の意味の関数で捉えるとわかりやすい。 参照透過性というか。
exec sp_executesql
を使えば、FUCNTION内部からでも無理やり実行できなくはない…と思うが、
言語仕様としてやめとけっていうのに逆らうとろくなことがない。
PROCEDUREでやったほうがわかりやすくて綺麗になる。
あと地味に、BEGIN TRY〜END TRY
(CATCHも同様)も使えない。
これはちょっと理由がわからないな…。
Table型パラメータの誤算
ストアドプロシージャのOUTパラメータとして、Table型は使えない。
では可変で複数を取りうる値を返すにはどうするかというと、 statement_bodyにSELECT句を書けば、 結果セットとして返却可能。
ただし、通常のSELECTはすべて結果セットとして返却されてしまうので、API設計(というかパブリックなルーチン設計か?)としては あまりよろしくないかもしれない。
ではどうすればよいかというと、 変数に代入してあげれば、そのステートメントは結果にはならない。 Table型(や、独自ドメイン)はINパラメータとしては使える。
パラメータは2,100個まで。
()で囲めば、IF文の中でもSELECT句をかける。
毎度変数に代入してた…。可読性とのトレードオフになるかとは思うけど。
YYYYMMDD形式が厳密に正しい日付かどうか。
一応、IsDateという関数は提供されているが、
言語やフォーマット変えないと使えないっぽい。
CONVERT
使うとエラーになるし、困った。
邪道だけど、TRY-CATCH
でなんとかするか、と思ったが、 FUNCTIONでは使えない。 (アンチパターン)
うーん、8桁の確認と、substring
で分割してIsDate
にぶち込むか、
と思ったら、try_convert
なる関数があるようで。
変換不可ならNULLを返してくれる(もちろんIsNullと組み合わせればNullオブジェクトっぽくも出来る) 素敵関数。
可搬性は低そうだけど…。
STOREDのCREATE系(一応備忘録)
CREATE PROC[EDURE] proc_name ( @var1 type [READONLY], @var2 type = default OUT ) BEGIN -- 最低1行のステートメント END -- FUNCTIONはRETURNSが付く感じ。 -- TABLE型には()を付加して、通常のCreate Tableみたいなカラム定義する
SQL標準も学ばないとな、と決意を新たにしました。
CODE COMPLETE 第2版 下巻
途中までしかまとめられてないけど
第25章 コードチューニング戦略
パフォーマンス ≠ コードチューニング というか、コードの速度向上がパフォーマンス改善の一部分でしかない。 要件、設計レベルの見直しやハードウェアの改善、コンパイラやOSコールなど 改善できるところは多々あるはず。
コードチューニングは基本的に経験則は役に立たない。 立つとすれば、徹底した測定のみ。 ハードウェアや実装言語、コンパイラなどに依存するので 完全な正解は存在しない。
速いコードを書くことより、たいていの場合正確なコードを書くことのほうが重要だ。 実装が完了してから最適化を行う。
第26章 コードチューニングテクニック
【読書】プログラマが知るべき97のこと
全体的に、以下に重点が置かれているのかな、と思う。
「命をふきこむ魔法」「名前重要」の話は特に面白かった。
あまりコードを読んでこなかったので、 今後は新しい言語を学ぶのも含めて、 OSSを色々落として読んでみようと思う。
とりあえず、Javaのsrc.zipから…
01. 分別のある行動
技術的負債 は返す。返せるような仕組みにしておく。
08. ボーイスカウト・ルール
来たときよりも美しく。 コードに編集を加える場合は、チェックアウト時よりも綺麗にして ソースベースにプッシュする。
17. コードに書けないことのみをコメントにする
メソッド名、変数名。
18.
22.
36.
43.
学び方に関する指南。 複数の(パラダイムの)言語を学ぶとか、 勉強会に参加するとかそういう話。
23.
ドメイン特化言語。知らない言葉だった。
25. 見られて恥ずかしいデータは使わないこと
テストデータでふざけたのを投入していて、デモに使われると困る。
33.
OSSで好きなことをやろう。
38. 余分なコードは決して書かない
58.
87.
プログラマとテストエンジニアのあるべき関係について
64. プロのプログラマとは
責任感です。
74. 「イエス」から始める
(要求なども)否定から入るのではなく、 せめて「なぜその仕様変更を行いたいのか」を確認する。 決して無碍にしない。
…次は達人プログラマーを読みたいな。