FULL JOIN について

oracleの結合でFULL JOIN というものがあります。

簡単に言うとLEFT JOIN とRIGHT JOINを足したような感じですが、

プロジェクトによっては

結合の記述をJOIN（LEFT JOIN ,RUGHT JOIN）ではなく、(+)を使って結合するというルールになっている場合もあります。

で、FULL JOINの記述をしないで同じことを実現しようと思ったら、冗長なコードになってしまいますね…

いまだに、(+)で結合を標準にしているのはどうかなと思える理由がひとつ増えました。

くれぐれも、新しく規約を作る型は結合はJOINでするようにしてほしいなと思います。

主な理由は

JOINのほうが結合条件と検索条件を見分けやすい。
どのテーブルを結合しているのか見やすい。
FULL JOINが使える。
他のSQL言語でも使える。
といったところかな？

SQLで小計、総計 ROLLUP

現在、SQLで明細、小計、総計と出すようなプログラムを作っているのですが、
特に考えることもなく、PL/SQLだったので、明細分をSELECTしてからループして
小計、総計を計算してました。

しかし、よくよく、調べてみたらGROUP BY句でROLLUPってのを使うとSQLのSELECT一発で出来ますね。

取得するレコードによっては工夫が必要ですが…

また、次の機会は使ってみようかな。

案外、忘れている知識もあったりするので、このやり方でできると思っても、多少、調べてみたほうがさらによいやり方が見つかっていいのかもしれません。
過信は禁物ですね。

ROLLUPは、GROUP BY句に指定しますが、一部をROLLUP、一部を普通にグルーピングもできるみたいです

SVFでミスしやすい部分

帳票ツールSVFを使い出して一ヶ月以上経過しましたが、

基本的にはそんなに難しくありません。

ただ、ミスしやすいポイントがいくつかありますね。

まず、罫線の微調整。

よく、微妙にはみ出したりするので、位置をプロパティの値で設定するのが望ましいです。
あと、一括設定の画面でチェックしつつ、PDF出力時に拡大してチェック！！

あとは、キーブレイクの設定。

レポートライターという部分はタブで切り替えないと表示されないので忘れがち。

これまた、一括設定画面でよく確認しましょう。

なにかのレイアウトをコピーして作成する場合は、元にしたものの余計なものが残ってないかチェックするのも大事ですね。非表示項目とか忘れがち。

あとはしっかりテストするしかないですね。

プログラミングセンスの測定法

どうすれば、プログラミングのセンスがあるかどうかわかるのでしょうか？？

と思い、私の中では変数名の付け方でわかるのではないかと思ってます。

例えば、運用年度を日付型で定義してくださいと…

そこで、たいていは

dUnyoNendo とか付けると思いますが、これも人によって様々なので、ある程度、測れるんじゃないかと考えています。

bool型なら　IsとかbIsとかを頭につけた変数名にするとか

本気で何も考えない人なら

aaとかつけかねないですから。

あと、プログラミング規約を作ってもらうとかでもわかりそう

そういうので、古いタイプの人かどうかもわかりますし。

Windows７

ついに、仕事でもWindows７を触るときがやってきました。

以前は、Vistaを使っていたプロジェクトもあったけれど、基本的には浸透してませんでしたが、もうXPを搭載した端末が売ってないので、徐々に７が頭角をあらわしてきました。

まあ、まだ自分自身のローカルマシンはXPなのですが、７はやっぱりXP慣れしていると操作に戸惑いますね。

基本的には同じなのですが、いろんなものの場所が微妙に変わってたりして、探すのが少し手間です。

それに、システムの環境によってはXPと同じようにやろうとしても、できなかったり、うまく動作しなかったりするので、環境構築の手順書を作る場合は７用も作っておくのが得策ですね。

それでも、まだ全体的な割合としては７は２割程度くらいで残りはほぼXPという状態なので、まだ、使い慣れてなくても大丈夫そうです。

個人的には圧倒的にXPのほうが使いやすいです。でも、Vistaよりはよさそうだなー