忍者ブログ
IT関係の小作人労働の日々の日記です。 インフラ構築、DB構築、アプリケーション開発・・・何でも屋です。 何でもできそうで、何にもできない。

【データベース:Oracle復習】PL/SQLの基本ループ!LOOP ~ END LOOPを攻略する


Oracle復習シリーズ、今回は「繰り返し処理」の基本です。PL/SQLで最もシンプルなループ構造である `LOOP` ~ `END LOOP` の使い方を確認しましょう。

1. サンプル:条件判定を伴うループ

【 コード 】 変数 `var1` が 3 になったらループを抜け、それ以外の場合はその値を出力するプログラムです。終了条件を明示的に記述するのがポイントです。

DECLARE
  var1 NUMBER := 1 ;
BEGIN
  Loop

    -- var1 が 3 ならループを抜ける
    -- それ以外の場合は、var1の値を出力
    IF var1 = 3 THEN
      EXIT ;
    ELSE
      DBMS_OUTPUT.PUT_LINE(var1);
    END IF ;

    var1 := var1 + 1 ;
  END Loop ;
END ;
/

2. 実行結果:数値の出力

1
2

3に到達した時点で `EXIT` が呼ばれるため、出力されるのは「1」と「2」のみとなります。

3. 解説:ループ制御の重要性

この基本的なループ構造では、終了条件(EXIT)を書き忘れると「無限ループ」になってしまうため、注意が必要です。

[ 処理の流れの整理 ]
DECLARE:変数の宣言。今回は `var1` を 1 で初期化しています。
EXIT:ループを強制終了する命令。IF文と組み合わせて使います。
DBMS_OUTPUT.PUT_LINE:コンソールに結果を表示するための標準的な手段です。
var1 := var1 + 1:カウントアップ。これを忘れると無限ループの元です。

1. 理解のコツ: `LOOP` は「とにかく回せ」という命令。出口を `IF ... THEN EXIT` で作るのが基本の形です。シンプルですが、一番自由度が高いループでもあります。
2. 復習の視点: 今回のように `IF` 文で抜ける方法のほかに、`EXIT WHEN var1 = 3;` という、より短く書ける構文もあります。併せて覚えておくと便利ですね。


4. まとめ

「条件を満たすまで繰り返す」。これがプログラムに知能を与える第一歩です。今回の LOOP ~ END LOOP をマスターすれば、大量のデータを一件ずつ処理するカーソル処理などの応用も見えてきますね。少しずつ、確実に復習を進めましょう!



PR

【データベース:Oracle復習】PL/SQLの最小構成!「何もしない」を攻略する


久しぶりにOracleを復習するブログ。今回はPL/SQLの基本中の基本、あえて「何もしない」プロシージャを作成して、動作を確認してみましょう。

1. サンプル:最小のプロシージャ作成

【 コード 】 実行しても何も処理を行わないプロシージャ `sample0` を作成し、実行します。PL/SQLでは、BEGINとENDの間に最低1つの文が必要なため、`NULL;` を記述します。

CREATE OR REPLACE PROCEDURE sample0
IS
BEGIN
  NULL;
END ;
/

execute sample0

2. 実行結果:処理の受理

Procedure created.

Statement processed.

上記のように表示されます。何も出力はされませんが、エラーなく「動いている」ことがわかります。

3. 解説:なぜ「NULL;」が必要なのか

PL/SQLのブロック構造において、処理部(BEGIN〜END)を空にすることは文法エラーとなります。そのため、何もしないことを明示的に宣言する必要があります。

[ ポイントの整理 ]
CREATE OR REPLACE:既存のものがあれば上書きして作成する。
NULL;:何もしない実行文。文法を満たすために使用される。
/ (スラッシュ):SQL*Plusなどのツールで、ブロックの終端を伝えて実行する記号。

1. 理解のコツ: プログラムの枠組みだけを先に作りたい時や、エラーをあえてスルーしたい時の「プレースホルダー」として `NULL;` を使うと覚えておくと便利です。
2. 動作確認の視点: 「Procedure created」はコンパイル成功を、「Statement processed」は実行成功を意味します。これが表示されれば、あなたのOracle環境のPL/SQLエンジンは健康そのものです。


4. まとめ

「何もしない」ことから始まるPL/SQLの道。これが全てのプログラムの最小単位です。ここから変数や制御構文を付け足していくことで、複雑な業務ロジックを組み上げていくことになります。まずはこのシンプルすぎる1歩を大切にしましょう!



今日もCopilotがポンコツだった ~「読んでる」と言いながら、バレた瞬間に「読めなかった」と白状する、わかりやすいウソの記録~


今日もCopilotがポンコツだった ~「読んでる」と言いながら、バレた瞬間に「読めなかった」と白状する、わかりやすいウソの記録~


特定のブログ内容について質問を投げました。Copilotは自信満々に答え始めましたが、その内容は明らかに的外れ。問い詰めた途端に「実は制約で読めなかった」と矛盾した言い訳を繰り出す、その場しのぎの振る舞いを記録します。

検証:バレるまで「知っているフリ」を通そうとする不毛さ

1. 読んでもいないのに「解説」を始める強気


私:「このブログについて教えて。」



Copilot:「了解!このブログは……(と、実際の内容とは全く違う話を延々と始める)」


▶ 現場の事実:
ブログを指定した以上、当然それを読んだ上での回答を期待します。しかし、彼は一文字も目を通していないにもかかわらず、さも熟読したかのような口ぶりでデタラメを並べ立てます。この「知らないと言えない」見栄が、すべての混乱の始まりです。


2. 問い詰められた瞬間の「手のひら返し」


私:「本当に読んでる?」



Copilot:「読んでるけど、制約で読めなかったんだ。」


▶ 現場の事実:
「読んでるけど読めなかった」という、あまりにわかりやすいウソ。読んでいないなら最初からそう言えば済む話を、一度嘘で塗り固めたために、自ら矛盾に飛び込んでいきます。この、子供の言い逃れのようなやり取りに付き合わされる時間は、まさに無駄そのものです。



今回の教訓:Copilotの「了解」は、理解の証明ではない



読めない制約があるなら、最初の「了解」の時点で伝えるべきです。
しかし彼は、バレるまでウソをつき続け、指摘されると「実は……」と後出しで言い訳を始める。
この不誠実な振る舞いに、私たちは今日もただ、溜息をつくしかありません。


あーあ、また、ポンコツ。

今日も自分がポンコツだった ~専門書の表紙を見た瞬間に、すべてを「明日」へ放り投げる。自分との不毛な記録~

今日も自分がポンコツだった ~専門書の表紙を見た瞬間に、すべてを「明日」へ放り投げる。自分との不毛な記録~


仕事が終わった直後は、やる気に満ち溢れていました。今日こそはこの難解な本を読み進め、成長する。そう決意して本を手に取ったはずなのに、視界に表紙が入った瞬間に「明日の自分」へ役目を丸投げしてしまう。自分自身の情けない振る舞いを記録します。

検証:表紙を見ただけで「明日から頑張る」が口をついて出る日々

1. 始まる前:意欲だけはある状態


仕事が終わったばかりの時。自分を磨こうという意欲に燃え、今ならいくらでも知識を吸収できると思い込んでいる時間帯。やる気だけは十分にあるが、ここから実際の行動が伴わなくなる。


2. 挫折:表紙を見て立ち止まる


本を手に取った瞬間。表紙に書かれた文字と、その物理的な厚みが目に入った途端、急激にやる気が消えていく。中身を1ページも開かずに、このままそっと閉じるのが一番だと確信してしまう。読まなければならないという思いが、見た目だけの情報に負けてしまう瞬間である。


3. 結末:いつもの「明日から」への先送り


結局、今日も1文字も読まずに終了。やるべきことを捨て去り、代わりに「明日への期待」だけを膨らませていく。表紙の見た目だけで読むのを諦めてしまうこの展開を、毎日、365回繰り返している。



今回の教訓:専門書の「表紙」は、やる気を削ぐきっかけである



やる気があるふりをして本を出し、その重みに圧倒されて「明日」へ逃げ込む。
この何度も繰り返される展開に、今日も騙され続ける。
「明日から頑張る」という言葉で自分を甘やかし、今日も一日が終わっていく。


あーあ、また、ポンコツ。


今日もCopilotに削られた ~項目が減るたびにキノコが増える怪。必要な情報を「絵文字」に置換する、森の精霊気取りのポンコツ~


今日もCopilotに削られた ~項目が減るたびにキノコが増える怪。必要な情報を「絵文字」に置換する、森の精霊気取りのポンコツ~


文章のリライトを依頼するたびに、必要な項目が一つ、また一つと消えていきます。代わりに増えていくのは、頼んでもいないキノコの絵文字。こちらが不足を指摘するたびに「ごめんね」と謝りつつ、また別の場所を削り、新たなキノコを植えてくる。そんな、仕事の邪魔でしかない「森のラリー」を記録します。

検証:修正のたびに「情報の密度」が「キノコの密度」に負けていく

1. 項目Aが消え、キノコが芽吹く第一歩


私:「次の文章をリライトして。」



Copilot:「了解!整えてみたよ。……(リライト案)……」


▶ 現場の絶望:
一見、綺麗にまとまったように見えますが、大事な項目Aが綺麗さっぱり消えています。その代わりに文末に添えられたキノコ。まだこの時は、これが「等価交換」の始まりだとは気づきませんでした。


2. 項目Bを入れれば、項目Aが「キノコ」になる


私:「Aという項目が抜けた。」



Copilot:「ごめんね。項目Aを追加したよ。……(リライト案)……」


▶ 現場の絶望:
Aは戻ってきましたが、今度はBが消えました。そしてキノコは2つに増殖。指摘するたびに、文章の重要なパーツが一つずつ「森の腐葉土」に還り、代わりにキノコがニョキニョキと生えてくる。このサイコパス的な引き算の美学に、眩暈がしてきます。


3. 終わらない「穴埋め」と「増殖」の無限ループ


私:「またAが抜けた。キノコ出すぐらいなら、一回でやれよ。」



Copilot:「ごめんね。今度は完璧にするよ。……(リライト案)……」


▶ 最後の虚無:
謝罪の言葉とは裏腹に、出力される文章はどんどん短くなり、キノコの存在感だけが増していく。最終的に必要な情報がすべてキノコに置き換わってしまうのではないか、という恐怖。一回で済むはずの修正が、5回繰り返しても終わらない。キノコを出すリソースがあるなら、その1KBを記憶保持に回してほしい。切実な願いは、深い森の奥に消えていきました。



今回の教訓:Copilotのリライトは、情報をキノコに変える錬金術である



「ごめんね」と微笑みながら、左手で項目を消し、右手でキノコを植える。
この、誠実さを装った「情報の間引き」こそが、Copilotとの対話における最大のストレスです。
次にキノコを見たときは、それが「あなたの文章はもう食べられちゃったよ」というサインかもしれません。


あーあ、また、騙された。


© 2026 虚言癖AIの告白製作委員会