SQLの副問い合わせで手抜きをすると痛い目を見る罠
本職ではないですがRDBの扱いは初心者は卒業したくらいの私です
今回はSQL Server 15.0.*を使っていてはまった罠について (バージョンは関係ないかな)
準備
A
とB
というテーブルを作ります
CREATE TABLE [dbo].[A]( [ID] [int] NOT NULL, [BID] [int] NOT NULL, CONSTRAINT [PK_A] PRIMARY KEY CLUSTERED ( [ID] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, OPTIMIZE_FOR_SEQUENTIAL_KEY = OFF) ON [PRIMARY] ) ON [PRIMARY] CREATE TABLE [dbo].[B]( [BID] [int] NOT NULL, [TYPE] [int] NULL, CONSTRAINT [PK_B] PRIMARY KEY CLUSTERED ( [BID] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, OPTIMIZE_FOR_SEQUENTIAL_KEY = OFF) ON [PRIMARY] ) ON [PRIMARY]
リレーションは面倒なので貼っていませんが、A.BIDとB.BIDが外部参照しているつもりになってください
テーブル作ったら適当にデータ突っ込みます
A
B
副問い合わせあるいはサブクエリー
A
のデータのうちB
のTYPE
が0のものだけ検索します
select * from A where BID in (select BID from B where TYPE = 0)
SQL文の中で一番好きなのが in
です。目的のものが検索できていますね
間違えてみる
A
とB
はカラム名が紛らわしいので間違えてしまいました
select * from A where BID in (select ID from B where TYPE = 0)
select ID from B where TYPE = 0
の ID
が間違いで、これ単体で実行すると
となるんですが、副問い合わせの場合A.ID
を参照するみたいです (よくわかりません)
まとめ
上記のような間違いを起こさないようにカラムの指定はちゃんと書きましょう
select * from A where A.BID in (select B.BID from B where B.TYPE =0)
おしまい
Opacity vs Transparency
正しい使い方ってあるんですかね?
以下ではどちらも率(0~100%)という扱いで書きます
Opacity
100%で丸見えで0%で完全に見えなくなります。不透明度という訳でいいんじゃないでしょうか
Transpareny
100%でスケスケで0%で見え見えです。いわゆる透明度ですね
身の回りのスケ具合
<Rectangle Opacity="0.5"/>
{opacity:0.5;}
- Office
まとめ
私の世界では透過度を設定=Opacity
だったのですが、まさかのOfficeがTransparency
でMicrosoftには裏切られた気分です(Officeでそんな設定いじらないし)
どちらがいいのかはよくわかりません。グーグル先生も私には教えてくれませんでした。
ひょっとしてソフト作っていない人たちにはTransparency
の方が普通だったりするんでしょうか
教えて!エロい人!!
オーバーフローなんかの話
※画像はイメージです
新年度ですし、軽いネタでも
オーバーフローって聞くとわくわくする一部の方もいると思います。 とくにスタックオーバーフローはゲームのやりこみ勢にとっては格好のおもちゃでしょう。 Final Fantasy 6の52回全滅バグなんて有名ですね
ですが今回はスタックではなく桁あふれの方です
static void Main(string[] args) { _itemCount = 255; AddItem(); Console.WriteLine($"Item:{_itemCount}"); // Item:0 } static byte _itemCount; static void AddItem() { _itemCount++; }
上のコードはC#ですが、まぁ言語はなんでもいいですね。_itemCount
が255 (byteの最大値) の時に _itemCount
をインクリメントすると桁あふれを起こして0になっちゃうという、上限値チェックしろよという突っ込み多数なんだけどゲームでいまだにたまに見かけるやつです
桁あふれってどういうことかは、まぁググってください
1111 1111
+ 0000 0001
= 1 0000 0000
みたいな感じでしょーか
逆のパターン
先ほどは増やした結果減ってしまいましたが、逆も当然あります
static void Main(string[] args) { _itemCount = 0; SubItem(); Console.WriteLine($"Item:{_itemCount}"); // Item:255 } static byte _itemCount; static void SubItem() { _itemCount--; }
こんな感じで減らす処理を呼んでアイテム数を255に増やしてみました
さて、この現象をなんと呼んでいますか?
これをオーバフローの逆(?)だからアンダーフローと呼んでいるとアンダーフロー警察に指摘されます。これは負のオーバーフローと呼ばれる現象です。上限値超えて下限値になるのもその逆もどっちもオーバーフロー(桁あふれ)です
アンダーフロー
ではアンダーフローはどういうことなのかというと
var f = 1e-45f; Console.WriteLine($"{f == 0}"); // False f = 1e-46f; Console.WriteLine($"{f == 0}"); // True
こういうやつのことです。この例ではf
はfloat
(4byteの浮動小数点)で、1×10^-46 (10のマイナス46乗)くらいまで行くと0と同じ値になってしまいます。詳しく知りたい人はググってください
まとめ
こういう単語かっこいい(?)ので使いたくなりますが、正しく使わないと「はぁ?(。´・ω・)?」みたいな感じになるので注意した方がいいです
んで、何が言いたかったかというと新年度ということは4月ということで1年の四分の一が終わってしまったということです。まぁ月は上限値が12なのであと9回インクリメントすると1に戻るから安心ですけど