kb10uy のひみつ
デカ乳の女が描けない
kb10uy(@kb10uy@mstdn.maud.io)の投稿
もみあげの長い美少女の話ばかりしています
Avatar icon: [𝕏] CamemBellcheese
Header: [𝕏] generalcanon
各種フレコ:
beatmaniaIIDX(八段): 1751-5340
オンゲキ(15.8): 3067667719792
Arcaea(◆9): 433827474
このアカウントは、notestockで公開設定になっていません。
King of Performai エリア決勝お疲れ様でした！ | Ag₂O #pixiv https://www.pixiv.net/artworks/85898440
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
Search: [mywords] - らりお bookmarks https://shaarli.cardina1.red/?searchterm=&searchtags=mywords
クソ発言しかねえ！
> **わいせつ**、脅迫、中傷を含む投稿や他人を不快にする内容は禁止なのじゃ。
ダメそう(わいせつな投稿しかしていないため)
同じステートなら D3D11 側で使い回されるとはいえ毎回 ComPtr 引っ張ってくるのもなんだかなあという感じだ
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
1:1 のテーブルを id で JOIN するなら MSJ になってJOIN がそんなに重くならない可能性もあるな
ちゃんと強制的に最適化するオプションを有効にしないとデータが小さいときに見誤るので気を付けましょう(2 敗)
(Option<Col1>, Option<Col2>, Option<Col3>)
を
Option<&Ext> と Ext(Col1, Col2, Col3)
にするくらいの気持ちはね、やっぱりある
んいやどうなんだろう 同時に存在しないからそういうわけでもないのかな(まあ分離しない状態で第 4 正規だとしても僕なら分ける)
さっきの正規化的な話だと suspended かと言うのが暗黙のカラムとして存在すると解釈できて、この場合 suspend 関連情報は多値従属なので分離するのが望ましいことになる
インデックス張ってるカラムしか参照しない場合本当にインデックスのデータしか見ないという最適化が多くの場合存在して、一般的に Index Only Scan (IOS) と呼ばれているやつです
これについては詳しい情報を SELECT しなければ IOS になるので大丈夫そう、 MySQL は知らん
でもアカウント情報の走査で必ず accounts と account_suspends を JOIN するのはあまり望ましくない気もしてるんだよな……
accounts に account_suspend_id UUID REFERENCES account_suspends(account_suspend_id) を入れておけば、 JOIN なしで null / nonnull 判定だけ使ってアカウントが停止されてるか知れるわけで、そちらの方が望ましい気はする
(気はするが、 DB の最適化に関しては全くわからないのでテキトー)
アカウント accounts に対してアカウント停止エントリ account_suspends みたいなのを設定したくて、 account_suspends の primary key は accounts.account_id を流用してええやん的な
絵日記 2020-11-29(Sun) - 日下ファクトリー(Fantia 分館) (日下夏稀)の投稿｜ファンティア[Fantia] https://fantia.jp/posts/531191
【30%OFF】彼女とあま～い作業通話しよ?～バーチャルテレワーク～ [いちのや] | DLsite 同人 - R18 https://www.dlsite.com/maniax/work/=/product_id/RJ293342.html
このアカウントは、notestockで公開設定になっていません。
