【Oracle】DATE型をWHERE句で比較するときの注意点

今日たぶん人生で初めてDATE型のデータをSQL文のWHERE句の条件で使った気がする。

比較条件の使い方を完全に勘違いしていたので、メモ書きとして
今後のために残しておく。

ピンポイントでSTART_DATEが2017-6-29のレコードが取得されるように、
こんなSQLを書いた。

SELECT
*
FROM
TABLE_A
WHERE
START_DATE = '2017-06-29';

START_DATEはDATE型で定義されていて、実際にレコードには「2017-06-29」というデータが入っているのだけど、
いくら実行しても、結果は表示されず。

なんでだろう～、と思ってググったところ
そもそもDATE型は「＝」で結ぶような比較は出来ないということが判明した。

では、どうやって比較すればいいのか。

その前に、DATE型に格納されている値について確認しておく。
表示上、「2017-2-29」とされていても実データの方には、
「2017-2-29 00:00:00」といった感じで時分秒まで格納されているのだ。

ということを踏まえると前述のSQLの場合、

SELECT
*
FROM
TABLE_A
WHERE

START_DATE > TO_DATE('2017-6-28', 'YYYY/MM/DD')
AND START_DATE < TO_DATE('2017-6-30', 'YYYY/MM/DD'); 

という、SQL文になる。一旦、TO_DATE書式を使って、書式をそろえる。
（実際はいちいちTO_DATE書式に揃えずとも問題ない）

時分秒まで指定したい場合は、

  TO_DATE('2017-6-29 12:12:12', 'YYYY/MM/DD HH24/MI/SS');

のように記述する。

DATE型の比較については、BETWEENを使う方法もある。
範囲で検索結果を取得したい場合に有効。

以下の場合、2017-6-28の00:00:00から2017-6-30の23:59:59までに該当する
レコードが検索結果として取得される。

 START_DATE BETWEEN TO_DATE('2017-6-28', 'YYYY/MM/DD') 
 AND TO_DATE('2017-6-30', 'YYYY/MM/DD') 

※間違えていたらぜひ指摘してください('ω')ノ

スッキリわかる SQL 入門 ドリル215問付き! (スッキリシリーズ)

達人に学ぶ SQL徹底指南書 (CodeZine BOOKS)

徹底攻略 Java SE 7/8 Bronze 問題集[1Z0-814]対応

結合試験が始まって、いろいろ思ったこと

先日、結合試験用に作成を続けていたテストシナリオが完成した。その前に作成の終っていた各画面単位のテスト仕様書とDBダンプ作成のための画面単位のDB確認書をもとに結合テストを実施してもらう手はずであった。つまり結合テストを実施するうえでの仕様書は以下のようにまとまっている。

• 結合テスト用シナリオ
• 各画面単位のテスト仕様書
• DB確認書

ボリュームとしてはこんなもんだろう、という印象。不明な点は詳細設計書やテーブル定義書を確認してもらえばよい。

今更遅いのだけど、もっとシナリオを作成する段階で画面単位に作られたテスト仕様書をよく確認しておけばよかった。というのも、いざ結合テストが始めってみてわかったのだけどとにかくテスト仕様書に不備がめっちゃ多いのだ。

結合試験の準備がなかなか終わらない

スケジュール上ではすでに結合試験が始まっているはずなのだけど、いまだに準備が終わらない。これは、単に結合試験の準備が遅れているからというだけではない。単体試験の結果が芳しくないのがそもそも...という状況が大きい。単体試験を進めるたびに

• 仕様バグ
• プログラミングバグ
• 仕様漏れ

が、ワラワラ出てきて詳細設計書の修正をしている最中だからだ。

【ゲーム感想】ペルソナ４ゴールデン（P4G）をはじめました

ペルソナ3ポータブル（以下、P3P）と同時期に購入して、P3Pクリア後に始めたものの「謎の喪失感」に囚われてなかなか進めることが出来なかったペルソナ４ゴールデン（以下、P4G）を最近はじめたのでちょっとインプレッション的な感想を述べていきたいと思います。

例によってネタバレ等は特にないつもりで書きます。

（めちゃくちゃ明るいトーンのP4G）

技術を重ねないまま年だけ取ったエンジニアの末路

今、還暦間近のエンジニアと一緒のチームで働いている。今は設計フェーズなので、特にゴリゴリコードを書くということもないのだけどこのおじさんがとにかく能力が低い。しばらく実装から離れていた、ということでプログラミングでつまづくというのはなんとなくわかる。しかし、設計・テストフェーズでまともなドキュメントが作れていない状況。

自分も能力の低さなら負けてないので、このおじさんエンジニアはよっぽどの出来だと言えると思う。いうなれば1～２年目のエンジニアとほぼ同等。今まで設計書やテストケースを書いたことがないのでは？と思うくらい質が低い。

このおじさんを仮にYさんと呼ぶけれども、Yさんはずっとエンジニアをこの年まで続けてきてこれなのでまったくエンジニアに適性がなかったんじゃないかと思ってしまう。今たまたまこんな感じなのか、若いころはもっと仕事が出来たのか想像がつかない。

プログラミングってしばらくやってないと本当に染みついた人以外、忘れてしまうものだと思うけど、設計書とかテストケースってそうそう忘れるもんじゃないと思うんだけども...

• この設計書は何を記述するものか
• このテストケースはどういった観点で作られていて、何を確認するか

このあたりの本当に基本的なことがよく理解できていない様子。Yさんの言葉を借りると「細かいことが苦手でよくわからないんですよねｗ」とのことだが、上記の2点だけでいえば特に細かいことはなくてむしろ非常におおざっぱなものだと思うんだけども...

と、ここまで語ったのは決してYさんを腐したいわけではない（ここまで書いておいてなんだが）。人当たりは非常によく、勤怠もしっかりしているYさんは社会人（エンジニア）としては非常にまじめだ。むしろ、このYさんの姿が将来の自分なのでは？と恐怖を感じているのだ。

今回たまたまプログラミングをする機会がなく、自分の一番悪いところ（コーディング技術の低さ）が出ていないけれど、いざプログラミングとなれば自分の言葉がブーメランとして返って刺さるだけだ。まさにコーディング技術は１～２年目のエンジニアにも劣る自分だからだ。

プログラミングだけではない。SQLだってすっかり忘れているし、Linuxのコマンドも忘れている。今、SQL Server Management StudioからDBを取得しようにも方法をすっかり忘れているだろう。PM的なタスク管理の能力もなく、PMOとしてスケジュールを管理することも出来ない。簡単なExcel関数も使えない。

今回ちょっとだけ、たまたま設計・テストフェーズで自分が出来る作業だっただけなのだ。期間的な余裕もあり、作業ペースも緩やかで徹夜をせずに帰れているのは本当に偶然なのだ。今の現状、非常にヌルイ現状に慣れてしまっては今度は自分がYさんになるのは間違いない。

今回の記事のタイトル、これはYさんを指した言葉ではなく、完全に自分に向けた言葉だ。今後、IT産業がどのような形の産業になるか末端の自分にはなにもわからないけど、今以上に技術という部分でハードになっていくのは間違いない。プログラムだけ設計だけでは足りず、場合によってはインフラ周りやアーキテクチャにも精通していないと年齢からいってプロジェクトに入れなくなるかもしれない。書いてて震えてきた。

マンガ 自営業の老後

わかばちゃんと学ぶ Git使い方入門〈GitHub、Bitbucket、SourceTree〉

成功するシステム開発は裁判に学べ! ~契約・要件定義・検収・下請け・著作権・情報漏えいで失敗しないためのハンドブック

「プロになるためのWeb技術入門」 ――なぜ、あなたはWebシステムを開発できないのか